You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
More advanced REST API consumers will want to switch how they handle post_content depending on whether the content contains blocks or not, and (in the future) will likely want to switch based on which version of the block format it contains.
Rather than requiring consumers to duplicate how Gutenberg determines whether to parse blocks or not, we can expose the same information in post objects returned by the REST API.
Currently, it would return:
0: The post_content does not contain blocks, it can be treated as classic content.
1: The post_content contains blocks, it should be treated appropriately.
If the block format has back compat breaking changes in the future, we can increment this value as needed.
For an immediate practical use, this would be useful for the WordPress mobile apps to decide how to handle the post_content: wordpress-mobile/WordPress-iOS#9194
The bug that caused this change needing to be made in the mobile apps is also why we should be exposing a flag, instead of relying on Gutenberg's internal behaviour: when we changed how core blocks are stored in #2950.
The text was updated successfully, but these errors were encountered:
A side note on implementation details: I would expect the version to stay at 1 until the WordPress 5.0 release: there may still be breaking changes in the format between now and then, but until that point, I would like for Gutenberg to not be bogged down in back compat handling.
Issue Overview
More advanced REST API consumers will want to switch how they handle
post_content
depending on whether the content contains blocks or not, and (in the future) will likely want to switch based on which version of the block format it contains.Rather than requiring consumers to duplicate how Gutenberg determines whether to parse blocks or not, we can expose the same information in post objects returned by the REST API.
Currently, it would return:
0
: Thepost_content
does not contain blocks, it can be treated as classic content.1
: Thepost_content
contains blocks, it should be treated appropriately.If the block format has back compat breaking changes in the future, we can increment this value as needed.
For an immediate practical use, this would be useful for the WordPress mobile apps to decide how to handle the
post_content
: wordpress-mobile/WordPress-iOS#9194The bug that caused this change needing to be made in the mobile apps is also why we should be exposing a flag, instead of relying on Gutenberg's internal behaviour: when we changed how core blocks are stored in #2950.
The text was updated successfully, but these errors were encountered: