[wp-trac] [WordPress Trac] #36860: Introduce filter for users_have_content within delete action of users.php

[WordPress Trac]

#36860: Introduce filter for users_have_content within delete action of users.php
-------------------------------------------------+-------------------------
 Reporter:  garrett-eclipse                      |       Owner:  garrett-
                                                 |  eclipse
     Type:  enhancement                          |      Status:  accepted
 Priority:  normal                               |   Milestone:  5.2
Component:  Users                                |     Version:  4.6
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing 2nd-opinion  |     Focuses:
  dev-feedback                                   |  administration
-------------------------------------------------+-------------------------
Changes (by garrett-eclipse):

 * keywords:  has-patch needs-testing => has-patch needs-testing 2nd-opinion
     dev-feedback


Comment:

 Replying to [comment:18 birgire]:
 > Thanks @garrett-eclipse for that information and it's informative to see
 how plugins are handling it.
 >
 > One thing that might be confusing with the current patch
 [attachment:"36860.5.diff"] is that if we use e.g.:
 >
 > {{{
 > add_filter( 'users_have_content', '__return_false' );
 > }}}
 >
 > The developer might think it's being overriden by the filter, but we
 still get the UI for reassigning/removing user data, even if the deleted
 user is post author or link owner.
 >
 > Another approach, if we want to allow the filter to control the UI both
 ways, is to have the default filter value as {{{null}}} and only run the
 {{{post_author}}} and {{{link_owner}}} queries for {{{null}}}. That way
 the boolean value of the filter can be used to turn it on/off.
 >
 > Do you see any reason to know that the user is being deleted from this
 UI, compared to e.g. other {{{wp_delete_user()}}} calls elsewhere?

 Thanks for the feedback @birgire I'd initially been going down the
 approach to allowing the plugin/customization to have full control but as
 I mentioned in my second comment I wanted to avoid plugins suppressing the
 WordPress checks as it can potentially lose users content.

 Reference to [comment:2 comment#2]:
 > I placed the filter prior to the WordPress checks to avoid plugins
 suppressing them and possibly losing users content. If needed another
 filter can be added after to support suppression but I fear that may have
 negative consequences.

 Mainly I wanted to avoid unintentional data loss but am open to further
 discussion. The other idea above about another filter if suppression is
 desired could be avoided by using your null approach there.

 Adding `dev-feedback`/`2nd-opinion` to get some more input so we can make
 a decision and hopefully still get this in by Thursday.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/36860#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform