Deleting a user without reassigning should have clearer messaging about the implications

[jtsternberg]

Just this morning, a client deleted a user and elected to NOT reassign the user's content, as the user had no posts assigned to them. This resulted in a mass-deletion of attachments which that editor had uploaded. There should at least be some language that indicates the danger of deleting a user without reassigning. Even when you click to 'permanently delete' an attachment, you get a javascript alert.

The current terminology "What should be done with content owned by this user?" is too innocuous. Ideally, WordPress would indicate which post types would be deleted with that user (by checking the delete_with_user post_type object parameter), along with a count of the number of items in that post type.

[bradparbs]

+1 to this.

[williamsba1]

Completely agree! I would bet most users aren't thinking of attachments as content, so this is a very bad experience for an end-user.

[coreymcollins]

+1 all the way. I feel as though previous versions of WordPress would at least tell you how many posts a user had when deleting, but the confirmation message now just contains a vague message about content which, as Justin mentioned, doesn't give us a great idea of everything that could/will be deleted.

[Phyrax]

+1, confirmed this would be great to have

[Funstacy]

+1.

[SergeyBiryukov]

Related: #26195

Replying to coreymcollins:

I feel as though previous versions of WordPress would at least tell you how many posts a user had when deleting

Previous message just mentioned "posts", without any count: [27416].

[bradparbs]

@phyrax has put together a simple plugin to add some data to this screen.

I think doing something like this, not showing the ones that are zero, and maybe making it look a bit better would be a good addition to core.

[netweb]

Rather than all of the devs at webdevstudios adding +1's just click the star and "watch" this ticket ;)

See ​https://make.wordpress.org/core/2014/01/09/new-trac-notifications-feature/

Just above the comment box, you’ll see a new notifications pane. Here, you can watch/unwatch tickets.

A note on how this is implemented: isn’t just subscribe/unsubscribe. “Watch” can also be thought of as “Vote” or “Star” or “Favorite”.

[Tmeister]

Shows the content that will be affected as the screenshot above.

[Phyrax]

Love the way you did the foreach loop, didn't even think of that @Tmeister. The only problem is that the count_user_posts() method does not actually count attachments. It uses get_posts_by_author_sql() for its WHERE statement. In-turn, that method only checks if post_status is publish or private.

Attachments are stored with the 'inherit' post_status, so the attachment post-type will always come up as zero.

So, I took your code structure, re-factored it a bit, and put it into a callable method in includes/user.php

As for the rest of this, I added multi-site compatibility to the method as well, so this works for both regular installs, and multi-site installs.

Additionally, the delete_user_form action was passing the current WP_User object, not the actual list of users being deleted. So, as to not break anything that is currently using that, I added a second parameter to the action, to actually pass the proper data.

Screenshot of both, regular and multi-site installs, using @Tmeister's HTML:

[Phyrax]

Clean version of original diff, removed debug output, and empty lines.

[Tmeister]

@Phyrax,

Definitely that is a good improvement ;)

[jtsternberg]

As this page could become quite long if you're deleting a large number of users, I would probably get rid of the results that come up as zero. It might even be worth exploring converting to an inline version with the number next to each in parentheses.

[emirpprime]

+1 We've had lots of users trash content they didn't mean to as a result of this and had to revert to backups... Not a good user experience.

Also related #33216 - indicating that users have draft posts before you even select them for deletion (yes that's mine, no this isn't meant to be a plug, but I found this when searching to see if someone had already submitted it).

Both of these highlight a wider UX problem that begins with Users.php screen Posts column count only referring to Posts - as WP is being used more and more as a CMS this seems less relevant. Perhaps this should be replaced with a Content column that covers all posts types in any state except Deleted? Not really sure how tickets are picked up as never contributed until today but might try the Make Core UI chat to flag both these tickets for discussion...