Open gziolo opened 1 year ago
We are exploring a new concept of a partially synced pattern, as explained in https://github.com/WordPress/gutenberg/issues/48458. There is an ongoing discussion (see my comment https://github.com/WordPress/gutenberg/discussions/50456#discussioncomment-5873770) 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.
What problem does this address?
Related issues and PRs: https://github.com/WordPress/gutenberg/pull/2649, https://github.com/WordPress/gutenberg/issues/6494, https://github.com/WordPress/gutenberg/pull/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:
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 (https://github.com/WordPress/gutenberg/pull/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:
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:
get_post
's$filter
parameter to allow block data as a return shape (Trac ticket).