Exported blocks not visible in WordPress (solved)

I’m new to Pinegrow. Overall…I find it amazing. Having said that I also find it a bit buggy. Most of the work I’m doing is with Wordpress and Tailwind CSS. To learn Pinegrow, I did the recent Flex tutorial…which is wonderful. But I’ve found bugs along the way. I decided I should start posting them.

First one: Pinegrow inconsistently registers the Blocks. They show up in the Blocks folder, with the register php file, but don’t show up in Wordpress. I’ve traced this to functions.php. It seems to be hit or miss whether Pinegrow adds the new block to functions.php. Manually adding the include, doesn’t fix it. When you reload in Pinegrow it reverts to the original functions.php (have had this same issue with a custom header.php always being overwritten. - but guess that is issue #2 :wink:

I’ve tried clearing the cache in both Pinegrow and the browser, but it doesn’t work. I believe the answer IS having it registered in functions.php…but because Pinegrow keeps deleting any customization to functions.php. it does not resolve the issue.

@iHuman Most of my work is also with blocks and Tailwind and I haven’t run into either of those issues. Can you post a loom video (or similar) and/or a sample of your project showing us what is happening?

It would be really complex to do a video of…
I am wondering if some of the bugginess I’m experiencing with Pinegrow is related to working on an M1 processor?

I’ve done a lot of Tailwind CSS with php manually (Sublime)…without issues. So I’m fairly confident in my coding skills.

Here’s the issue:

  1. create a block
  2. save all
  3. export theme
  4. block appears in block folder under correct name, with all component files.
  5. hit or miss whether block appears in _pgexport folder
  6. functions.php shows the require file in the block init
  7. functions.php in _pgexport does not.

So in summary, for whatever reason…the two don’t seem to sync. The frustrating part is that it is inconsistent. I created four blocks that worked like a charm. The last one…just won’t work. Have deleted and retried, but no luck. I even thought it was a naming issue - deleting a block and creating a new one with the same name. If so, seems that clearing the cache would resolve that.

Also…if I manually register the block in functions.php - it DOES show up in Wordpress…but with the error that the site doesn’t support it. Catch 22…

Decided to try deleting the block and rebuild it…this time watching the blocks folder to see what happens. It seems to me…if you delete a block in Pinegrow, when you save all, it should delete the old block in both Blocks folder locations. It doesn’t.

Didn’t do much with themes yet. I’m doing a plugin right now with a lot of custom blocks and everything works like a charm. Also on a M1 Mac here, so that can’t be a problem in my opinion!


@iHuman thanks for posting details of the issue and helping with troubleshooting.

PG doesn’t delete any files in the export folder, as a safety precaution. Would not want to delete any manual customization. In such cases it is recommended to do “WordPress → Clear the export folder” to delete the folder and then do Theme export.

M1 should play no role here, I’m using it as well. The problem seems to be related with exporting the functions.php.

@iHuman I just set up a sample project and ran through the steps you outlined. Everything is working as expected. (I’m also on an M1 Mac). Here is a Loom video of the start to finish process.

iHuman Pinegrow Test - Watch Video

Maybe you can link to a copy of your project so we can take a better look?


“WordPress → Clear theme folder” ? I don’t see an option for “WordPress → Clear the export folder”

1 Like

I should have noted… this is specifically an issue with interactions. The other blocks that worked like a charm - did not have interactions activated. This is block is a slider.

@iHuman Okay, I seem to be able to reproduce your issue. Here is a video of what I did to reproduce it and the troubleshooting steps I took.

@matjaz This does appear to be a real bug.

Steps to reproduce:

  1. Export theme with a block.
  2. Delete the block you exported
  3. Recreate the block you exported with the same name
  4. Note that the newly recreated block is not exported
  5. Rename the recreated block
  6. Note that the previously deleted, recreated, and renamed block is still not exported.

I tried all the usual stuff… clearing cache, regenerating functions.php, clearing and recreating the export folder. Nothing seemed to make the theme exporter pick up on that block.

Other things I’ve tried/checked/noted

  • The “bad” block now shows up as part of the template even though it’s marked as a block in PG.
  • I can successfully create NEW blocks after making a “bad” block, as long as I don’t re-use any old unique Block IDs.
  • Renaming the cms-block-title has no effect
  • Renaming the WordPress Block Title has no effect
  • Closing & reopening Pinegrow has no effect
  • Deleting my Pinegrow application support folder has no effect

Be careful not to re-use any block IDs, regardless of whether or not they have been deleted. If you are experiencing this problem, delete the offending blocks and sections and re-create them with a unique block ID.

iHuman Pinegrow Test - Part 2 - Watch Video

And here is a repository with my test project


@adamslowe great debugging skill, thank you for this!

I managed to discover and fix the issue, the fix will be soon out with PG Live.

For now, a workaround is to check if Block type setting on the Block action is set correctly.

More about the issue

In the following workflow, the Block type gets incorrectly set to “[Object object]”:

  1. Add an component from the Page Library to the page (such as the Slider blueprint)
  2. Add Block action to the element
  3. Export the theme
  4. Add another slider from the Page Library to the page
  5. Add Block action to that element. Block type gets corrupted.

In addition, the Register Pinegrow Blocks section didn’t get cleared if there were no blocks in the project. This is fixed as well.

@adamslowe, @iHuman & @Wolfgang.Hartl keep posting your reports of any issues you encounter, they are super helpful!


Thank you so much for the quick update!

Since it isn’t obvious where to download Pinegrow Live, here is a link:

1 Like

Great work @adamslowe ! That pretty much sums it up exactly!

From a software dev viewpoint, it makes sense the chain of events would be user delete block → app removes specific block folder from parent block folder (all of its files) → app removes from functions.php …and if there is a dB that tracks the unique ID, run a DELETE from for the specific ID. Might be part of projectdb.pgml.

That’s doesn’t appear on my version (6.7) Are you using a beta version @adamslowe ?

I see now…it’s a latest builds version. Downloading now!

The production releases have the question mark and the coffee cup. Pinegrow Live, which is the bleeding edge version, replaces the coffee cup with a radio signal icon.

Just installed the Live version. Looks like theme settings don’t work in that version.

Also… @matjaz why do custom header.php files always get overwritten in Pinegrow?

It should work in PG Live. What happens?

At the moment, that’s how PG works. header.php is always generated, even if header.php exists in the source project. One solution would be for PG not to generate PHP files that already exist in the source project.

But let’s step back first. Why do you need custom header.php as opposed to adding custom code in the master page so that PG would export the correct functionality?

theme settings in live
what happens? No matter what you set the theme on it stays on the default dark.

custom header.php
I used custom headers quite often. For example, I do an include header-meta - where I can add the specific metadata, twitter card, og, etc for a client. Definitely would like the option to not have header.php not overwritten…without having to disable it for all files.

Suggetion: Why not do something like a gitignore? We could set which files we don’t want Pinegrow to auto generate. Or add it as an option similar to do not export. add do not auto generate.