First, thank you to everyone involved in the development of Bedrock, Sage and Acorn. Working with Laravel in WordPress has been really enjoyable!
I’m excited to introduce wp-user-roles, a new Acorn package we’ve built to simplify managing user roles in WordPress. wp-user-roles aims to make role management straightforward by providing a configuration-based approach to defining and managing roles and capabilities.
Here’s a quick rundown of the package:
• Configure: Define custom roles and capabilities with a configuration file.
• (Re)Create: Insert roles into the database with a single wp-cli command.
• Clone roles: Quickly set up new roles based on existing ones.
• Delete roles: Remove any roles that you don’t need.
For a full list of configuration options, check out the config file in the package.
Since roles and capabilities are defined in a config file instead of the database, they can be stored in version control, making it easy to track changes and maintain consistency across all environments. We run the wp acorn roles:create command during each deployment.
If you give it a try, I’d love to hear your thoughts! Any feedback is valuable as we continue developing this package.
This seem promising! One thing I can’t figure out, though: during the “Reset core roles” step, it seems to be removing capabilities that have been previously added to core roles by other plugins or CLI commands.
I like the idea a lot, but it seems like it needs:
a config parameter for “don’t change this role at all”
The goal of this package is to manage roles and capabilities entirely through the configuration file, providing complete control and versioning.
Many plugins add or remove capabilities dynamically—on hooks like activate_{$plugin}, init, admin_init, or elsewhere. This means that even if we set up the desired capabilities initially, other plugins can modify them at any time. To address this, our approach is to use the clone feature to create custom roles based on core roles and then remove the core roles entirely.
We reset core roles before creating custom roles to make sure that our clones have the original capabilities.
The limitations you mentioned – resetting core roles and no way to alter them --are intentional to align with this approach. That said, I’m happy to consider changes if they help make the package adaptable to your workflow!
I could introduce an optional configuration array for each role like this:
Aha! with that objective your approach makes a lot of sense. You’re right that dynamic capabilities can be messy. The clone mechanism is a wonderful idea.
I do think a configuration array on the core roles would make sense and make the package more widely usable. I’d actually tried adding one with 'add' => [ 'caps' => [...]] just to see if it worked, so it might be a natural expectation? reset => false seems particularly good to avoid breaking capabilities that other plugins might be anticipating.
Brainstorming a bit further… it would be extra-useful to have a “capabilities diff” command that reports any divergence between a role’s caps stored in the db and what’s defined in config/user-roles.php. That way a dev can detect any weirdness before overwriting it on deployment. (Oh dang, now I really want a log of capability changes somewhere…)
Absolutely no rush for any of this on my account, should you decide to pursue it.
(Also, because I’m curious: what’s the reason you chose to depend on the WP-CLI packages, Role_Command, and so on, rather than calling WordPress’s WP_Role and WP_Roles classes directly? Is there something more practical about the CLI interface?)