Thanks to some Google Summer of Code proposals, there have been some conversations on the wp-hackers list about roles and capabilities, and how we can improve them. It’s important, though, to understand exactly what the current API allows — it’s much more complicated than many realize.
Here’s how an end user generally sees it:
- A user can be given one of five roles: Administrator, Editor, Author, Contributor, Subscriber.
There’s much more of course behind that. Hopefully, a developer just getting started with WordPress does not notice the long-deprecated user levels. If all goes well, budding developers will also realize that:
- Each role is made up of a number of capabilities, such as manage_options (only for Administrators), moderate_comments (for Editors and Administrators), and edit_posts (for Contributors, Authors, Editors, and Administrators).
Of course, a more experienced developer, or a blog administrator who has downloaded one of the various capability/role management plugins will also realize that:
- You can create roles and give those roles a set of capabilities. Example: You can give the Editor role the activate_plugins capability.
- You can grant individual users a specific capability that their role does not otherwise give them. Example: A user with the Editor role can be given the activate_plugins capability.
- A user can have capabilities removed from them, negating capabilities they would otherwise have through their role. Example: A user with the Editor role can be stripped of the unfiltered_html capability.
But wait, there’s more:
- A user can have more than one role. Thus, a user could have both the Editor role, and the Administrator role. (Since all capabilities in the Editor role are also in the Administrator role, then this example would have no effect.)
This last one is not supported by the core WordPress user interface. No publicly released plugins use it (that I know of). In fact, the main use case would be for a membership plugin (which is, incidentally, the rare use case for using your own table).
The problem is, this system cannot scale well due to the overhead. But, since most of our performance woes are from features that aren’t used, the best solution is to remove those features.
The current consensus — see Trac ticket #10201 — would be to eliminate user-specific capabilities (both additional capabilities, and negation), and we would force users to have only one role.
It would be an admission that the current roles/capability system, in a desire to be leaps and bounds over the original 0-to-10 user levels, went a little too far.
In a later post,* I’ll talk about the schema — how we store roles and capabilities now, how we may store roles and capabilities in the future, and how we’ll bridge the two on an upgrade. Some alternatives should also be discussed, but in the context of the schema.
* While drafting this, I’ve also been replying to that wp-hackers thread, so my thoughts on most of this are already out there.
I am using multiple roles with my amProtect plugin for WordPress. It integrates aMember Professional membership software with WordPress and it does it by assigning a unique role in WordPress for every product or subscription level that the person purchases.
Thousands of web sites use WordPress to offer online classes in the expertise and niche of the web site (membership site) owner. A single member can sign up for multiple classes and/or memberships.
Integrating with the Simple Press forum is done best by having unique roles to assign to users who need special restricted access to a private forum for the level they are on.
If multiple roles were removed from WordPress then all of this would be in jeopardy so I hope this capability never goes away.
To me, the way it has finally become is what it should have been all along.
For me, the need is to identify them by a label…a role…more than to give users certain capabilities.
I absolutely, positively would be against limiting users to only one role. It would hurt quite a few WordPress sites if you did this.
Just thought I’d weigh in on this and give you something to think about.
Thanks!
Ken
@Ken: I’m with you on your concern. I have a use-case where I need abstractly the same thing you describe. However, once the WordPress team makes up it’s mind experience tells me there’s very small likelihood of them revisiting said decision. Or put another way, get started mourning the loss now because it going to happen.
-Mike
@Mike: We are always open to reasoned technical discussions.
These discussions do need to take into consideration the core philosophies of the product as well as respecting the opinions of everyone involved.
The current desire for simplification amongst the community of core contributors is in part to make it more adherent to those philosophies as well as making it simpler to user, maintain and extend.
The current role/cap system tries to be too flexible at the expense of performance. It doesn’t scale well and it isn’t easy to query for things like “find me all the users with the foobar capability”.
We all want to make it simpler to use, more scalable, easier to extend and to make sure it provides the 80% functionality that most people need out of the box. The hooks will be there for you to extend if you can’t satisfy your use-case with what the core provides (and if we end up missing a hook then you only have to ask to get it added).
The best way to influence the direction the rewrite takes is to get involved when it happens.
Peter:
My point to Ken was that the team has made its decision and the team don’t have a history of reconsidering decisions once they’ve been debated and decided so for Ken to continue to advocate for something different would be a waste of his effort. At least that’s what I’ve come to understand from my past two years being involved in the community at various levels. Did I mis-state?
-Mike
I believe Peter’s point was that we haven’t made a decision. Because we haven’t.
Ah, then I stand corrected.
Mike: In general no firm decision on any implementation is every really made until the implementation starts.
In this particular case we have some strong opinions based on how the current system has worked over the past few years which is why it might feel like we have made a decision and I can understand why you may have thought that because strong opinions often sound like decisions.
Everyone’s opinion can be swayed – often the best way to do this is to show how something can be done differently – for example once we get to the release where we do as a community decide to tackle this issue to offer code and data which show how things can be improved and still meet the use cases you have in mind.
@Peter: Gotcha.
@Peter: BTW, this particular issue (Roles) isn’t my hot button (yet?) so I probably won’t be writing code to address it (as I’ve personally not actually run into difficulty because of it) but these two (2) actually are of my hot buttons and where I’d prefer to invest my development time:
1.) Evolve the URL Routing System
2.) A Post Relationships Table
The former I’ve seen no push back on (thankfully, although it is a huge pending dev task for me) but quite frankly the rejection of use-cases for post relationships was frustrating and felt summarily dismissive. (I’m just sayin…)
I’ve got more years experience with database systems focused on the solutions end (vs. the systems end) than I care to admit and know that having a way for relational databases to effectively handle many-to-many relationships is the one foundational aspects still missing from otherwise brilliant software. Many-to-many relationships are relevant to practically every potential solution that requires database support (see also: Associative Entities). I keep hoping that my continued contributions will result in some acknowledgment that I have relevent insight (I’m just assuming you appreciate those who help WordPress users solve their problems and advocate for the use of WordPress?)
Another thing to consider, not everyone can contribute code for every concern they have and I’m by no means talking about just myself here; @Ken Gary might be an example, and there are many others in the community as well. If the development team only considers the input from those who write patches then the result will be that a highly imbalanced WordPress deficient of important influence. You could consider it much like the inbreeding that occurred in royal families over the many centuries albeit the half-life of software is much less than the evolution of human DNA. I think it would be dangerous for the long term health of WordPress to require code contribution to be a gating factor for influence, IMO anyway.
-Mike
P.S. In hindsight, though, sorry if I highjacked this thread somewhat. Your dismissal of the relevancy of #14513 left me with some lingering distaste which I think is what resulted in my comment. I will try to better moderate my unsolicited feedback moving forward.
If we remove the support for multiple roles in WordPress core then we wouldn’t be precluding you from still doing this.
You would likely have a number of options:
Add some extensions to the api in your plugin to allow users to have multiple roles
Use capabilities to determine this rather than roles
You example to me reads very much like something which should be achievable using capabilities assigned to individual users rather than multiple roles.