contentOnly template lock can be lost

[stokesman]

Description

When editing/modifying a block with templateLock: contentOnly it's possible to cause a loss of the attribute by updating while the editing mode is engaged. It’s happened to me at least once.

Step-by-step reproduction instructions

<!-- wp:group {"templateLock":"contentOnly","layout":{"type":"flex","flexWrap":"nowrap"}} -->
<div class="wp-block-group"><!-- wp:list {"style":{"layout":{"selfStretch":"fixed","flexSize":"50%"}}} -->
<ul><!-- wp:list-item -->
<li>one</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>two</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>three</li>
<!-- /wp:list-item --></ul>
<!-- /wp:list -->

<!-- wp:image {"style":{"layout":{"selfStretch":"fill"}},"className":"is-style-default"} -->
<figure class="wp-block-image is-style-default"><img alt=""/></figure>
<!-- /wp:image --></div>
<!-- /wp:group -->

1. In the Post Editor, paste the above code
2. Select the Group (Row) block
3. Pick “Modify” from the block “Options” menu
4. (Optional, merely to enable the “Update” button) change content or a setting of the group or one of its children
5. Update/save the post without first exiting the editing mode
6. Refresh the editor
7. Note that the block is no longer contentOnly

Screenshots, screen recording, code snippet

loss-of-contentOnly.mp4

Environment info

• WordPress 6.1-alpha-53714 running Twenty Twenty-Two theme
• Chrome
• macOS

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

Yes

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

No

[Thelmachido]

For now, users still have the freedom to leave this locked mode by pressing modify. When modify is pressed, the block editor shows the hierarchy, and the user has complete control. For now, any user can press the modify button. In the future, it may depend on the capabilities of the user.

Hi @stokesman when I click modify I can edit as well, however, following the conversation on locking updates you can opt-out of the locked mode by clicking modify on blocks.

Not sure this can be considered as a bug, looping in @jorgefilipecosta to review

[stokesman]

Thank you @Thelmachido. Since I'm not sure I’ve made this clear I hope to clarify.

1. It seems that pressing modify is intended to temporarily unlock the block.
2. Saving the post before disengaging the mode saves the block with the lock removed.

My expectation is that pressing modify to unlock the block is not part of its savable state. Among the things supporting that expectation is that it does not create entry in the history stack, i.e. it's not an edit.

[franzaurus]

I think I understand what @stokesman mean.

I find that the contentOnly lock mode disengagement issue only came up if I reload the Post Editor without first clicking "Done" on the said locked block after modifying it.

Perhaps this issue could be counted as a bug or at least a usability issue.

Steps to reproduce

1. Edit a block with contentOnly locked
2. Click "Modify"
3. Edit the content e.g the text or change its background color
4. Click "Update"
5. Without clicking "Done" on the locked block, reload the Post Editor
6. Observe the contentOnly locked block is now a regular (unlocked) block

The issue, however, doesn't happen if on step 5 I managed to click "Done" after modifying the said locked block because doing so will preserve the lock.

Environment
WordPress 6.2 RC2, TT3 theme without Gutenberg installed.
WordPress 6.1.1, TT3 with Gutenberg 15.3.1 installed.

Modify the contentOnly locked block without clicking "Done" afterwards.

Modify the contentOnly locked block and click "Done" afterwards.

[jorgefilipecosta]

This seems like a bug, ideally, when pressing save we would revert the block back to content locked before saving.

[talldan]

Pressing 'Modify' unsets the contentLock attribute, and 'Done' sets it back again. So when saving content lock will be made inactive unless you click 'Done' first.

I think the best thing would be for 'modify' not to change the block attribute, instead it could set a value that isn't persisted (either a useState value or something in the block-editor store).