Reusable block: Add a lock to the parent toolbar to protect the inner content from accidental editing.

[paaljoachim]

Description

There has been multiple complaints of accidental changes with the Reusable block in WP 5.7. In earlier versions we had an edit button protecting the inner blocks, but in 5.7 the edit button was removed. Making a one click directly into the Reusable block inner content.

Step-by-step reproduction instructions

1. In WP 5.7.
2. Add a Reusable block.
3. Click the Reusable block.
4. Make a change.
5. Do other changes to the page.
6. Click save.

Expected behaviour

In WP 5.6. There was an edit icon one had to click to edit the contents. Protecting against accidental changes.
I expected to see also a protective measure in WP 5.7 that protected the content.

Actual behaviour

I happen to make a change and save it.

A possible solution is to add back a kind of edit/lock button.
Here is an example.

Unlock-to-edit-Reusable-block-contents.mp4

WordPress information

• WordPress version: 5.7.2
• Gutenberg version: Not active
• Are all plugins except Gutenberg deactivated? No plugin active
• Are you using a default theme (e.g. Twenty Twenty-One)? Twenty Twenty One.

Associated issues:
Improvements to Reusable Blocks
#27890

Reusable block: A suggestion for a new revision.
#31163

Try: Obscure edit-ability of post content blocks in the template editor (linking to my comment).
#31461 (comment)

On Locking and TemplateLocking
#29864

[paaljoachim]

We have a few things happening.

A click through approach is being worked on. Located here (linking to a comment I made showing a video on how it works) #31109 (comment)

One selects/clicks and it will automatically select the top most container/parent block. Clicking again clicks into the inner contents.

Having a lock and a click through approach would be a helpful mix.

[peterwilsoncc]

Thanks Paal,

I've been coordinating the 5.7.x minors and it would be great if this could be done as a half way step between the larger proposal to be backported in to the wp/5.7 branch. There have been a few issues raised on trac about difficulties people are having in 5.7 so putting in some improvement would be most helpful.

[cpsyctc]

I am not a programmer but a very frustrated user who has now lost hours trying to use reusable blocks for an obvious task for them where they should have saved me hours. I am sure the following are vital:

• The ability to create unnamed reusable blocks was dangerous and should be removed.
• I think there's a fundamental mistake in treating editing reusable blocks as something not much different to editing any other block in a page: to me they are completely different things. Editing a page or post is about that unique entity, editing a reusable block is changing a building block that may be in use elsewhere.
• We should be able to list and preview (but probably not edit, to avoid locking issues) reusable blocks independent of editing a page. I want to be able to go and check out what reusable usable blocks I have without losing what I have done in a page.
• For me (5.7.2, using reusable blocks for the first time but working on pages created in probably 5.6) the "convert to ordinary block" which is a vital option, seems to be erratically visible. This may be a corner case relating to the reusable block I was trying to use being a three column block.
• Surely if a reusable block has already been used in any other page/post it should be locked and you should be prompted if you try to edit it and warned that any edit will immediately change all other uses of the block? I would expect a dialogue to come up asking if I'm sure I want to edit the reusable block and offering to convert to an ordinary block.
• Related to that, if I have fallen into the trap of editing a reusable block within a page and I hit the update (or publish) button the current actions seem to me to be broken as they simply don't seem to successfully separate the two saving issues. I would have expected the prompt against any reusable block (I have only ever used one on a page but presumably you could have used more than one) to prompt again with a clear warning and option to convert to an ordinary block.

To me these seem to be desperately serious faults in the current set up. I hope they will be fixed soon. TIA.

[thisissandip]

Unlock Icon is not available in @wordpress/icons package.
So as of now, I have used plain text to display the lock and unlock state in the toolbar.

[jasmussen]

Which "unlock" icon are you referring to?

I found this lock icon in the icons package:

Edit: I'm also happy to help if we need to add anything to the library.

[thisissandip]

In the example video above,
To display the lock state, the lock icon from Dashicons is used.

And for the unlocking state, the unlock icon is used.

I was looking for similar icons in the icons package but only found the lock icon and not the unlock one.
It'd be great to have an unlock icon in the package too!

[paaljoachim]

EDIT: I moved my reply to @cpsyctc to this issue:
#31163 (comment)

I am working on keeping feedback to issues that already has various feedback.

[paaljoachim]

A PR has been added here:
#32710

[critterverse]

Hi all, just left a note in #32710 (comment) but also wanted to highlight a potential improvement available in #31109. In my opinion, the clickthrough approach doesn't resolve all of the known issues with the Reusable block but it's a big improvement over where we are currently!

[paaljoachim]

I have left a couple of comments directly in the PR. The latest is here: #32710 (comment)
Where I create a suggestion using click through and a lock.
See the comment for additional information.

[arnemulder]

I really think that editing a reusable content block shouldn't be taken lightly. It should be done on a central place instead of in the context of a post or page that uses that reusable block. A clickthrough isn't enough imo. The lock is a far better idea, but still less protection than the old method of a separate post type to edit outside of the post or page that holds the reusable block. Access to the reusable content blocks to edit was a bit cubersome, but it was well protected outside of the context of a specific post.

[paaljoachim]

I want to add @pwkip Jules comment from:
Add Reusable block save button, snackbar on save and Welcome Guide PR
(Which is ready for a last test and a code review before it is merged.)
#32464 (comment)

Since the save button is in place now, what about changing it to an "Edit" button initially, then once you click it, the block becomes editable and the button changes to the Save button?

It is an intriguing idea. Something to look more into later after the above PR has been merged.

[BenWittert]

+1 for this issue.

I have a large enterprise client who is experiencing significant issues related to content writers frequently accidentally editing reusable blocks as it is not clearly differentiated from their article content.

Our client considers this to be a huge issue, and they feel that reusable blocks are no longer fit for purpose in their current state and not usable for large enterprise businesses.

[paaljoachim]

@Mamaduka George is working on adding a lock to Reusable blocks in this PR:
#39950

It can use some feedback!

[paaljoachim]

I just want to inform everyone on this thread that the first version of locking a Reusable block is in place.
A NB! though. This will only lock an instance and not all identical Reusable blocks. This means if a Reusable block has been placed into the content and edit locked that it is not editable.

This means to protect the site we need to first add the Reusable block into the content and lock it. Then we can let the user loose on the content without risking an accidental change.

[BenWittert]

This means to protect the site we need to first add the Reusable block into the content and lock it.

@paaljoachim is this the intended final implementation style for the block lock? Or may it be possible in the future to set all instances to locked?

[paaljoachim]

Hey Ben

is this the intended final implementation style for the block lock?

No. This is just one important step.

Or may it be possible in the future to set all instances to locked?

There are plans to explore how global lock will work.

The following is a comment by @jameskoster
#39950 (comment)

I think it's probably a good idea to explore the default lock status separately.

On the surface it may seem a good idea, but there is nuance to consider – is the locking local or global? What level of locking do we apply, just movement, just editing, everything? Should there be an Editor setting to configure the default? There are also initiatives like #39281 which may change how we feel.