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

allowedBlock attribute implementation at column #18164

Open
wants to merge 3 commits into
base: master
from

Conversation

@JesserH
Copy link

JesserH commented Oct 29, 2019

Fixes #18161

Description

I have developed a solution to the issue where a individual column could not define any allowed blocks and newly added columns in the columns block (from the slider at the columns settings) also specify the allowed blocks.

How has this been tested?

I have tested this locally.

Screenshots

Screenshot 2019-10-29 at 13 54 43

Types of changes

I have added a new attribute called allowedBlocks in both the column and columns block, which allows for defining the allowed blocks per individual column.
I suggest to add documentation to the InnerBlocks ReadMe on GitHub, where the templates are documented about the use of allowedBlocks.

EXAMPLE
You can set this property in for instance a template. Below is an example of how you can provide it to the column and columns block like so:

const allowedBlocks = [
  "cgb/recipe-name-block",
  "cgb/recipe-description-block",
  "cgb/recipe-author-block",
  "cgb/recipe-cuisine-block",
  "cgb/recipe-course-block"
];

//the code below can be used in a template
[ [ 'core/columns', { allowedBlocks }, [
      [ 'core/column', { allowedBlocks }, [
          [ 'cgb/recipe-name-block', { name: attributes.name, allowedBlocks },  ],
      ] ],
      [ 'core/column', { allowedBlocks }, [
        [ 'cgb/recipe-description-block', { recipeDescription: attributes.description, allowedBlocks },  ],          
     ] ],
  ] ] ],

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
Issue: 18161
Copy link
Member

jorgefilipecosta left a comment

Hi @JesserH,
Here we are trying to change a block option, e.g., allows blocks from the outside. So we are solving issue #7931 for a specific case.

The solution we are using here is the addition of attributes. We have cases following the same approach, e.g., the placeholder in paragraphs and headings.

This approach, although working well, is not ideal:

  • attributes are expected to be important for the block output (save), which is not the case.
  • We are also serializing these attributes relevant to edit taking DB space.
  • It presents challenges for block maintainability e.g.: parent block (A) that uses nested columns is updated and changes the columns allowed blocks. On older instances of (A), the columns allowedBlocks continues to be the old one. Users may wonder why the block did not change after a plugin updated.

On #18161 I suggest as a possible solution to the problem having an options mechanism something similar to attributes but not serializable and controlled from templates (e.g., parent templates, CPT templates), or from the data module by dispatching actions. This solution is complex, and we would essentially expand the block API's.

On #17352, I used context as a way to pass options from a parent to a child. The child exposes a component that allows ancestor blocks to configure a set of options. This option has some limitations; it does not allow to set options from a CP or from non-ancestor blocks.

Although the solution here has some inconveniences, the other solutions are not perfect either, because of the complexity or because of limitations.

Personally, I don't have a strong preference for this or for the other two options I referred. I guess we just need a decision on the path to follow. @youknowriad, @gziolo, do you have any preference for one of the options?

packages/block-library/src/columns/edit.js Outdated Show resolved Hide resolved
@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Nov 12, 2019

Personally, I don't have a strong preference for this or for the other two options I referred. I guess we just need a decision on the path to follow. @youknowriad, @gziolo, do you have any preference for one of the options?

I'm exploring how we could integrate Patterns API into blocks and Columns block in particular in #18283. This raises the question if the list of allowed blocks should be part of this proposal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.