-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add context properties to block types REST endpoint #22686
Conversation
Size Change: +218 B (0%) Total Size: 1.12 MB
ℹ️ View Unchanged
|
docs/rfc/block-registration.md
Outdated
* Type: `object` | ||
* Optional | ||
* Localized: No | ||
* Property: `providesContext` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this property map to provides_context
in PHP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this property map to
provides_context
in PHP?
Technically there's no mapping today, but I've mentioned it in the original comment as a potential blocking decision:
A decision at #22519 (comment) in regards to registering block types using snake-cased
provides_context
, rather than camel-casedprovidesContext
.
docs/rfc/block-registration.md
Outdated
* Type: `string[]` | ||
* Optional | ||
* Localized: No | ||
* Property: `context` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like this naming. Context is already in use in the REST API and it reusing this naming is super confusing.
If I make a request to /wp/v2/block-type/?context=edit
what do I get. The request in an edit context and block files by context === edit. Confusing. Can we use another name here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about the naming block_context
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, it's a completely different concept from what REST API uses. It didn't occur to me earlier that the name might be too general, it's more like:
dataContext
orexternalAttributes
providesAttributes
I'm curious to hear how @aduth views it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd consider "context" a fairly generic term of the likes of "type", and the relationship between blocks and the REST API is incidental enough that—outside this specific collision—I can't imagine there'd be a high likelihood for confusion of the two.
Conversely, as I understand from some of early discussions like in #19685, there's an intentional overlap of the name it and the concept of Context in React which it mimics (and uses for implementation in the client).
I'm not especially attached to the name, but it wasn't really the intent of the pull request to be introducing the concept, moreso to bring this document into alignment with what had already been implemented across discussions and iterations of #19685, #19572, and #21467.
There's some interesting merit to thinking about this in terms of "attributes provided from some ancestor" and potentially naming around that, though even that may restrict some options for how context could expand in the future (see #19685 (comment), #19685 (comment)).
Since there's far more impact to a decision than what's affected here, I'd rather weigh it in its own dedicated space (an issue or editor meeting discussion).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Context is already in use in core and to add this here would be really confusing. Please can we just rename it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for adding missing support for the block context. Overall it looks good. We just need to decide whether context
is a good fit here 👍
Per #22686 (comment) and #22686 (comment), I documented default values in d255bb0. A couple additional notes:
|
d255bb0
to
d438cac
Compare
@spacedmonkey, I applied changes to unblock this PR per your feedback. Does it work as is? We still need to decide on about the block registry:
I believe it can be tackled separately though. From the perspective of the REST API endpoint. everything seems fine. |
@aduth Should we be able to filter the block by these context? So add |
e760fd1
to
e5a946c
Compare
Co-authored-by: Miguel Fonseca <[email protected]>
e098182
to
18002bb
Compare
🎉 Nice collab here. |
New block context related fields were added as part of WordPress/gutenberg#22686. This changest backports them to WP_Block_Type class. Props aduth, spacedmonkey, mcsf, epiqueras. Fixes #47656. git-svn-id: https://develop.svn.wordpress.org/trunk@48117 602fd350-edb4-49c9-b593-d223f7449a82
New block context related fields were added as part of WordPress/gutenberg#22686. This changest backports them to WP_Block_Type class. Props aduth, spacedmonkey, mcsf, epiqueras. Fixes #47656. git-svn-id: https://develop.svn.wordpress.org/trunk@48117 602fd350-edb4-49c9-b593-d223f7449a82
New block context related fields were added as part of WordPress/gutenberg#22686. This changest backports them to WP_Block_Type class. Props aduth, spacedmonkey, mcsf, epiqueras. Fixes #47656. Built from https://develop.svn.wordpress.org/trunk@48117 git-svn-id: http://core.svn.wordpress.org/trunk@47886 1a063a9b-81f0-0310-95a4-ce76da25c4cd
New block context related fields were added as part of WordPress/gutenberg#22686. This changest backports them to WP_Block_Type class. Props aduth, spacedmonkey, mcsf, epiqueras. Fixes #47656. Built from https://develop.svn.wordpress.org/trunk@48117 git-svn-id: https://core.svn.wordpress.org/trunk@47886 1a063a9b-81f0-0310-95a4-ce76da25c4cd
New block context related fields were added as part of WordPress/gutenberg#22686. This changest backports them to WP_Block_Type class. Props aduth, spacedmonkey, mcsf, epiqueras. Fixes #47656. git-svn-id: https://develop.svn.wordpress.org/trunk@48117 602fd350-edb4-49c9-b593-d223f7449a82
This pull request seeks to add block context properties to the block types REST controller originally implemented in #21065. Block context documentation was created as part of #21925, but not incorporated into the existing Block Type RFC document. It has been included here alongside the necessary revisions to include the properties in the REST controller.
Status: The implementation should work well enough, though it may warrant being considered blocked by one or both of:
register_block_type_from_metadata
to handle assets #22519 (comment) in regards to registering block types using snake-casedprovides_context
, rather than camel-casedprovidesContext
.provides_context
as an empty object{}
, rather than incorrect array[]
, related to the comment at https://github.com/WordPress/gutenberg/pull/21065/files#r431468417.Testing Instructions:
Ensure tests pass:
Test scenario from #21467 is helpful as well: