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

[beerallica]

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)

[netweb]

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)

[swissspidy]

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.

[swissspidy]

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!

[tharsheblows]

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]

just took out post_status

[netweb]

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

[dd32]

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.

[dd32]

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.

[dd32]

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.