Element deletion blockers

[brandonkelly]

Description

Adds the ability for elements to define blockers that should prevent their own deletion.

When the element is deleted via a supporting UI control, the element will be checked for blockers, and if there are any, a modal will be shown to the user that lists them, along with various options to resolve them.

Elements can define their own deletion blockers via the new ElementInterface::deletionBlockers() method, and plugins can register additional blockers via a new Element::EVENT_DEFINE_DELETION_BLOCKERS event.

Element deletion blocker classes must implement craft\elements\deletionblockers\DeletionBlockerInterface. A base implementation is provided by craft\elements\deletionblockers\BaseDeletionBlocker.

See for documentation on blocker/action definitions, and craft\elements\deletionblockers\EntryAuthorsBlocker for an example.

Related issues

• Please provide some way to track asset usage #11934
• [FR] Option to transfer existing relationships to a sibling when deleting an element (Entry/Category/Tag…) #15410
• [4.x]: Deleting user with existing order/subscription shows success message commerce#3070

[i-just]

This looks great!

I only found one proper bug, and the rest are questions/suggestions:

1. it's not possible to delete assets via element index action on this branch (using local FS)
2. when the deletion modal is presented, could we make the whole “accordion” title clickable (to expand), not just the icon?
3. is it intended behaviour that you can’t use double-click to open, e.g. entries in the element index in the deletion modal? (the pencil icon works as expected)
4. lets say you have a setup where some entries were authored by the user you want to delete; is there a reason why the “delete entries” action takes immediate effect, and reassign/remove author ones don’t?
   • if it needs to stay like this, could we tweak the confirmation message to say that this will take immediate effect? (I know most people rarely read those messages at all/in full, but it might be beneficial if/when they do)

[brandonkelly]

lets say you have a setup where some entries were authored by the user you want to delete; is there a reason why the “delete entries” action takes immediate effect, and reassign/remove author ones don’t?

“Reassign” also takes immediate effect; “remove” doesn’t actually do anything and just lets the relationship remove itself on user delete.

The buttons are labelled to imply immediate action will be taken, so in general the behavior should be clear. The exception cases like “remove” should clarify that no action has been taken yet via their resolution message (e.g. “The entries will be updated once the users are deleted.”).