Editor: Introduce block context

[aduth]

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 introducing WP_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 and context 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.

Feedback welcome: While the above can be considered a proposal of tasks, this is all very much subject to change.

[aduth]

There have been a few iterations to block context in Gutenberg after the pull request referenced in the original comment.

Notably:

• The approach using ArrayAccess to emulate backward-compatibility was not fully-compatible and was rolled back
  • Issue: ​https://github.com/WordPress/gutenberg/issues/21797
  • Fixes:
    • ​https://github.com/WordPress/gutenberg/pull/21868
    • ​https://github.com/WordPress/gutenberg/pull/21921
• A second attempt was made, where instead of trying to reuse the first argument, a new third argument is added to render_callback
  • ​https://github.com/WordPress/gutenberg/pull/21925

Trac ticket: https://core.trac.wordpress.org/ticket/49927

[gziolo]

Dev note should be compiled based on ​https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-context.md.

[gziolo]

In 48224:

Editor: Introduce block context

Backports a new block context feature from Gutenberg. 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/master/docs/designers-developers/developers/block-api/block-context.md

Props aduth, epiqueras.
Fixes #49927.

[SergeyBiryukov]

In 48226:

Docs: Correct $wp_query global reference in render_block().

See #49927, #49572.

Confirm $post is a WP_Post object.

Trac ticket: https://core.trac.wordpress.org/ticket/49927

[kraftbj]

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.

[gziolo]

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.

[gziolo]

In 48243:

Editor: More strict checks for globals in render_block

Props kraftbj.
Fixes #49927.

[justinahinon]

Dev note link: ​https://make.wordpress.org/core/2020/07/30/block-api-updates-in-5-5/

[gziolo]

In 56761:

Tests: Rename and improve the blocks/context.php file to follow handbook

Renames context.php and Tests_Blocks_Context to renderBlock.php and Tests_Blocks_RenderBlock. See ​https://make.wordpress.org/core/handbook/testing/automated-testing/writing-phpunit-tests/#test-classes.

Simplifies also the tear_down method by using the same convention as in [56759].

Props costdev, ockham.
Follow-up [48224].
See #49927.