I don’t fully understand the Deprecation feature of G Blocks but if it can help solve the issue of “Attempt Block Recovery” notice every time you make a minor change to a block it would be a huge help. Right now I find myself deep into a new website and need to make an update to a block sitewide but get tons of “Attempt Block Recovery” notices which don’t look great from the client’s perspective and if there are hundreds of them is laborious to go into every post/page and update them manually. -Thanks
@jonroc this is one area where WP core needs to make progress. There should be site-wide update block(s) option in WP.
One idea I’m entertaining is to export hybrid blocks - JS in the editor and PHP on the frontend. That would make sure that blocks are always displayed up to date and avoid the recovery completely.
1 Like
During the development phase with Pinegrow, for each modified block, the author will find himself in this painful situation, but it is understandable and acceptable.
Once the site is in production, the author will have two choices to update the structure of his blocks:
- Do not deprecate the block and create a new one (a different name)
- Provide a “deprecated” version of the block allowing users opening these in the block editor to edit them using the updated block.
@matjaz has indeed recently envisaged a solution (hybrid blocks) intended to facilitate the life of the authors/developers who very regularly modify the definitions of blocks, mainly because of the facility offered by Pinegrow for such operations.
*HYBRID BLOCKS: rendering JS in the editor to ensure superior editing experience, and PHP rendering on the front-end to always serve the correct version of the block and up-to-date dynamic data.
The data & display would be 100% the same in the editor and on the front-end. The only drawback would be a slight performance hit from rendering each block with PHP. It might be negligible.
ETA: After the 1.0 release of the Pinegrow plugin for WordPress. For now, it’s just an idea floating around.
1 Like
Since you first mentioned the idea of hybrid blocks i just can’t stop thinking about them 
i think that would solve a lot of problems indeed! 
1 Like
Sounds great! Do you think exporting blocks to a PG plugin (vs exporting to a theme) would be viable as an official plugin for WP.com? I realize I’d have to manually add in some things like an update feature but do you see any reason PG could not act as my base for a “real” WP community plugin?
@matjaz Will SEO plugins be able analyse/read the hybrid block content? Most of them parse html and analyse the content.
Will the hybrid block content be like this?
<!-- wp:custom/heading {"htmlRender":"\u003ch1\u003eTest\u003c/h1\u003e","content":"Test","uniqueID":"c97ddbd8-a7f1-49d8-b5dc-024ed74df2a8","classID":"heading-c4df2a8","id":"heading-cc97ddb"} /-->
@jonroc I guess it could be, but I haven’t tried to submit a plugin to WP plugin store.
They should. It’s just the content, doesn’t matter how it is implemented.
No, I meant the content on the back-end. Most SEO plugins read/analyse the content on the back-end. They are able to analyse the normal/js blocks as the block html is available for them to scan. They are not able to scan the dynamic blocks since the html output is not available and it’s dynamically generated/render from the php file. So I was wondering how will be the behaviour with the hybrid blocks.
Are you sure about this? WP function get_the_content() returns the content of the post with all blocks (JS and PHP) evaluated. I don’t see a reason why a SEO plugin could not use this information on the backend. NOTE: I’m saying this without looking closer at various SEO plugins. Just, as a WP developer, I can say that all data is there, available to be used.
@matjaz I think most such plugins do not rely on that particular function as they provide real time analysis as you type the content in the blocks. I will dig more into it. It’s not your issue in any case.
I was surprised to see a "Attempt Block Recovery” in the edit mode of an existing post when troubleshooting why a small tailwind tweak to a grid-cols class didn’t show on the front end after exporting the updated plugin. I tried it a few times selecting different options such as ‘regenerated the plugin php file’ and am still getting the same issue.
Is my understanding correct that you if deprecated an existing block you would essentially have to repopulate the content again? If the existing block’s been used in multiple posts across the site why update v1.0 if you need to go back and manually update the block in the post?
If this is still an existing pain point, how does one go about managing these changes? Can one run a script to get a list of affected blocks? I can’t imagine how @jonroc was able to go back and manually update his blocks.
@pixel fortunately, I was working with a team and had interns, so that’s how I was able to manually update blocks by hand. I’ve seen a few suggestions on how this could be done with a script of some sort but have not ventured down that path and I have my doubts about how well that would work.
This issue in blocks is one of the big reasons I’ve turned away from BS and TW in general. The way I “manage” them now is to only use custom CSS for each block and build a solid HTML structure that is flexible enough to be able to allow me to make changes in the CSS only. When we inevitably run into an issue on a live website (happens all the time) that requires a whole theme update for a block, we’re able to change the CSS only (not the HTML), which does not create a “Attempt Block Recover” issue. It’s that in combination with trying my best to get the block 100% correct before using it for real/live data.
[UPDATE: after faffing about doing what I suggested below, I could just use the search box in the posts page for the ‘Unique ID’ used on the block. That works to find the posts which will get the ‘Block Recovery’ issue if you made changes. Thank you google Bard :)**]
Thanks for the insight into how you managed it before. Mirroring your thoughts, I have been tinkering with the pinegrow settings for inserting a UNIQUE ID into the pinegrow block so it’s in the HTML or $post_content and then run a script to pick up this particular ID and present it as a table. I think that could work as a revision procedure for blocks. It’s a solution for a much better coder than I though.
I get the CSS approach for layout pages and that’s always going to be more elegant than Tailwind. That said I’m all in and not ready to get divorced from her just yet. On a positive note I think having a way to search and find particular block layouts on posts could be handy in other situations beyond a stop gap for this ‘Block Recovery’ hiccup.
2 Likes
Another way around this is by using Dynamic PHP blocks instead of regular JS blocks. That avoids the whole “attempt block recovery” thing, but introduces a bit of overhead.
I know at some point @matjaz was looking into a hybrid block that would potentially help, but I’m not sure where that stands.
I thought you might chime in at some point Adam 
The only automated fix I could find was if a page/post is in edit mode and you can run the in-browser inspector. Pretty useless if it can’t be run site wide. All the gutenberg plugin tools would perceivably experience this Block Recovery issue.
How to Recover All Broken Blocks In One Command in WordPress - Stackable (wpstackable.com)
Yeah, hunting down and fixing them is a massive hassle. It’s one of the (many) half-baked parts of the WordPress block editor. Your article is as good a solution as any.
Like @jonroc, I also stick with vanilla css in blocks to avoid this issue since style changes are much more common than structure or logic changes.
1 Like
(copying this from the Facebook post)
I forgot about the “Find my Blocks” plugin. I haven’t used it in a while, but it worked nicely when I tried it last year.
https://wordpress.org/plugins/find-my-blocks/
This is the immediate-term solution for the blocks you already have. If you are making new blocks and you think you might change the structure of them in the future, I’d advise manually changing the block type to use Dynamic PHP instead of the default javascript block. Those get rendered each time they are loaded, so you won’t run into this issue.
2 Likes
Yes, the ‘Find my blocks’ plugin works quite nicely. PHP blocks seems the way to go for now.
Thanks Adam for the video and thank you Pinegrow for the Hybrid option!
2 Likes