WordPress 4.9 was a huge update for the platform. Not only did it bring in tons of new functionality and utilities for users, but developers weren’t left out in the cold, either. While devs will absolutely get use from the new code editing updates (now with error linting and line numbers!), one of the more under-the-radar changes has been to WordPress user roles.
Prior to 4.9, setting permissions with users has been pretty undynamic. Not quite static, but not necessarily customizable. Admins, subscribers, editors, etc. were all given permissions, and we could all choose who could do what within those roles.
With 4.9, however, we get a lot more specific control of what users can do, and we can assign them tasks and permissions within each role, without worrying about them having access to unwanted features, either. The way the notes describe this update is allowing “more granularity through the following new capabilities.”
Think about it as a bunch of toggles you can add to users.
Plugin Control
Before 4.9, WordPress user roles were limited to a binary choice regarding plugins: either they had access to them, or they did not. Those with access could add, delete, activate, deactivate, adjust settings, and so on and so forth. Those without access didn’t even get the menu item.
Now, you can edit your wp-includes/capabilities.php to really play with the current_user_can function. The example given in the Codex for it is
< ?php current_user_can( $capability , $object_id ); ? >
And the specific use case is
current_user_can( 'activate_plugin', 'my-plugin/my-plugin.php' )).
Now, that may look kind of confuzzling if you’re not totally into PHP, and I get that. So here’s the breakdown of what you can do, and why it’s cool.
- activate_plugin – you can pick a single plugin the user has access to activate
- deactivate_plugin – the exact opposite of the above–a single plugin the user can deactivate
- deactivate_plugins – general access to disabling any plugin on the site
In English your syntax basically says “BJK can activate/deactivate the Divi Builder plugin that is located here”. It’s pretty simple, honestly, and, for example, gives your clients access to enough of their site they can customize it without whitescreening it.
Thanks, 4.9!
English? Do You Speak it?
No? Oh, that’s cool. Because in WordPress 4.9, users can adjust that, too. It’s not a huge feature that most people will take advantage of, but the focus in 2017 on languages and getting WordPress more distributed internationally means that the install_languages and update_languages functions are a necessary step in that direction.
Basically 4.9 gives you more specific control on whether a user is linked to wp_can_install_language_pack(). If the user can install_plugins, install_themes, or update_core, they will automatically have install_languages and update_languages.
Functionally, nothing changes from how it is right now, but it will allow more control for folks who need it, which is never a bad thing.
Secure the Hatches!
In a very small-but-important update, 4.9 prevents users from being flagged as do_not_allow, which directly (and sometimes wackily) interacts with the other permissions and granulations that the update introduces. By preventing this $capability, core contributors are protecting us from ourselves a bit.
Multisite Improvements
Again, this series of updates might not pertain to you, but there’s a good chance it does. WordPress multisite is an absolutely fantastic feature, and if you’re not taking advantage of it, there are a lot of good reasons to.
That said, things can get kind of complicated regarding WordPress user roles when dealing with a network installation. You’re dealing with a lot more than simply who can and cannot update plugins and edit posts.
Prior to 4.9, user capabilities would be set in switch_to_blog() or restore_current_blog() which aren’t necessarily the most user-friendly functions. We now get to use wp_switch_roles_and_user() which eases the server load by essentially combining the two previous functions into one that has a bit better logic behind it.
In similar fashion, the notes indicate that the interactions between WP_User and WP_Roles make a lot more semantic sense. Instead of WP_User::for_blog() and WP_User::_init_caps() (which indicate which capabilities you want to initialize for each user per each blog), you will be using the new WP_User::for_site().
When you initialize WP_User::for_site(), you can then call get_site_id() to filter through all the roles and capabilities the user has on a site-by-site basis.
On top of that, multisite had a ton of smaller bug fixes that were addressed in 4.9. You can read about them here. It is very interesting to note that multisite wasn’t a huge focus for the core contribution team this year (and indicated by the 2017 State of the Word Q&A session), but there are still a number of people who feel very strongly about its use and that it needs to be kept up as much as any of the more-known and more-used elements of the WP Core.
These 4.9 improvements are just proof that side of the community puts its money where its mouth is.
Digging Into Files
The real problem with this update is that the permissions and capabilities aren’t easily accessible from the WordPress admin dashboard. You can’t just click on Users -> All Users and get access to these new changes. You need to get into the PHP system files to change it up.
Now, this tends to be the case with any user role updates, as well, and the newest changes aren’t actually unique to that. There are a lot of methods and capabilities you can already adjust, and the best way to do it is the User Role Editor plugin on the WP.org repo.
Just keep in mind the plugin hasn’t implemented the new 4.9 methods and such, but that’s okay. I spoke with the plugin author prior to this writing, and he assured me the new roles and options would be included in the 4.40 version of the plugin.
It’s been tested with the newest version of WordPress (4.9.1 as of this writing), and nothing has been broken. So if you’ve only now been introduced to the world of user role customization, and you or your clients need the extra control you can get, you should definitely check out the User Role Editor plugin to see if you can do what you need.
And when you’ve used the plugin to get a handle on it, you’re more than ready to dig right in and work on the new 4.9 user roles.
Article thumbnail image by PODIS / shutterstock.com
The post User Roles and Permissions in WordPress 4.9 appeared first on Elegant Themes Blog.
