Block migration on larger sites?

[tomasruud]

Hi! So, I got more of a question/hypothetical problem than an actual bug.

We are currently buliding a larger site for a client, and have decided to try to adapt Gutenberg as our main editor. The site is mostly static information, but there will be a lot of pages with content, and we are building our own custom blocks to fit the different elements of the website. We're realizing that we might end up using some blocks on many of the pages, and have been doing some testing of block migrations.

Now, let's take an example. Say I have a block for "hero" elements, which has an image, a title and some text. I've created the markup and added it to the save() function of my custom block. Then I use this hero block on 43 different pages. Suddenly my designer makes some changes to the hero element, which requires the markup to be changed. I then add the deprecated property to my block, which should handle the transformation. But, how do you migrate all the blocks used on all of those pages? From my testing the only way to make sure it happens is by changing a property for all blocks, one by one, until all of them have run the deprecated script.

[artuze]

That's the main reason why I'm avoiding saving any markup into the post_content for most of the blocks I'm creating and rendering them serverside. It's completely anti-Gutenberg philosophy as I understand it, but best I can tell, that's the only way to have the flexibility to change things going forward.

Side note — it's an issue I'm seeing with the Gallery block now too. With the old editor and gallery shortcode, we had the flexibility of adjusting the markup or replacing it entirely pretty easily (like with a carousel of some kind). With this, it's all stored in the content, so you better be okay working with that markup.

Anyway, commenting to follow along on answers to this question because I want to know too.

[tomasruud]

Yeah, it's basically what I've been doing as well. All of our blocks are rendered server side now. We don't really have to worry about switching themes on this website, because that's a thing you would rarely do on a professional site anyway. Our concern is updating our theme, and server side rendering seems to be the only safe way to make sure this is possible.

[danielbachhuber]

I expressed some opinions about this in this blog post: How to Convert a Shortcode to a Gutenberg Block

Specifically, dynamic block rendering makes it simpler to:

1. Render different presentation in different contexts. For instance, AMP doesn’t support arbitrary JavaScript, so you might want to render a HTML link instead.
2. Change the presentation in the future without updating all stored instances. For example, you may decide to wrap your <script> tag with a <div class="github-gist"></div> for easier styling.

However, the gap is still in producing previews. I've opened a new issue for such: #5862

[danielbachhuber]

@tomasruud Any other specifics we can help with at this point, or is it safe to close the issue?