Inconsistent behaviour when using group and columns block with template_lock = 'all'

[Retrofitterdk]

Describe the bug
It looks to me like the columns block and group block are treated differently, when added to a block template and using template_lock = 'all'

It seems like it’s possible to add innerblocks to the columns block, but not to the group block. Strangely enough it seems possible to add inner blocks to the group block, when it itself is added inside a column.

I’m uncertain whether this is a bug or intended behaviour, but if intended it seems like inconsistent behaviour to me.

(It is also very possible, that I’m just not creating the block template in a correct manner.)

To reproduce
Steps to reproduce the behavior:

1. Create a block template with both a column block and group block.

function myplugin_register_template() {
  $post_type_object = get_post_type_object( 'post' );
  $template = array(
    array( 'core/columns', array(), array(
      array( 'core/column', array(), array(
        array( 'core/group', array(), array(
          array( 'core/paragraph', array(
            'placeholder' => 'Add a inner paragraph'
          ) ),
        ) ),
      ) ),
      array( 'core/column', array(), array(
        array( 'core/paragraph', array(
          'placeholder' => 'Add a inner paragraph'
        ) ),
      ) ),
    ) ),
    array( 'core/group', array(), array(
      array( 'core/paragraph', array(
        'placeholder' => 'Add a inner paragraph'
      ) ),
    ) ),
  );
  $post_type_object->template = $template;
  $post_type_object->template_lock = 'all';
}
add_action( 'init', 'myplugin_register_template' );

2. Create new post
3. Successfully try to add new inner block in a column
4. Unsuccessfully try to add new inner block in the group block

Expected behavior
i would expect that both group and columns block are treated like containers that has their own setting for adding inner blocks, and that they would both allow innerblocks to be added regardless of the template settings.

Screenshots

Desktop (please complete the following information):

• OS: MacOS
• Browser Safari
• Version 12.1.2

Additional context

• Gutenberg 6.4.0

[oxyc]

I can confirm this but I disagree with the expected behavior. I would expect the lock to be inherited to all blocks unless somehow indicated as a property on the container.

[Retrofitterdk]

Inconsistency was the main problem, so fixing that removes a source of confusion.

And I can see, that logically template_lock = 'all' should actually mean lock all blocks, but it also underscores the lack of flexibility provided template_lock. #5208

Say I want to create block template for a portfolio, and I want two group blocks. One for a description and one for some meta data about the portfolio item.

I don’t want the user to move the two group blocks around, so I set template_lock = 'all'.

This would work fine for the group block with the specific meta data, but for the free form description I would want to allow, that the user inserts any block type into the group block.

If understand it correctly this would require, that I – somehow in the block template – could change the property of one of the group blocks, but not the other.

I don’t know if that is even possible. I have yet to find any documentation of how it should be done.

[rdswd]

I believe that the Columns block sets templateLock="all" which overrides any parent settings (to control only allowing the column block). Then the individual column blocks set the templateLock={ false } which overrides any parent setting. So any parent settings on columns are overridden two times. It would be great if we could set templateLock on child blocks in the template. I.e. array( 'core/group', array( 'templateLock => 'false' ), array(... or array( 'core/column', array( 'templateLock' => 'false'),.... Or maybe using the block filters will provide a way to change the templateLock?

I believe the only work around is to create core-like custom blocks with your own template locks.

[Retrofitterdk]

I believe the only work around is to create core-like custom blocks with your own template locks.

Sure, but creating af custom block almost identical to the group block doesn’t strike me as a very elegant way to solve this challenge.

[rdswd]

Absolutely agree. Looks like there's some movement on this: #9386
A lot of people, myself included, are having trouble with templateLock: not being able to override core block settings, and not having enough control of what it does. I'd follow #8112 as well.

[sailormary13]

I'm also running into this issue. I have a custom block that is very similar to the core group block-- many other types of blocks can be inserted into it.

I created a template for my posts that contains my custom block. I used template_lock = 'all' on this template because I don't want the authors to add or move or do anything but use the template.

Unfortunately, using template_lock = 'all' not only disallows other blocks from being added to the post, but it also disallows blocks from being added to my custom block, which makes it totally unusable.

[rdswd]

@sailormary13 I believe if you add templateLock="false" to your custom block, it will override the post template lock. So your top level will be locked but your custom block will not be. However, there is a bug that will show an error on save (with a workaround). Read this, it is exactly what you're trying to do. #11681

[sailormary13]

@rdswd Thank you! Yep, that's the issue. Too bad about the error on save, but great to see folks working on it! :)

[youknowriad]

As discussed on #23329 it seems the path forward here is to add a templateLock attribute to container blocks and remove lock inheritance. Instead each template could define precisely how to lock a give a block.