[wp-trac] [WordPress Trac] #18934: Multisite issue cleaning up empty capabilities

[WordPress Trac]

#18934: Multisite issue cleaning up empty capabilities
-------------------------------------+------------------------
 Reporter:  jammitch                 |       Owner:  PeteMall
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  4.2
Component:  Role/Capability          |     Version:  3.0
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  multisite
-------------------------------------+------------------------
Changes (by jeremyfelt):

 * milestone:  Future Release => 4.2


Comment:

 Let's fire this up again. :)

 I'm of the opinion that removing a large chunk of this code is the right
 move.

 A few interesting reads:

 * In #2809, the concept of "No role for this blog" was introduced as a way
 to prevent the accidental assignment of a role when editing a user from
 `user-edit.php` on a site for which the user had no existing role.
 * The commit message for [22686] mentions hiding "''users that have no
 capabilities (in case they possess a leftover, empty wp_xx_capabilities
 key from the MU days), not users that have no role, as they may have a cap
 but no role.''"
 * In @jjj's
 [https://core.trac.wordpress.org/attachment/ticket/22361/22361.2.patch
 patch for 22361], he addresses this area of code as "''prevents a user's
 capabilities from being completely deleted in multisite setups when
 setting 'role' to none''". That ended up not being committed as part of
 the ticket, but is the issue at hand here.

 When `wp_insert_user()` is used with an empty role, an empty array is
 stored. However, core treats this condition and that in which
 `wp_xx_capabilities` has been deleted completely exactly the same. That's
 ok, but what makes the existing code a bit confusing—the explicit check
 for `a:0:{}`.

 The real issue:

 If a user has a built in role assigned, and a custom role is added, the
 two roles are stored in the database alongside the existing role. With the
 current state of `user-edit.php`, setting that user to "No role for this
 site" will delete the row entirely, including the custom role. This means
 the user will no longer be shown in the site's user list table, even
 though the intent could be for the user to continue with an even more
 limited custom role.

 By removing this section of code

 * No change in behavior if editing your own profile.
 * No change if editing a user in `wp-admin/network/user-edit.php`
 * No change if editing a user and setting any role..
 * If setting the role to "No role on this site", custom roles now remain.

 We can also take this opportunity to clean up and combine what's happening
 in multisite and single site installs.
 [https://core.trac.wordpress.org/attachment/ticket/18934/18934.3.diff
 18934.3.diff] does this.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/18934#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform