• 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).