Allow block creators to disable block deletion via block support.

[noahtallen]

Description

Allow block developers to disable the ability to delete a specific block via block supports.

Some issues with this approach:

1. Existing code like this appears to remove the button entirely instead of disabling it. For our use case, we would like to disable the button instead of removing it. Should that be done differently?
2. The user can still delete the block using the code editor. I think the solution to this would be improving the block template API to support block removal.
3. I need to figure out how to dynamically disable these buttons. For example, I'll need to turn on block removal if a condition is met.

How has this been tested?

1. Tested in my local environment.
2. Existing tests should pass.

To test this yourself, create a new block with supports: { removal: false }. Insert the block into the editor and make sure you cannot delete it with backspace or through the UI.

Screenshots

Types of changes

New feature.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

Resolves #16364

[noahtallen]

The eventual UI of the block I'm creating is supposed to look like this:

I saw #7199 in which there is a lengthy conversation about options for extending the block menu. Was there ever a followup or do we need to make one?

[chrisvanpatten]

Should be noted that this also relates loosely to #16678 and #8112. I’d love to see this addressed holistically, to cover the various use-cases around how various block “actions” are available and unavailable, whether via Inserter or in the context of an InnerBlocks area. Support is currently somewhat patchy and inconsistent, unfortunately.

[noahtallen]

Yeah, that's a great point. I think the block template API is very limited at the moment and can work in unexpected ways (see #11681 as well!). As the stuff you linked to develops, different UI elements could be covered - for example the remove button doesn't exist if the block can't do the remove action.

I think also beyond that, there is a use case for individual blocks dynamically modifying the actions available. For example, the main goal of this PR is to allow a developer to dynamically disable the remove block action for a single block if a condition is not met. The current code is pretty limited in that regard, so I'll have to rework some aspects of this.

[noahtallen]

in php, we might use a filter:

$disabled = apply_filters( 'should_disable_block_remove_button', false, $block_name );

I wonder what the best approach for doing something like that would be here. I'm familiar-ish with slot fill, but not familiar with JS filters/actions in Gutenberg.

Do we need to implement a store for something like how we remove settings panels?

[noahtallen]

It seems what I "really" want here is to be able to apply something like a templateLock='all' to a single block. Sort of like allowedBlocks=self, and template=self. Hm. I'm not sure what the way forward is here. Our use case is the following:

1. Disable the block removal button (but not hiding it)
2. Showing a message by the block removal button to say why the user cannot remove the block.
3. Show a popup or notice of some sort if the user tries to remove the block via delete or via the code editor.

I'm not sure that working on a new allowedActions API is in scope for just this, since that would probably primarily be for InnerBlocks. Is the solution to extend some of the template concepts to the individual block level? Or just do a simple supports thing as we've done here, and then use another SlotFill to show a message?

[noahtallen]

I'm following up on this over here: #11681 (comment)

IMO we need to fix the underlying inflexibility of the block template API so that it's easy to add things like this to it :)

[noahtallen]

No longer relevant. I still think this is worth visiting in the future, but will need to put more thought into it when I'm working on something that more closely relates to this :)