I spent some time over the weekend implementing changes in WordPress’ login system. In 1.5, a user’s capabilities are determined by their user level, a number that represents how powerful they are.
The problem with the 1.5 system of user levels is that you don’t really know what a specific level can do without having a reference in front of you. And every time you want to add a new capability for users, you have to figure out where in the 10 discrete levels is the best place to put it.
Changes in the 1.6 user scheme are going to change all that. Instead of using numeric levels, users will have Roles.
A “Role” is just what it sounds like it is. By default (as of this moment), WordPress will have 6 roles: Inactive, Subscriber, Contributor, Author, Editor, and Administrator.
These Roles allow users to be easily classified by their capabilities. The fundamental differences between these Roles should be mostly apparent just from their description. A Subscriber is a user that can login to the admin console, but cannot write posts. Contributors can write posts, but can’t publish them. Authors can write and publish their own posts. Editors can write and publish posts, but can also edit and publish other people’s posts. Administrators can do everything, including setting site options and configuring plugins and themes.
All of the capabilities of a Role are determined by that role’s Capabilities. There will eventually be a master list of Capabilities, but they boil down essentially to things like “edit_posts” and “edit_users”. A Role is basically a name attached to a set of Cababilities.
WordPress 1.6 will ship with the default set of Roles mentioned above, but Roles are configurable. Additional custom roles can be added to a site, or the default role set can be completely scrapped for something new. There is currently not an interface for modifying and adding roles, but it can be done programmatically, and I’m currently working on a generic role-editing interface as a patch.
One of the changes to permissions in the new role-based scheme is that there is no longer a hierarchy of users. In WordPress 1.5, users of a higher user level could edit any user with a lower user level. WordPress 1.6 requires only that you have the “edit_users” Capability.
Plugins should be able to define their own Capabilities and make them available to roles. In this way, add-on functionality can use the built-in permissions system to great effect.
Programmatically, you need only a very simple command to check whether the current user has a particular permission:
if( current_user_can(’edit_users’) ) …
See how it actually reads like something you would want to know? Permissions functionality will now be strangely easy to deploy in plugins. But what of plugins that require a user level, for example, admin pages?
Well, I assume that the permissions scheme for admin pages will change to accomodate the Capabilities-based permissions rather than the numeric system. But until that time, there are some backwards-compatible features in the new code.
Roles can have a Capability assigned to them such as “level_4”. These Capabilities range from “level_0” to “level_10”. The highest number of these Capabilities is used as a “synthetic” user level. Plugins that deploy custom Roles should include at least one “level_*” Capability for backwards compatibility.
There are advanced features to Roles whose capabilities will not exend to the 1.6 core codeset. For example, the data structures that contain Roles for a user can contain more than one Role, and will resolve all Capabilities for all Roles assigned to a single user. So if a user is both a “Theme Designer” and an “Author”, the Capabilities allocated to both of those Roles will be available to the user. WordPress itself will not let you assign two Roles to a user, but the structure will hold it and the code will correctly return Capabilities for it, so a plugin could implement the admin UI.
Also, it is possible (once again, in the data structure, but likely not via any of the core admin UI functionality) to assign Capabilites directly to a user. So if you have a trusted user that is normally just an Editor, you can also add the “edit_themes” Capability to his account wihtout granting him the full Administrator role. Of course, you could always create a new Role with just the permissions you need, but there may be cases in plugins where this functionality is useful.
Note that as of this writing, none of this code has been committed, but I’m optimistic that it’ll go through.
