[wp-trac] [WordPress Trac] #16617: Bulk activate plugins: add capabilities with WP_Roles::add_cap() fails, while procedural add_cap() does not
WordPress Trac
wp-trac at lists.automattic.com
Wed Feb 23 11:36:28 UTC 2011
#16617: Bulk activate plugins: add capabilities with WP_Roles::add_cap() fails,
while procedural add_cap() does not
-----------------------------+------------------------------
Reporter: jrfoell | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Role/Capability | Version: 3.0.5
Severity: normal | Resolution:
Keywords: |
-----------------------------+------------------------------
Comment (by solarissmoke):
Here's the problem:
The function `get_role()` uses the global `$wp_roles`, which is
instantiated the first time that `get_role()` is called. At instantiation,
it loads the `wp_user_roles` option and stores it as `$wp_roles->roles`.
Now, whenever you use $wp_roles::add_cap() (as the procedural plugin
does), it simply adds the capability to `$wp_roles->roles`, and then does
`update_option()` to store it in the database. If, in the mean time,
something else has updated the `wp_user_roles` option independently (which
is what the OO plugin does, with it's own instatiation of the WP_roles
class), then $wp_roles has no knowledge of this and simply overwrites
those changes. Hence the capability added by the OO plugin is overwritten.
Basically, the current setup only works if you have *one* instantiation of
the `WP_Roles` class. Things will break if plugin authors create their own
- because the `wp_user_roles` option is loaded only once, at
instantiation. Having two instances of the class making concurrent changes
will always cause one set to be overwritten by the other.
I'm no expert, but I can't see why you would want more than one instance
of WP_Roles anyway?
--
Ticket URL: <http://core.trac.wordpress.org/ticket/16617#comment:5>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list