Gutenberg Attempt Block Recovery - Updated Block

Question

Anyone could tell me proper method how to update existing, added Gutenberg (custom) blocks after code edit? As we know after any code update we need to click "Attempt Block Recovery" to reload a block and save the page. But if the block would be used on +500 pages, it will be impossible to visit each and re-save.

With 12.5 plugin I can see very long console.log with updates for existing core blocks on patterns, so it looks like there is a method for it, but I can't find how to use it.

Does anyone have a good method for it? "Search-replace" on DB is not an option to update the blocks ;)

Thanks.

Answer 1

Assuming you are the custom blocks author, you can deprecate the current version of your block and create a new version that contains the changes. This strategy is advised for static blocks in which you are either changing the block attributes or markup. If you follow this strategy, whenever a post/page is loaded in the Editor, the block will automatically attempt to migrate to the newer version.

NB. With this approach for each deprecation, the save() function must return valid content for the block; if it doesn't, the block is skipped and migrate() will not run. If the migrate function handles the changes correctly, you will avoid the dreaded "Attempt Block Recovery" issue.

The drawback is (as noted), all existing posts/pages until edited use the previous version of the block. I've worked through this same issue migrating ~300 pages to use a new versions of 5 custom blocks. After becoming frustrated with lack of ease to accomplish this, I generated a csv list all the required URLS into Selenium. Next, the Selenium script opened each page in the Editor, then the Editor automatically migrated all blocks before resaving the page. While this sounded like a good idea, in reality it was really slow and inefficient although it did achieve the desired result in ~1hr without noticeable interruption to a production site.

I further tested the much faster method of exporting the required pages and using GREP to find replace the blocks with valid output from the save() method of new block version (not ideal, brutal but it did work for certain blocks).

Alternatively, if it is a dynamic block and the block output is rendered by PHP and no block attributes change, you can just update the PHP render callback function.

This issue was also discussed on WordPress Gutenberg GitHub and is worth a read for background into how migrations are handled and why.