Block plugin updates and the sometimes delayed effect on the frontend

I am a big fan of Gutenberg. But a few weeks back I had multiple content pages that got destroyed in the frontend after updating, without changing much.

The reason: a block plugin had an update earlier which changes block markup, and with that, a few of my custom CSS rules did not apply any longer. Well, that could also happen with plugins that use shortcodes, but…

If Gutenberg blocks are created in the default way, they save their markup to the database, it does not get generated on page load. And with that, the page will look great after updating a block plugin, because the markup is changed when the user updates the page, not earlier.

I did not have that in my mind while working on the project, so the customer was the one who updated a page and saw the frontend with the wrong styles.

My short-term conclusion from that is to only use third-party blocks when they match 100 percent. That will not be the case often, so I will need to write a custom block more often.

Idea for a better solution

Of course, that cannot be the goal in the long term, but I do not want to manually update all pages and posts after a plugin update to check if everything continues to work like expected. So I think about a solution that automatically updates posts and pages after an update.

Even better would be if the tool would take screenshots of the content, to be able to automatically say if something broke.

Leave a Reply

Your email address will not be published. Required fields are marked *