Pinegrow inconsistent with registering blocks

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.

Do not export seems for me the approach which fits more in the current workflow.

But that would mean, that PG has to generate all files which normally get auto exported whenever you turn your project into a WP-Theme into your project-folder (for flagging them later). So that you can manually pick then which files not to export, default could still remain then to export everything and as you do it with other files you would need to add the “do not export” to files you don’t want to be auto-generated!

Written in a few lines, but I guess could be not that easy to implement, as always with feature requests! :wink:

Got the light theme working in PG Live. Temporary mind lapse. Age happens!

1 Like

@iHuman why not use Function action or PHP code blocks directly in the header on the source page, so that any custom code is defined there and will be exported into the header.php? In this way, everything would defined be in the same place (in index.html for example).

1 Like

@matjaz when I insert anything into Pinegrows header.php (includes, etc) it get’s overwritten. I guess I could add custom functions for meta-data etc in the functions.php file (wait…can’t edit that one either)…the custom.php file, but it’s not ideal. Any reason you overwrite header.php and functions.php? How about an option to disable overwrites selectively?

Most of the sites I was building prior to Pinegrow were all hand coded. (Also all Tailwind with Gulp) So I have a system of includes that works really well for me. It’s not necessary for me to have a visual editor like Pinegrow…but I do enjoy it! Pinegrow has convenient features. Can you explain why you overwrite certain files?

@iHuman to add custom code in functions.php, do it in the source project (not in the exported theme) and add your code outside of PG generated sections:

/* Pinegrow generated Load Text Domain Begin */

//This will be overwritten
/* Pinegrow generated Load Text Domain End */

//This will be kept

That said, if you regenerate function.php, any custom edits will be lost.

Therefore it is best to add custom code into inc/custom.php file in the source project.

PG overwrites files that it generates, including headers and function.php.

We could add the following simple logic:

  1. PG generates file A
  2. If file A exists in the source project, do not export the file A and instead use the A from the source project

There would have to be some kind of visible warning in order to let users know what is happening, and to avoid confusion as to why some changes done to HTML are not reflected in the exported theme.

This would not work for functions.php because PG needs to control many things in there. The above mentioned would have to be used for that.

1 Like