Remove locking inheritance. Add template lock attribute to some blocks

[jorgefilipecosta]

Fixes: #23329

This PR removes the locking inheritance. This change may have an impact on existing blocks and CPT templates and needs a dev not.

Besides removing inheritance it implements a mechanism where if a block explicitly contains an attribute with the name templateLock, that attribute is automatically used as the templateLock of the inner blocks area.

Multiple template lock attributes were added to existing blocks. All these changes allow, CPT template creators, blocks, and patterns to explicitly specify the locking of the blocks that are used.

Testing

I verified now locking is not inherited by using sample cpt templates, and sample blocks with inner block templates.

I verified I could control the locking of the group block by using the templateLock attribute.
By pasting the following code on the code editor I verified that the first group block is not locked, while the second group block is locked.

<!-- wp:group -->
<div class="wp-block-group"><div class="wp-block-group__inner-container"><!-- wp:quote -->
<blockquote class="wp-block-quote"><p></p></blockquote>
<!-- /wp:quote --></div></div>
<!-- /wp:group -->

<!-- wp:group {"templateLock":"all"} -->
<div class="wp-block-group"><div class="wp-block-group__inner-container"><!-- wp:quote -->
<blockquote class="wp-block-quote"><p></p></blockquote>
<!-- /wp:quote --></div></div>
<!-- /wp:group -->

[github-actions]

Size Change: +12 B (0%)

Total Size: 1.19 MB

Filename	Size	Change
build/block-editor/index.js	130 kB	-1 B
build/block-library/index.js	145 kB	+18 B (0%)
build/edit-widgets/index.js	21.2 kB	-5 B (0%)

ℹ️ View Unchanged

Filename	Size	Change
build/a11y/index.js	1.14 kB	0 B
build/annotations/index.js	3.52 kB	0 B
build/api-fetch/index.js	3.35 kB	0 B
build/autop/index.js	2.72 kB	0 B
build/blob/index.js	668 B	0 B
build/block-directory/index.js	8.55 kB	0 B
build/block-directory/style-rtl.css	943 B	0 B
build/block-directory/style.css	942 B	0 B
build/block-editor/style-rtl.css	11 kB	0 B
build/block-editor/style.css	11 kB	0 B
build/block-library/editor-rtl.css	8.65 kB	0 B
build/block-library/editor.css	8.65 kB	0 B
build/block-library/style-rtl.css	7.66 kB	0 B
build/block-library/style.css	7.65 kB	0 B
build/block-library/theme-rtl.css	741 B	0 B
build/block-library/theme.css	741 B	0 B
build/block-serialization-default-parser/index.js	1.78 kB	0 B
build/block-serialization-spec-parser/index.js	3.1 kB	0 B
build/blocks/index.js	47.6 kB	0 B
build/components/index.js	169 kB	0 B
build/components/style-rtl.css	15.5 kB	0 B
build/components/style.css	15.5 kB	0 B
build/compose/index.js	9.43 kB	0 B
build/core-data/index.js	12 kB	0 B
build/data-controls/index.js	685 B	0 B
build/data/index.js	8.6 kB	0 B
build/date/index.js	31.9 kB	0 B
build/deprecated/index.js	772 B	0 B
build/dom-ready/index.js	568 B	0 B
build/dom/index.js	4.42 kB	0 B
build/edit-navigation/index.js	10.6 kB	0 B
build/edit-navigation/style-rtl.css	868 B	0 B
build/edit-navigation/style.css	871 B	0 B
build/edit-post/index.js	306 kB	0 B
build/edit-post/style-rtl.css	6.29 kB	0 B
build/edit-post/style.css	6.28 kB	0 B
build/edit-site/index.js	20.9 kB	0 B
build/edit-site/style-rtl.css	3.73 kB	0 B
build/edit-site/style.css	3.73 kB	0 B
build/edit-widgets/style-rtl.css	3.02 kB	0 B
build/edit-widgets/style.css	3.02 kB	0 B
build/editor/editor-styles-rtl.css	492 B	0 B
build/editor/editor-styles.css	493 B	0 B
build/editor/index.js	45.5 kB	0 B
build/editor/style-rtl.css	3.85 kB	0 B
build/editor/style.css	3.84 kB	0 B
build/element/index.js	4.45 kB	0 B
build/escape-html/index.js	734 B	0 B
build/format-library/index.js	7.49 kB	0 B
build/format-library/style-rtl.css	547 B	0 B
build/format-library/style.css	548 B	0 B
build/hooks/index.js	1.74 kB	0 B
build/html-entities/index.js	621 B	0 B
build/i18n/index.js	3.54 kB	0 B
build/is-shallow-equal/index.js	710 B	0 B
build/keyboard-shortcuts/index.js	2.39 kB	0 B
build/keycodes/index.js	1.85 kB	0 B
build/list-reusable-blocks/index.js	3.02 kB	0 B
build/list-reusable-blocks/style-rtl.css	476 B	0 B
build/list-reusable-blocks/style.css	476 B	0 B
build/media-utils/index.js	5.13 kB	0 B
build/notices/index.js	1.69 kB	0 B
build/nux/index.js	3.27 kB	0 B
build/nux/style-rtl.css	671 B	0 B
build/nux/style.css	668 B	0 B
build/plugins/index.js	2.44 kB	0 B
build/primitives/index.js	1.34 kB	0 B
build/priority-queue/index.js	790 B	0 B
build/redux-routine/index.js	2.85 kB	0 B
build/rich-text/index.js	13 kB	0 B
build/server-side-render/index.js	2.6 kB	0 B
build/shortcode/index.js	1.7 kB	0 B
build/token-list/index.js	1.24 kB	0 B
build/url/index.js	4.06 kB	0 B
build/viewport/index.js	1.74 kB	0 B
build/warning/index.js	1.14 kB	0 B
build/wordcount/index.js	1.17 kB	0 B

_{compressed-size-action}

[youknowriad]

Besides removing inheritance it implements a mechanism where if a block explicitly contains an attribute with the name templateLock, that attribute is automatically used as the templateLock of the inner blocks area.

Do we want this to be automatic or should it be a support flag or something?

[jorgefilipecosta]

Besides removing inheritance it implements a mechanism where if a block explicitly contains an attribute with the name templateLock, that attribute is automatically used as the templateLock of the inner blocks area.

Do we want this to be automatic or should it be a support flag or something?

Hi @youknowriad,

I think it should be automatic, I don't think we will have a case where:

• A block uses inner blocks.
• A block does not pass a templateLock to inner blocks.
• A block has a templateLock attribute, and the blocks not want the templateLock attribute to be the templateLock of inner blocks.

I think we don't need a support flag for this the fact the block adds a templateLock attribute is already an opt-in for this system.

I guess the supports flag would make sense if with the flag we remove the need to add the attribute. Adding the support flag would automatically add the attribute. Would you prefer this approach?

[youknowriad]

I guess the supports flag would make sense if with the flag we remove the need to add the attribute. Adding the support flag would automatically add the attribute. Would you prefer this approach?

I'm not sure yet, I'm still trying to understand the consequences. Also, I think we probably need something similar for allowedBlocks don't you think if we go the "API" route? Do you think it makes sense to start small and only add support for this in specific blocks (say column, and group)

[jorgefilipecosta]

Do you think it makes sense to start small and only add support for this in specific blocks (say column, and group)

Hi @youknowriad,

So if we followed this approach. We would remove:
Remove templateLock inheritance from all the blocks.
Not have any system that automatically uses templateLock Attribute.
On the columns and group blocks we would manually pass the templateLock attribute to InnerBlocks templateLock property.

Would you be able to confirm if this matches your idea? It seems like a safe and good first step.

[youknowriad]

@jorgefilipecosta yes, it does.

[youknowriad]

It is potentially impactful though, so I'm wondering whether we should include on 5.6 or not.

[jorgefilipecosta]

For 5.6 we decided to test the attributes mechanism on columns and group block and remove any breaking changes like the inheritance removal to test this system so I'm closing this PR.

[jorgefilipecosta]

The attribute addition to columns and groups is proposed at #26128.