WordPress.org

Make WordPress Core

Opened 3 months ago

Last modified 2 months ago

#53613 new enhancement

Add filter to prevent term deletion

Reported by: davedoesthings Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Taxonomy Keywords: has-patch 2nd-opinion
Focuses: Cc:

Description

Currently, the developer UX for wp_delete_term is not ideal when attempting to prevent term deletion.

In order to prevent a term from being deleted e.g. to implement "protected" terms, you must essentially throw a wp_die() call from within a pre_delete_term action callback.

This isn't ideal, and isn't consistent with other, similar implementations such as the pre_delete_post filter in wp_delete_post.

I propose that a filter should be introduced that fires before pre_delete_term and offers like-for-like functionality.

Unfortunately, pre_delete_term -- the most appropriate name for this filter -- is already used by the action, therefore I propose pre_term_deletion or similar.

I have a patch ready which will be attached shortly.

Thanks,
Dave

Attachments (1)

53613-pre-term-deletion.diff (742 bytes) - added by davedoesthings 3 months ago.
Patch

Download all attachments as: .zip

Change History (4)

#1 @sabernhardt
3 months ago

  • Keywords has-patch added; needs-patch removed
  • Version trunk deleted

#2 @jorbin
3 months ago

  • Keywords 2nd-opinion added

Welcome to trac @davedoesthings.

I'm not sure if I love the idea of adding an additional filter here for this use case. Core only calls wp_delete_term in a couple of places, each of them has a check for the delete_term capability. I feel like using the map_meta_cap filter might lead to a better result since then the UI would also be updated to not display the trash link.

the pre_delete_post bailout was added since deleting a post can be resource-intensive, especially on some custom sites. #32933.

I wonder if there are other use cases for this filter that map_meta_cap wouldn't be able to solve.

#3 @davedoesthings
2 months ago

Thanks @jorbin, map_meta_cap does indeed resolve the original need here, thanks for the suggestion!

I think that filter could use some additional documentation, I may raise a meta trac ticket. Either that or leave some examples on that page; some were included in a release post that John Blackbourn made a while ago.

In terms of additional use cases, does the use of map_meta_cap cover off any programmatical rather than manual deletions? This is the only other use case I can think of right now.

Note: See TracTickets for help on using tickets.