[wp-trac] [WordPress Trac] #36961: wp_roles displays incorrect roles in multisite

WordPress Trac noreply at wordpress.org
Tue Dec 27 17:09:50 UTC 2016


#36961: wp_roles displays incorrect roles in multisite
-------------------------------------------------+-------------------------
 Reporter:  ryanduff                             |       Owner:
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
Component:  Role/Capability                      |  Release
 Severity:  normal                               |     Version:  4.2
 Keywords:  dev-feedback has-patch has-unit-     |  Resolution:
  tests                                          |     Focuses:  multisite
-------------------------------------------------+-------------------------
Changes (by flixos90):

 * keywords:  dev-feedback has-patch needs-unit-tests => dev-feedback has-
     patch has-unit-tests


Comment:

 [attachment:36961.2.diff] is a more sophisticated approach to the problem.
 A new private property `$blog_id` containing the site ID the user is
 initialized for is introduced in the `WP_User` class. The property is set
 in the `for_blog()` method, and then the cap key is created based on it.
 The method `get_role_caps()` then does not need to do anything else than
 conditionally switching the site.
 A caveat of this approach is some ugly code in the `_init_caps()` method
 (line 463-475). This clause would not be necessary though if we made
 removed the magic call method to have it available as a public method
 (which is in place for backward-compatibility). But even if we don't I
 think this approach is a better solution going forward.

 The patch also adds a unit test for the issue. Another existing unit test
 failed upon making the changes, however this was solely caused by doing an
 object-to-array conversion via typecast, which exposes private properties.
 Using a proper `get_object_vars()` call instead ensures only public
 properties are included.

 A further idea: We could remove the `$cap_key` property and only have the
 `$blog_id` property to rely on when building the cap key. This would make
 having the two properties out of sync impossible. For BC, we could have
 the `$cap_key` property available through magic methods, that would create
 the value from the `$blog_id` property on read-access and translate the
 input to the `$blog_id` property on write-access.

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


More information about the wp-trac mailing list