#49927 closed enhancement (fixed)
Editor: Introduce block context
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 5.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Editor | Keywords: | has-patch has-unit-tests has-dev-note |
Focuses: | Cc: |
Description
Related: https://github.com/WordPress/gutenberg/pull/21467
Related (blocked by): #49926
The Gutenberg project is currently exploring the introduction of a new block context feature. The purpose of this feature is to be able to establish values in a block hierarchy which can be consumed by blocks anywhere lower in the same hierarchy. These values can be established either by the framework, or by other blocks which provide these values.
See documentation: https://github.com/WordPress/gutenberg/blob/29c6a1b/docs/designers-developers/developers/block-api/block-context.md
This is planned to be used for:
- Site blocks, to derive values from site settings
- Post template blocks, to derive values from the "current" post
- Navigation block, to derive values from the "current" menu
Many of these use-cases are related to the current full-site editing efforts, currently slated for WordPress 5.5: https://make.wordpress.org/updates/2020/03/06/update-progress-on-goals/
Prior art: Just as many of the full-site editing post blocks are intended to map to corresponding theme post tags, the role of block context can serve the role of The Loop in preparing the post for blocks within to consume from.
Proposed tasks:
- For making context available to blocks for
render_callback
, this relies on the proposal at #49926. There are earlier iterations of Gutenberg#21467 which assigned this context as a global variable and expected blocks to consume from the global, similar to the$post
global. The changes introducingWP_Block
sought to avoid these globals, but it is an alternative option if #49926 is not viable. - Introduce block context mechanism based on registered block settings for providing and consuming context. See implementation from Gutenberg#21467 for initial reference.
- `get_block_editor_server_block_settings` should be updated to pick the new
providesContext
andcontext
keys from the registered block's settings, in order to share these values between the server and client.- Optionally, the
$keys_to_pick
array within this implementation could be considered to be made filterable. It's not explicitly needed for core introduction, but is a challenge for external extensibility, like in the case of Gutenberg#21467.
- Optionally, the
Feedback welcome: While the above can be considered a proposal of tasks, this is all very much subject to change.
Change History (17)
This ticket was mentioned in Slack in #core-php by aduth. View the logs.
17 months ago
This ticket was mentioned in PR #370 on WordPress/wordpress-develop by gziolo.
15 months ago
- Keywords has-patch has-unit-tests added
Trac ticket: https://core.trac.wordpress.org/ticket/49927
#7
@
15 months ago
Dev note should be compiled based on https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-context.md.
#8
@
15 months ago
- Owner set to gziolo
- Resolution set to fixed
- Status changed from new to closed
In 48224:
This ticket was mentioned in PR #372 on WordPress/wordpress-develop by kraftbj.
15 months ago
Confirm $post
is a WP_Post
object.
Trac ticket: https://core.trac.wordpress.org/ticket/49927
#12
@
15 months ago
- Resolution fixed deleted
- Status changed from closed to reopened
I'm investigating an issue with this changeset where running the_content
filter when there isn't a post set is causing a error during unit testing plugins. See https://travis-ci.com/github/Automattic/jetpack/jobs/355892149
I think confirming $post
is an WP_Post
would handle it.
To add on, this is due to the way the test mocks $post
incompletely. We can fix this plugin side ( https://github.com/Automattic/jetpack/pull/16337 ), but I think Core could be a little more defensive too.
#13
@
15 months ago
I think confirming $post is an
WP_Post
would handle it.
Yes, it sounds like a good idea. There wasn't any check present in Gutenberg added, I added a simple check whether it is set when backporting, but it looks like we can be more explicit about WP_Post
and the other global we use.
There have been a few iterations to block context in Gutenberg after the pull request referenced in the original comment.
Notably:
ArrayAccess
to emulate backward-compatibility was not fully-compatible and was rolled backrender_callback