Blocks: Optional support that optimizes handling blocks for usage as structured data

[gziolo]

• Part of Block API #41236.

What problem does this address?

Related issues and PRs: #2649, #6494, #2649.
Related Trac tickets: 53603, 53602.

There are many ways how people use WordPress. One of them is to consume the content saved by the block editor as JSON. Let's explore whether we can add an optional built-in support that optimizes handling blocks for usage as structured data.

The default configuration optimizes the block editor to store the values assigned to block attributes in two ways:

• Inside the code, comment as a serialized object - that part we can always read on the server as we have access to that object.
• Inside the HTML snippet saved with save function – that part we can only read on the client in WordPress core today because we need to know how to query those attributes and have a tool that would do it in PHP.

There is an ongoing exploration (#46345) to build a tool that reads attributes sourced from HTML on the server with PHP, but it might only work in some specific cases. There are several limitations on how far we can go with that approach coming from the architectural decisions made in the past:

• Blocks need to be registered on the server so we can define the attributes to use when querying HTML content.
• The way how blocks get saved to HTML might change over time. The only way to migrate them to the latest version is to run the migration logic (usually when opening in the editor) that is written only in PHP. In effect, we can't run the same code on the server to migrate blocks, so even when we have the definition of attributes, that might not be what fully matches the outdated HTML stored in the database.
• The last but less concerning issue here, but still a valid one, is the attribute's default value. We can't access that value if the block isn't registered on the server. In many cases, it isn't a problem when working with structured data.

What is your proposed solution?

What if we offer an optional editor setting that enables a few optimizations that resolve the listed issues when consuming WordPress blocks as structured data?

Here are some initial ideas:

1. First idea comes from @dmsnell and is explained at length in his blog post - disable the mechanism that prevents attributes sourced from HTML in the block comment delimiter. It will create duplication, increasing the size of the content stored in the database. That might complicate updating the block by hand, as the HTML of the block would no longer be a source of truth for those attributes. However, in that case, only the block comment delimiter matters because the block's HTML becomes merely a historical snapshot from when it got saved by the editor.
2. Expose block data directly through REST API endpoints (Trac ticket). When retrieving a post via the REST API you could get the block data as part of the content object instead of the HTML.
3. Expand get_post's $filter parameter to allow block data as a return shape (Trac ticket).

[gziolo]

We are exploring a new concept of a partially synced pattern, as explained in #48458. There is an ongoing discussion (see my comment #50456 (reply in thread)) on how to dynamically mark content in the saved HTML to replace it on the server with PHP during the rendering phase. While it isn't related to this issue directly, it can offer some new ideas on how to mark and read the content stored inside HTML to use it as structured data. I can see the future where we find a way to post-process the saved HTML in JavaScript and modify the markup to precisely annotate it with data attributes that would hint that tag attributes or inner HTML contains value related to block attributes. This way we could resolve all the issues listed in the description.