4 Comments

  1. peter
    · Reply

    what about using dynamic blocks where the outout of a block is rendered in php?

    Report

  2. Federica
    · Reply

    Thank you Justin for covering this topic. I agree with you that a good development starts with a good plan for the future, but sometimes, no matter how good was your initial plan, you have to change something due to user feedback for example or for adding an enhancement in your block/plugin.
    I think developers have the right to update/upgrade their blocks/plugins/modules and there should be a consistent (and documented) way to “do it right” by preserving what was already done by the user and reflecting the changes in the right way if possible.

    Report

  3. Bastian
    · Reply

    One of the biggest problems with developing blocks for Gutenberg is that it relies on the output markup as the overall source of truth, when it should be the attributes and/or state. So, if for any reason you want to a simply replace a “div” with a “nav” in a block you developed a year ago, you are screwed.

    Report

    • Christoph Bratschi
      · Reply

      Yes, HTML markup is the first citizen for Gutenberg and not the raw model it is based upon. I proposed a different compatible approach to update markup in this comment:

      https://github.com/WordPress/gutenberg/issues/4849#issuecomment-719651681

      I am running an agency and we have WordPress installations with up to several hundred thousand posts. Therefore it is crucial for us to be able to upgrade all content at once. For instance we are using Bootstrap and it’s common that HTML markup changes between major revisions and sometimes even minor ones if new features are introduced. On top of that HTML specs are regularly extended and markup has to change to follow latest standards and SEO recommendations. A simple and robust upgrade path is therefore a must have feature.

      Server-side rendering is unfortunately not a solution because of its limitations.

      ACF’s approach looks promising but so far only supports one InnerBlocks per component. They already announced to be working on a solution for this issue. I am looking forward to this update. This finally would separate the model (JSON in the_content) from the view (server-side rendered HTML).

      Report

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: