Administrator Role Changed to "No Roles" Causes Internal Server Error

[jomonthomaslobo1]

Environment Details:
WordPress Version: 6.8 Beta 1
PHP Version: 8.1
Database: MySQL 8.0 / MariaDB 10.5
Web Server: Apache/Nginx
Theme: Twenty Twenty-Four
Plugins Installed: WP Beta Tester

Bug Description:
After upgrading to WordPress 6.8 Beta 1, if the only Administrator user is changed to “No Roles Assigned”, the site crashes with an Internal Server Error (500). This should be handled gracefully and don't allow role change if tehre is only one user.

Expected Behavior

1. WordPress should prevent removing the last Administrator role.
2. An error message should be displayed instead of allowing the change.
3. The system should gracefully handle such role changes instead of causing a site crash.

Actual Behavior
The site crashes immediately after saving the role change.

Steps to Reproduce

1. Upgrade to WordPress 6.8 Beta 1.
2. Ensure there is only one administrator account.
3. Go to Users > All Users, select the administrator account.
4. Change the role to “No Role for This Site” and save.

Result: The site shows a 500 Internal Server Error,

[jomonthomaslobo1]

Screenshot of error page

[audrasjb]

Hmm it appears that the issue was already here in 6.7.2. Therefore, I'm removing trunk version.

https://core.trac.wordpress.org/ticket/63068

[audrasjb]

Workaround patch to fix this issue: ​https://github.com/WordPress/wordpress-develop/pull/8469

I don't believe the number of users is the issue. The same thing occurs if you try to change the role of your own admin account on a site where there are other users.

I don't believe the number of users is the issue. The same thing occurs if you try to remove the role of your own admin account on a site where there are other users.

I suspected this but I wanted to propose a first workaround and then investigate a bit more.

I edited the PR to change the conditional: it now checks whether the current user is trying to remove their own role.

[jomonthomaslobo1]

@johnbillion Yes. So removing active user role by themselves need to te be tested I think

[shailu25]

Test Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/8469

Environment:
WordPress - 6.8-beta1
OS - Windows
Browser - Firefox
Theme: Twenty Twenty
PHP - 8.2.12
Active Plugin: None

Actual Results:

• Issue Resolved With Patch.✅

Screenshots:

• Added Attachment

[shailu25]

Before Patch.

[shailu25]

After Patch.

[rishavdutta]

Test Report

PR Tested: ​https://github.com/WordPress/wordpress-develop/pull/8469

Test Environment [Playground]

• WordPress Version: 6.8beta1
• OS: macOS
• Browser Google Chrome
• WordPress Active Theme: Twenty Twenty-Five
• Active Plugin: None
• PHP version: 7.4.31-dev
• Database Client Version: 3.40.1
• Database Server Version: 5.5

Test Results

• Actual Result: Upon updating the role of the only admin account in the site to "No Role for This Site", it leads to a screen similar to white screen of death with an error message "Sorry, you cannot remove your own role.".
• Expected Result: Upon updating, it should show an error message in the dashboard itself instead of showing error on white screen.

Reference Screenshots: ​https://drive.google.com/file/d/1NWh3DZ2YPwuEsT4HCKAARinUD7siY7YN/view?usp=drive_link

The underlying problem is that there is logic for this already, in ​https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/users.php#L146-L153, but it only accounts for a user attempting to change their own role to one that doesn't have the promote_users capability. It doesn't account for a user attempting to remove their role.

I think the existing condition should be updated or extended to account for an attempt to remove the role, rather than introducing separate logic prior to iterating the list of users.

[jorbin]

#63129 was marked as a duplicate.

[audrasjb]

As per today's bugscrub: The patch still needs some work, let's move it to 6.9.

Follows ​https://github.com/WordPress/wordpress-develop/pull/8469.
Proposes a new patch according to this ​suggestion

Trac ticket: https://core.trac.wordpress.org/ticket/63068