Can changes to custom block templates update already defined blocks?

[gthayer]

Issue Overview

Forgive me if this is covered elsewhere, but I can't seem to find a ticket discussing this directly.

I've been experimenting with creating custom blocks, and I'm finding that I can create a block and use it on multiple pages as expected. If I later update the template, I need to go into each page and update the block manually because the block HTML is written statically into the post_content.

I get a notice about the update, so this seems to be the expected behavior, however, it seems like this would severely limit longterm scalability.

For example, I have a client who embeds a shortcode we created which displays an "Add to Cart" up-sell within blog content. Creating a custom block would make perfect sense in this case, but if we ever needed to change the layout, needing to update each post manually would be a real hassle.

Am I missing something here? Is there a means to update the blocks layout after a template change? If not, is the current storage method the expected longterm solution?

Thanks!

[ghost]

No idea what the gutenberg teams expects, but in my opinion:

That's why i would never recommend using static html in such cases. It may be ok for trivial blocks like headings or buttons, but it's a killer for complex semantic blocks. Not only because of design changes, but the data is also unavailable for any further processing.

So i would suggest either storing the attributes in html comments (well, no) or as custom_fields, and then register a server side rendering function.

register_block_type( 'myapp/myblock', array( 'render_callback' => 'myapp_render_myblock', ) );

But there are a few unsolved issues around the editable component #4489 #4490

[youknowriad]

This PR should document what you can do here #4574.

I'm closing this issue as the API is already there.

[gthayer]

Good to know. Thanks for sharing this.

Correct me if I am wrong, but using the deprecation API would allow the user to update the existing block in the admin without receiving an update notice (useful for devs handing something to a client, or the blocks name changes) however this does not effect the frontend display.

Even after deprecating the older version of the block, one would still need to update each post individually to ensure the most recent version is displaying.

[youknowriad]

Even after deprecating the older version of the block, one would still need to update each post individually to ensure the most recent version is displaying.

yes

Correct me if I am wrong, but using the deprecation API would allow the user to update the existing block in the admin without receiving an update notice (useful for devs handing something to a client, or the blocks name changes) however this does not effect the frontend display.

The block updates itself when opened in the editor but unless you save the changes the old markup is kept as is.

[gthayer]

Eek, good to know. I can see the value in storing the data this way for increased load time performance, but this certainly limits custom block options. Thanks for all the info!

[benoitchantre]

Maybe we will see a WP CLI command to update a block or all blocks everywhere.