#50882 closed defect (bug) (fixed)
WP 5.5: Cannot attribute content when deleting users
Reported by: | webzunft | Owned by: | garrett-eclipse |
---|---|---|---|
Milestone: | 5.5.1 | Priority: | high |
Severity: | normal | Version: | 5.5 |
Component: | Users | Keywords: | has-patch commit |
Focuses: | administration | Cc: |
Description
I am testing: 5.5-RC2-48740
The site has multiple users, all plugins are disabled. Theme is Twenty Nineteen
- go to Users
- enable the checkboxes next to 3 out of 4 existing users (except my own user)
- select "Delete" in the bulk actions and "Apply"
- select "Attribute all content to" + my user name
- click "Confirm Deletion"
I am now seeing: The link you followed has expired.
With Query Monitor is enabled I see a bit more:
This message was triggered by Core. Call stack: wp_die() wp-includes/functions.php:3269 wp_nonce_ays() wp-includes/pluggable.php:1154 check_admin_referer() wp-admin/users.php:221
Attachments (2)
Change History (18)
#1
@
4 years ago
- Component changed from General to Users
- Focuses administration added
- Milestone changed from Awaiting Review to 5.5.1
#3
@
4 years ago
Also noting that the issue only affects the bottom bulk actions dropdown, the top one seems to work as expected.
@
4 years ago
Apply action="users.php"
to the forms in users.php to nullify the action2/doaction2 params that get inherited from the URL when no action set on the form.
#7
follow-up:
↓ 8
@
4 years ago
- Keywords has-patch needs-testing dev-feedback added; needs-patch removed
- Owner set to garrett-eclipse
- Status changed from new to assigned
Thanks for the report @webzunft I can confirm @SergeyBiryukov's note on this being "Introduced in [48134] / #46872."
Seems that change didn't get enough testing throughout as there's a few other reports.
Looking into this issue the introduction of the doaction2 param to the first request stays along for the ride when the second request to actually dodelete occurs as the form on that screen doesn't provide an action so inherits all current URL params in it's request.
To resolve this I've uploaded 46872.diff which updates the two forms in the users.php to provide an action referring to users.php without any params to avoid this param inheritance.
So far in my testing of the User Bulk Delete process it's working nicely, I'll look into the other occurrences to provide a more encompassing fix once I've identified all bulk-actions that are being affected. The fix for others should be the same just apply the current .php file as it's own action without any params.
CC @SergeyBiryukov / @desrosj / @johnbillion / @whyisjake - Can you test and feedback on this approach, I feel this is a candidate for 5.5.1.
#8
in reply to:
↑ 7
@
4 years ago
Replying to garrett-eclipse:
So far in my testing of the User Bulk Delete process it's working nicely, I'll look into the other occurrences to provide a more encompassing fix once I've identified all bulk-actions that are being affected. The fix for others should be the same just apply the current .php file as it's own action without any params.
Thanks for the patch! Just noting that #50998 also seems related.
#10
@
4 years ago
Can confirm the same issue in same way as @SergeyBiryukov https://core.trac.wordpress.org/ticket/50882#comment:1
Adding in the patch action seems to fix my issue, and I am now able to delete multiple users again.
#11
@
4 years ago
- Priority changed from normal to high
Hi there,
I tested @garrett-eclipse’s patch and it seems to fix the issue on my side.
Let's keep the needs-testing
workflow keyword for now.
I'd also add high
priority as this bug breaks an existing feature. This is a must-have for 5.5.1.
Hi there, welcome back to WordPress Trac! Thanks for the report.
I was able to reproduce the issue. It appears to only affect bulk actions: