WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 3 months ago

Last modified 8 weeks ago

#49927 closed enhancement (fixed)

Editor: Introduce block context

Reported by: aduth Owned by: gziolo
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 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.

Change History (17)

This ticket was mentioned in Slack in #core-php by aduth. View the logs.


5 months ago

#2 @aduth
5 months ago

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

Notably:

#3 @gziolo
3 months ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 5.5

#4 @gziolo
3 months ago

  • Keywords has-patch removed

This ticket was mentioned in PR #370 on WordPress/wordpress-develop by gziolo.


3 months ago

  • Keywords has-patch has-unit-tests added

#6 @gziolo
3 months ago

  • Keywords needs-dev-note dev-feedback added

#8 @gziolo
3 months ago

  • Owner set to gziolo
  • Resolution set to fixed
  • Status changed from new to closed

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.

#9 @gziolo
3 months ago

  • Keywords dev-feedback removed

#10 @SergeyBiryukov
3 months ago

In 48226:

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

See #49927, #49572.

This ticket was mentioned in PR #372 on WordPress/wordpress-develop by kraftbj.


3 months ago

Confirm $post is a WP_Post object.

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

#12 @kraftbj
3 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.

Last edited 3 months ago by kraftbj (previous) (diff)

#13 @gziolo
3 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.

#14 @gziolo
3 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 48243:

Editor: More strict checks for globals in render_block

Props kraftbj.
Fixes #49927.

This ticket was mentioned in Slack in #core by justinahinon. View the logs.


2 months ago

This ticket was mentioned in Slack in #core-editor by justinahinon. View the logs.


8 weeks ago

#17 @justinahinon
8 weeks ago

  • Keywords has-dev-note added; needs-dev-note removed
Note: See TracTickets for help on using tickets.