I have recently began developing custom/extending core Gutenberg blocks for a custom plugin that I develop for clients I work with. One of my main concerns is about whether extending core blocks will lead to potentially having to refactor a large amount of client sites when Gutenberg updates the core blocks.

Is there a safeguard within the way WordPress updates software that can prevent this from being a major concern? Is there anything that I can keep in mind when extending core blocks to make it much less likely that I will have to go back and refactor dozens of sites that have this extension?

Creating custom blocks from scratch results in a duplication of a lot of work/code so I would like to be able to take advantage of the existing core blocks as much as possible.

1 Answer 1


Luke, I've only done some but I've had some existing block styles and block style variations break after updates (examples 1, 2).

So far, I haven't found many proactive things to do prevent your blocks from breaking in the first place besides this list on backwards compatibility and would love a core Gutenberg contributor to chime in here (although they likely won't read this) with any additional advice.

That said,

One thing that I've noticed though is that the changes won't affect existing published content on the front-end that has already been published but the 'breakage' of a block will occur within the block-editor when your content editor goes to update a page/post that contains the said block; because the block needs to be regenerated.

Lastly, this isn't so much proactive, but reading over the dev notes can help you be aware of issues immediately before they become a problem for your clients.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.