Partially locked template wrongly shows notice about template mismatch

[kraftner]

Description

If a template of a post is only partially locked only the locked sections should be compared with the template for mismatches.

An example:

We have a custom post type with a template and a locked root via 'template_lock' => 'all'. But a group block inside that post is unlocked by e.g. setting 'templateLock' => false.

As soon as another block is added inside that group the block editor thinks the content doesn't match the locked template and shows this notice:

But if a template intentionally makes some inner block areas editable changes to that area should be fine.

---

The problems seems to be that on the top level unlocked templates are considered.

gutenberg/packages/block-editor/src/store/actions.js

Lines 86 to 87 in c1cf175

	// Unlocked templates are considered always valid because they act
	// as default values only.

But this same behavior is not implemented in nested blocks.

I'd assume that at this point

gutenberg/packages/blocks/src/api/templates.js

Lines 26 to 29 in c1cf175

	return (
	name === block.name &&
	doBlocksMatchTemplate( block.innerBlocks, innerBlocksTemplate )
	);

additional checks for unlocked blocks (e.g. for block.attributes.templateLock === false) should be added, ignoring everything inside unlocked blocks.

Step-by-step reproduction instructions

1. Register a custom post type with
   • a template
   • template_lock set to all
   • unlock a block with inner blocks (e.g. core/group) inside the template by setting 'templateLock' => false on it
2. Create a new post of that custom post type
3. Add new blocks inside the unlocked block
4. Save
5. Reload
6. See the notice which doesn't make sense

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress 6.0.2 (without Gutenberg)

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Thelmachido]

Hi @kraftner thank you for giving a detailed report on this one, can you please confirm that the issue is persistent on the recent version of WordPress and Gutenberg?

[kraftner]

@Thelmachido Yes.

I just tried it with WordPress 6.0.2 and Gutenberg 14.1.1 on a fresh install. Same issue.

(Wasn't expecting anything else since the current code referenced above still has the issue.)

[kraftner]

I just wanted to bump this and confirm that the issue still exists at least in WP 6.3.3. Looking at the code that hasn't changed since I reported this issue I am assuming it is also still present in the 6.4 branch and trunk.