[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