Block.json: Add ancestor prop to schema
#39894
Conversation
|
Size Change: +408 B (0%) Total Size: 1.22 MB
ℹ️ View Unchanged
|
|
Hey ya 👋 I need some answers before continue with this PR. The promblem is, with this implementation, blocks with the
|
DAreRodz
added
[Feature] Block API
If it doesn't work with a local $schema file, maybe it's not related to the schema. |
|
@DAreRodz, you need to ensure that the gutenberg/packages/blocks/src/api/registration.js Lines 154 to 168 in 16b89d6 It's a bit of work to add new fields to Block API because it needs to be wired with the block registration functions, classes, and the REST API endpoint. There is also some legacy function that exposes only certain fields to the client from the server. |
|
Oh, I see, I noticed, for example, that the function Anyway, I've added the polyfil and everything works now. Thanks for the tip, @gziolo. 😁 |
DAreRodz
requested review from
ellatrix,
ajitbohra,
ajlende and
mkaz
as code owners
DAreRodz
requested review from
luisherranz,
ockham,
gziolo and
cbravobernal
and removed request for
ockham and
cbravobernal
| @@ -1382,10 +1382,28 @@ const canInsertBlockTypeUnmemoized = ( | |||
| parentName | |||
| ); | |||
|
|
|||
| let hasBlockAllowedAncestor = true; | |||
There was a problem hiding this comment.
Hi!
Do we need a default value here?
There was a problem hiding this comment.
Yes because if not canInsert will always be false if blockType.ancestor is falsy.
|
@youknowriad, I looked at performance metrics reported on CI and I didn’t see any differences for the inserter’s performance. Can you confirm this new API is good to land from that perspective? |
There was a problem hiding this comment.
No concern from me in terms of performance. I'd like us to think more about this API in relationship to all the other APIs to allow/disallow blocks. Maybe we need some docs with all the APIs (parent, allowedBlocks prop, allowed block setting, ancestor...) We should explain the use-case of each one, and how it differs compared to the others.
Merging the PR in that case. Thanks for your reviews, folks. 😄
@youknowriad, regarding that, should we update some docs before releasing 6.0? Just asking because the only docs I wrote were the |
|
Yes, I think at least we should document this similar to how we document parent https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/#parent Also I believe we need a dedicated page or section somewhere in the handbook, to explain all the different APIs about allowing/hiding blocks and how they relate and differ. |
Adds documentation for the new API added in #39894
|
@fabiankaegy opened #40027 to extend the documentation for the block metadata. We still will need to update WordPress core so this new field is handled in |
bph
added
the
Needs Dev Note
@gziolo I've opened a Trac ticket 👉 https://core.trac.wordpress.org/ticket/55531#ticket |
Excellent, I will have a look today. |
The `ancestor` field was recently added to the `block.json` schema in Gutenberg. See: WordPress/gutenberg#39894. Props darerodz. Fixes #55531. git-svn-id: https://develop.svn.wordpress.org/trunk@53084 602fd350-edb4-49c9-b593-d223f7449a82
|
I committed the relared PHP changes in WordPress core in https://core.trac.wordpress.org/changeset/53084. Awesome work @DAreRodz 💯 |
The `ancestor` field was recently added to the `block.json` schema in Gutenberg. See: WordPress/gutenberg#39894. Props darerodz. Fixes #55531. Built from https://develop.svn.wordpress.org/trunk@53084 git-svn-id: http://core.svn.wordpress.org/trunk@52673 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `ancestor` field was recently added to the `block.json` schema in Gutenberg. See: WordPress/gutenberg#39894. Props darerodz. Fixes #55531. Built from https://develop.svn.wordpress.org/trunk@53084 git-svn-id: https://core.svn.wordpress.org/trunk@52673 1a063a9b-81f0-0310-95a4-ce76da25c4cd
) * Add documentation for `ancestor` property Adds documentation for the new API added in #39894 * Update docs/reference-guides/block-api/block-metadata.md Co-authored-by: Greg Ziółkowski <grzegorz@gziolo.pl> * Add ancestors example in innerblocks tutorial Co-authored-by: Greg Ziółkowski <grzegorz@gziolo.pl> Co-authored-by: Luis Herranz <luisherranz@gmail.com>
|
Hi everybody, I know this is already closed and merged, but could this functionality be ported to My issue (#48296) is that I would like to add Can someone please look whether this PR can be adapted to |
|
👋 @webmandesign it happened to have opened a PR about that here: #48348. We can continue the discussion there. |
|
Cool! Thanks @ntsekouras for pointing this out! |
What?
This PR adds a new property to the
block.jsonschema calledancestor. Similar toparent, this prop would permit blocks to restrict which blocks they can be inserted into, but allowing other blocks to be placed between them in the block tree (e.g. Group, Columns, etc.).It also adds the
ancestorprop to those Comment blocks that need it:Why?
Editor users may want to customize the Comment Template layout, so most of the Comment block would need this restriction. This restriction cannot be defined with the current API.
Will close #37181.
How?
ancestorto theblock.jsonschema.ancestorproperty insidecanInsertBlockTypeUnmemoized()selector, the function that decides if a specific block can be inserted or not.ancestorprop insideunstable__bootstrapServerSideBlockDefinitions(), updating the server-side definition of blocks.Testing Instructions