The standard WordPress role hierarchy is a lie of omission. Administrator can do everything. Editor can publish but not break the site. Author can write their own posts. Contributor can submit drafts. Subscriber can comment. Five neat tiers, all wrong for the actual situation, which is: a client who needs to update prices on their menu, occasionally swap a header image, and absolutely cannot be allowed within six clicks of the Plugins page.
Editor is too restrictive. They can’t touch the menu page because it’s built in Elementor and Elementor needs Administrator for most of the useful bits. Administrator is too permissive. The first time a client accidentally deactivates Yoast trying to ‘tidy up’, you remember exactly why this is true.
So you start building custom roles. And this is where it gets interesting, because the moment you sit down with the Members plugin and start ticking capabilities, you stop being a web developer and start being a small intelligence operation.
You’re not designing for what the user wants to do. You’re designing for what the user must never, under any circumstances, be allowed to do, even if they specifically ask. You’re modelling threats. You’re building blast doors around the bits of the site that would cost you a Sunday afternoon to recover. The capability list reads like a charge sheet. activate_plugins – no. edit_themes – no. manage_options – absolutely not. delete_published_pages – I don’t trust anyone with this, including me.
You give them edit_pages and upload_files and edit_posts and then sit there for ten minutes trying to decide whether unfiltered_html is safe. It isn’t. Nothing is safe. The job is to decide what’s least dangerous.
Beurre was the project that broke me on the default roles. Connor needs to update the menu. He doesn’t need, and doesn’t want, to see Tools, Settings, Plugins, Appearance, Users, or Yoast’s full SEO tower. The site uses Elementor, WooCommerce, ACF, a custom menu plugin I wrote, FluentSMTP, MetForm, and about six other things that all install their own admin pages and assume the person logging in is me. Every one of those pages is a place where Connor could, with one well-meaning click, take the site down on a Tuesday afternoon during a cake-pickup window. Which would be funny, in the abstract.
The role I built for him is called Beurre Manager. It has Editor’s capabilities plus the specific Elementor caps for editing existing pages but not creating templates, the menu plugin’s edit capability, the WooCommerce shop manager caps for orders and products but not settings, ACF field editing on the front-end forms only, and that’s it. Tools is hidden. Settings is hidden. Plugins is hidden. Appearance is hidden except for the menus screen. Yoast’s metabox shows on pages but the full Yoast admin doesn’t. Users is hidden because nobody needs to know that nobody else exists.
Building this was about three hours with Members and User Role Editor and a lot of test logins in a private window to see what the role could and couldn’t see. Every time I missed something – oh, there’s still a ‘Customise’ link in the top bar, oh, the Elementor toolbar still shows a ‘Site Settings’ option that 403s – I’d shut that door too. Eventually it was tight enough that Connor’s login looked like a completely different CMS to mine. Which is the point.
By the end of it I had a spreadsheet of capabilities with green ticks and red crosses and notes in the margin about which plugin owns which menu item. It looked exactly like the kind of document Sloan would have on his desk. Need-to-know basis. Compartmented access. A friendly face on the front end and an internal threat model in the back.
The Federation tells itself it doesn’t have an organisation like Section 31. Nobody runs a multi-user WordPress site for longer than six months without becoming one. The interfaces look open and collaborative. The actual privileges are stripped back to almost nothing, and you’ve left yourself one super-user account that can see and do everything, which you only log into from a specific machine, which you definitely don’t talk about.
Connor can update his menu. He cannot, under any circumstances, deactivate WooCommerce. The site stays up. He’s never asked why his admin looks different to mine, and I’ve never volunteered. That’s how it works.