Add context properties to block types REST endpoint #22686
Conversation
aduth
added
[Type] Enhancement
aduth
requested review from
ajitbohra,
chrisvanpatten and
TimothyBJacobs
as code owners
|
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.
Does this property map to provides_context in PHP?
There was a problem hiding this comment.
Does this property map to
provides_contextin 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.
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.
How about the naming block_context?
There was a problem hiding this comment.
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:
dataContextorexternalAttributesprovidesAttributes
I'm curious to hear how @aduth views it.
There was a problem hiding this comment.
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.
Context is already in use in core and to add this here would be really confusing. Please can we just rename it?
|
Per #22686 (comment) and #22686 (comment), I documented default values in d255bb0. A couple additional notes:
|
gziolo
force-pushed
the
add/block-types-context-fields
branch
from
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 |
gziolo
force-pushed
the
add/block-types-context-fields
branch
2 times, most recently
from
e760fd1
to
e5a946c
Compare
Co-authored-by: Miguel Fonseca <miguelcsf@gmail.com>
gziolo
force-pushed
the
add/block-types-context-fields
branch
from
e098182
to
18002bb
Compare
🎉 Nice collab here. |
gziolo
added
the
Backport to WP 6.7 Beta/RC
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
gziolo
removed
the
Backport to WP 6.7 Beta/RC
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_metadatato handle assets #22519 (comment) in regards to registering block types using snake-casedprovides_context, rather than camel-casedprovidesContext.provides_contextas 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: