[wp-trac] Re: [WordPress Trac] #2531: Functions for registering additional capabilities and getting a list of all capabilities

WordPress Trac wp-trac at lists.automattic.com
Wed Apr 26 00:54:09 GMT 2006


#2531: Functions for registering additional capabilities and getting a list of all
capabilities
----------------------------+-----------------------------------------------
       Id:  2531            |      Status:  new                     
Component:  Administration  |    Modified:  Wed Apr 26 00:54:09 2006
 Severity:  normal          |   Milestone:  2.1                     
 Priority:  normal          |     Version:  2.0.1                   
    Owner:  anonymous       |    Reporter:  markjaquith             
----------------------------+-----------------------------------------------
Comment (by matt):

 I think caps should move out of the DB entirely. At the end of the day, we
 basically have a boolean value for a number of different actions. Plugins
 should be able to create and check against a darn boolean value without
 modifying the DB. Defaults should be hardcoded into vars.php and plugins
 can modify them at will. Right now the system is far more complex than it
 needs to be, and it's extremely challenging to grasp. (The lack of
 documentation doesn't help either, but if the system was clearer it
 wouldn't need documentation, so I see that as a symptom not a cause.)

 I think the fact that no one but extremely core hackers have even
 attempted to put anything on top of roles/caps speaks to that fact.

 What if...

 We had an indexed array of roles in a file in WP. Roles 0-6, which match
 the roles we currently have.

 Each of these roles statically maps in an array by role_id to a set of
 caps.

 Roles and caps both pass through filters, so plugins can edit current ones
 or add new ones at runtime. This would match how we allow plugins to
 modify similar systems throughout the rest of WP.

 The role_id is stored in usermeta, but only in the key. If I'm
 Administrator (role_id = 6) I have a usermeta row which looks like:
 user_id 1, meta_key role_6, value $table_prefix.

 For MU for a fast way to get all the users of a blog, set a meta_key =
 $table_prefix and meta_value = 1, which is set if someone is attached to a
 blog. Again, this would be a key lookup.

 This would allow indexed lookups of people in different roles (scanning
 values is a full table scan) and we already have usermeta set for users so
 we could just check the user object, making everything ultra-fast as well.

 I'm just throwing this out there, it might not be the best system but I'm
 sure between us we can think of something infinitely simpler than what we
 have now.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/2531>
WordPress Trac <http://wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list