[wp-hackers] User Capabilities

Owen Winkler ringmaster at midnightcircus.com
Fri Jul 8 15:10:33 GMT 2005


Ryan Boren wrote:
> Sounds good.  Patch attached.

Holy caps, Batman.

There's a glitch or two.  I don't think that usermeta values get 
unserialized in get_userdata() when they are added to the WP_User 
object, so checking against $this->caps[] in WP_User::has_cap() won't 
return a valid value.  (It was returning "a" for me, which is "true", 
even though I shouldn't have the cap I requested.)

The confusing IF statement in that function seems to say:
If ((the user does not have the cap directly) and (a role exists with 
that name) and (the role doesn't have the cap)) then the user doesn't 
have the cap.

A problem is that it's not checking the requested cap against the caps 
of the *user's* roles.  It's only checking the requested cap against the 
caps of a role with the same name as the requested cap, which is 
incorrect.

I've attached new files to try with changes that look to me like they 
work.  It builds a complete list of caps when WP_User is created by 
reading the user roles recursively.  Apply my patch over Ryan's and 
replace the capabilities.php file with this new one.  You'll need to 
delete the options table row that contains the roles and run the upgrade 
to see the recursive roles work.

Hint: echo $current_user->caps from admin-footer.php.

Can you set a cap to false to deny that cap?  I think that my patch 
could enable this.  Just a thought, since it might be useful to grant 
users capabilities by role, and then revoke a single permission.

As I said before, the admin UI need not support setting these 
capabilities, but it's handy if the core supports them if someone wants 
to augment the permission page by plugin.

I also see in this code a trend toward assigning permissions to 
different table prefixes, which implies that MU functionality is in the 
pipeline for the core.  I'm not up to speed on MU - Which tables are 
shared and which aren't?  It seems that the options table would be a 
shared table, and that any option that's not global should have a table 
prefix.  This would be good to know for plugins with option data that 
want to support MU.

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newcaps.diff
Type: text/x-patch
Size: 5100 bytes
Desc: not available
Url : http://comox.textdrive.com/pipermail/wp-hackers/attachments/20050708/3c7be53f/newcaps.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: capabilities.php
Type: application/x-php
Size: 5469 bytes
Desc: not available
Url : http://comox.textdrive.com/pipermail/wp-hackers/attachments/20050708/3c7be53f/capabilities.bin


More information about the wp-hackers mailing list