WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 5 months ago

#31945 new enhancement

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

Reported by: jtsternberg Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.2
Component: Media Keywords: has-patch needs-testing
Focuses: ui, administration Cc:
PR Number:

Description

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.

Attachments (3)

31945-deleting-user-info.diff (1.1 KB) - added by Tmeister 5 years ago.
31945.diff (3.8 KB) - added by Phyrax 5 years ago.
31945-clean.diff (3.8 KB) - added by Phyrax 5 years ago.
Clean version of original diff, removed debug output, and empty lines.

Download all attachments as: .zip

Change History (17)

#1 @bradparbs
5 years ago

+1 to this.

#2 @williamsba1
5 years ago

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.

#3 follow-up: @coreymcollins
5 years ago

+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.

#4 @Phyrax
5 years ago

+1, confirmed this would be great to have

#6 in reply to: ↑ 3 @SergeyBiryukov
5 years ago

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].

#7 @bradparbs
5 years ago

  • Keywords needs-patch added

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

https://i.imgur.com/EUMxmpy.png

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.

#8 @netweb
5 years ago

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”.

#9 @jeremyfelt
5 years ago

  • Type changed from defect (bug) to enhancement

#10 @Tmeister
5 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

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

#11 @Phyrax
5 years ago

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:
http://imgur.com/BcgLcsa.png

@Phyrax
5 years ago

@Phyrax
5 years ago

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

#12 @Tmeister
5 years ago

@Phyrax,

Definitely that is a good improvement ;)

#13 @jtsternberg
5 years ago

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.

#14 @emirpprime
4 years ago

+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...

Note: See TracTickets for help on using tickets.