Skip to content
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

Define allowed inner blocks in register of block type #16560

Closed
spacedmonkey opened this issue Jul 12, 2019 · 5 comments
Closed

Define allowed inner blocks in register of block type #16560

spacedmonkey opened this issue Jul 12, 2019 · 5 comments
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Extensibility The ability to extend blocks or the editing experience [Status] In Progress Tracking issues with work in progress [Type] Enhancement A suggestion for improvement.

Comments

@spacedmonkey
Copy link
Member

As detailed in #13955 there is currently no way to filter the allowed block in a inner block area. Allowed blocks are stored in a none filterable array variable. See these examples.

Even finding which blocks are available requires you to dig through code.

Describe the solution you'd like
The allowed inner block should be defined when the block is registered. A new children or innerBlocks field could be added when a block is registered. This would mean, that this information would be available to all parts of gutenberg. This data could be exposed in the up coming blocks api, as this data would be useful to the mobile team.

Following the naming pattern of children would match with existing parent field for child block, already found in gutenberg.

@swissspidy swissspidy added [Feature] Block API API that allows to express the block paradigm. [Type] Enhancement A suggestion for improvement. labels Jul 12, 2019
@gziolo gziolo added the [Feature] Extensibility The ability to extend blocks or the editing experience label Jul 12, 2019
@spacedmonkey
Copy link
Member Author

I spent on sometime today. What I worked on was the following.

Added a new field called innerBlocks in the block.json file for cover, media + text and columns.

In the edit function, I type to get the block type so I could read the innerBlock values and as attributes to Innerblocks. However, it didn't work, as blockType was not yet defined. I wanted to blocks.registerBlockType to make the innerblock values filterable.

Next port of call, is to make the args to innerblock type filterable. But I don't love this solution.

@chriscasper
Copy link

Any update to this?

@skorasaurus
Copy link
Member

Any update to this?

@chriscasper this is being worked on at #58262

@jsnajdr
Copy link
Member

jsnajdr commented Jan 26, 2024

Reading @spacedmonkey's notes from 5 years ago, it's notable how much Gutenberg has changed since then. Today it was a very straightforward addition, there's no problem accessing blockType.children everywhere I need it.

@gziolo gziolo added the [Status] In Progress Tracking issues with work in progress label Jan 30, 2024
@skorasaurus
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Extensibility The ability to extend blocks or the editing experience [Status] In Progress Tracking issues with work in progress [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

6 participants