WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#34993 closed defect (bug) (fixed)

Deleting a user no longer asks what to do with their content

Reported by: beerallica Owned by: dd32
Milestone: 4.4.1 Priority: normal
Severity: normal Version: 4.4
Component: Users Keywords: has-patch commit fixed-major
Focuses: administration Cc:
PR Number:

Description

The process that deletes a user seems to only notice posts, and ignore other post_types, so it doesn't ask me if I want to attribute their content to other users if that content is of custom post_type.

On a certain installation, trying to delete a user that has zero posts, but 10 bbpress topics and 19 replies. the following query:

$users_posts = new WP_Query( array( 'post_type' => 'any', 'author' =>$user_id, 'posts_per_page' => 1    ) );
var_dump( $users_posts->found_posts, $users_posts->have_posts() );

returns

int(0) bool(false)

Attachments (2)

34993.patch (1.0 KB) - added by swissspidy 4 years ago.
34993.2.patch (1010 bytes) - added by tharsheblows 4 years ago.
just took out post_status

Download all attachments as: .zip

Change History (16)

#1 @swissspidy
4 years ago

  • Version 4.4 deleted

#2 @netweb
4 years ago

  • Milestone changed from Awaiting Review to 4.4.1
  • Version set to 4.4

Confirming, I noticed this same thing yesterday whilst cleaning up some users in a bbPress install.

This came from [34000]/#6405, the cause is wp-admin/users.php#L215 and 'post_type' => 'any because with WP_Query if the post type is set to any and the post type was registered with exclude_from_search as true (which bbPress does for all 3 CPT's registered) then WP_Query excludes these posts from the query. Hence the "Attribute content to another author" is not shown because the bbPress posts are excluded from the search.

https://codex.wordpress.org/Class_Reference/WP_Query#Type_Parameters

Note: Also need to check how this has or has not changed for Multisite (/wp-admin/includes/ms.php#L1057)

#3 @swissspidy
4 years ago

  • Keywords needs-patch added

#4 @swissspidy
4 years ago

See also #17592 (closed as wontfix) regarding the exclude_from_search problem.

What if bbPress would not use exclude_from_search but instead excludes its data from search using a pre_get_posts filter? Changing exclude_from_search seems difficult due to BC. See also #29418.

This ticket was mentioned in Slack in #bbpress by swissspidy. View the logs.


4 years ago

@swissspidy
4 years ago

#6 @swissspidy
4 years ago

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

34993.patch is a possible solution that uses a custom SQL query instead of WP_Query. Wondering if we even need to check for post statuses.

@beerallica Would you mind testing this patch? Thanks!

#7 @tharsheblows
4 years ago

I don't think we need a check for post_statuses. wp_delete_user (https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/user.php#L284) doesn't differentiate between them, so it's more consistent to not use it here. Plus it's much faster. :)

@tharsheblows
4 years ago

just took out post_status

#8 @netweb
4 years ago

  • Keywords commit added; needs-testing removed

Just tested 34993.2.patch and works for me, agree with no need for post statuses.

#9 @netweb
4 years ago

  • Owner set to netweb
  • Status changed from new to assigned

This ticket was mentioned in Slack in #core by johnbillion. View the logs.


4 years ago

#11 @dd32
4 years ago

  • Owner changed from netweb to dd32
  • Status changed from assigned to accepted

A few small things:

  • There's no need to do the GROUP BY, and we don't even need the COUNT(*). We just want to know if any of them have posts. It's a lot more efficient to simply do SELECT ID FROM {$wpdb->posts} WHERE post_author IN(1,2,3) LIMIT 1 as it'll return the truthy value as soon as it finds any content.
  • "Content" in the realm of wp_delete_user() is also Links/Bookmarks, so we should also check that, [34000] didn't take that into consideration. Better to take that into consideration than have a users old content go missing.

#12 @dd32
4 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 36068:

Users: When determining whether to show the reassign content option during user delete, don't rely upon WP_Query as it doesn't return all forms of content wp_delete_user() operates on.

This restores the reassign form when a user has a non-public post type or links assigned to them.

Props swissspidy & tharsheblows for initial patches.
Fixes #34993 for trunk.

#13 @dd32
4 years ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

#14 @dd32
4 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 36106:

Users: When determining whether to show the reassign content option during user delete, don't rely upon WP_Query as it doesn't return all forms of content wp_delete_user() operates on.

This restores the reassign form when a user has a non-public post type or links assigned to them.

Merges [36068] to the 4.4 branch.
Props swissspidy & tharsheblows for initial patches.
Fixes #34993.

Note: See TracTickets for help on using tickets.