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
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:
create a block
save all
export theme
block appears in block folder under correct name, with all component files.
hit or miss whether block appears in _pgexport folder
functions.php shows the require file in the block init
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.
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.
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.
Recreate the block you exported with the same name
Note that the newly recreated block is not exported
Rename the recreated block
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
Workaround:
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.
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.
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.
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.
