[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
Fri Apr 21 18:53:16 GMT 2006


#2531: Functions for registering additional capabilities and getting a list of all
capabilities
----------------------------+-----------------------------------------------
       Id:  2531            |      Status:  new                     
Component:  Administration  |    Modified:  Fri Apr 21 18:53:16 2006
 Severity:  normal          |   Milestone:  2.1                     
 Priority:  normal          |     Version:  2.0.1                   
    Owner:  anonymous       |    Reporter:  markjaquith             
----------------------------+-----------------------------------------------
Comment (by ringmaster):

 I must assume that ryan's table idea was just a lark.  Five new tables for
 capabilities?  That's insane.

 Here are my other thoughts:

 I like the idea of the WP-native get_all_caps().  That seems practical.

 I do not like the idea of registering caps using only the registration
 functions.  Here's why:

 Suppose you have a plugin that replaces a single intrinsic cap with three
 custom caps that provide different tiers of access to the same feature.
 Using only the registration functions, it is not possible to remove the
 intrinsic cap from the list.  (In case you were wondering how this would
 be done technically, you could use hooks to grant/deny the intrinsic cap
 from users based on the application of your custom caps in whatever
 circumstances happened to apply.)

 What difficulty would there be with moving the Role Manager's cap filter
 into the core?  It allows direct access to the array of available caps so
 that caps can be added ''and'' removed.

 If we're talking about making grander changes....

 Un-array the caps.  Currently, it's very difficult to answer questions
 like "Which users have cap X?"  If we stored caps as multiple individual
 rows in the options table instead of as an array in a single row, these
 types of queries would be easier.

 If you really needed to, the caps could be pushed to their own table-  one
 row per cap per user.  There would also need to be a store for caps in
 roles, which could probably just as efficiently stay in options as make a
 second table.  So two new tables at most, but I don't see a lot of benefit
 there.

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


More information about the wp-trac mailing list