The WordPress role system is one of the platform’s most powerful and most underused features. By default, WordPress ships with five roles — Administrator, Editor, Author, Contributor, Subscriber — each with a fixed set of capabilities. These five roles serve a simple blog model perfectly, but they become a straightjacket the moment your site’s organizational structure diverges from a simple editorial hierarchy. An agency, a WooCommerce store, an LMS site, a membership community, or a multi-author publication needs roles that don’t exist by default — and WordPress provides no native interface to create or manage them.

DominoRole’s Advanced Role Manager is the answer: a complete, modern wordpress user role manager module that provides full CRUD (create, read, update, delete) operations for WordPress roles through an interactive React-powered two-column grid dashboard. It is the core module from which all other DominoRole functionality flows — every capability assignment, every preset, every import/export begins with a role defined in the Role Manager.

The WordPress Default Roles Problem

Consider a growing WooCommerce store with this team:

• A content writer who creates product descriptions but shouldn’t have access to orders or customer data
• A shop manager who handles orders and inventory but shouldn’t touch plugins or themes
• An accountant who needs to view WooCommerce financial reports but nothing else
• A support agent who handles customer inquiries and order issues but doesn’t publish content
• A freelance developer who needs temporary administrator access for 48 hours

WordPress’ five default roles cover exactly zero of these profiles precisely. You can approximate some with the existing roles — give the shop manager the built-in Editor role, for example — but that gives them capabilities they don’t need and creates security surface area for your store. The only correct solution is custom roles, and that requires a wordpress role manager like DominoRole.

The Two-Column Role Grid: Design & Architecture

The Role Manager presents all WordPress roles in a responsive two-column card grid. Each role card displays:

• Role display name and Role ID (slug)
• Capability count — how many capabilities the role currently has
• User count — how many users are currently assigned this role
• Protection badge for default WordPress roles
• Action buttons: Manage Permissions, Clone, Rename, Reset, Delete (availability varies by role protection status)

The two-column layout is a deliberate UX improvement over the classic linear list used by legacy user role editor wordpress plugin solutions. With cards, you see more roles at once and the visual separation between protected system roles and custom user-created roles is immediately apparent — reducing the risk of accidentally modifying a core system role.

The grid is powered by a React component that loads role data from the REST API endpoint GET /dominorole/v1/roles on page mount. The response includes all roles, their capabilities as arrays, user counts fetched via get_users(['role' => $role_id, 'count_total' => true]), and protection status. All data is rendered client-side, making role grid interactions (opening permission modals, toggling capabilities) instant without page reloads.

Default Role Protection: Why It Matters

DominoRole implements strict protection for the five built-in WordPress roles:

These roles cannot be modified, reset, deleted, or cloned through the DominoRole interface. The protection is enforced both in the UI (action buttons are disabled for protected roles) and in the REST API (the permission check and role validation logic explicitly block protected role IDs at the server level).

Why this matters: Many user role editor wordpress plugin solutions allow you to modify default WordPress roles, including removing capabilities from the Administrator role — which can lock you out of your own site permanently. DominoRole’s hard protection of default roles makes the plugin safe for sites where non-technical administrators have access to the Role Manager.

Creating a Custom Role

To create a new role, click the + Create Role button in the Role Manager. A modal form requests two values:

• Role ID (slug): A unique lowercase identifier with underscores (e.g., community_manager, shop_supervisor). The plugin validates this field to ensure uniqueness and format compliance.
• Display Name: The human-readable name shown throughout WordPress (e.g., “Community Manager”, “Shop Supervisor”).

On submit, the plugin calls POST /dominorole/v1/roles with the role ID and name. Server-side, this calls WordPress’ native add_role($role_id, $role_name, []) function — creating the role with no capabilities except read (the baseline capability required to access the WordPress frontend). The new role appears in the grid immediately, with a card showing 0 custom capabilities and a “Manage Permissions” button to begin capability assignment.

Cloning Roles: The Fastest Way to Create Derivative Roles

Role cloning (Pro feature) is the most time-efficient way to create a new role that is similar to an existing one but with minor differences. The typical workflow:

1. Click the Clone button on any existing role card
2. Enter a new Role ID and Display Name for the cloned role
3. The new role is created with all capabilities of the source role copied exactly
4. Open the cloned role’s Permission Manager and add or remove specific capabilities as needed

Example: You want a “Senior Editor” role that has all Editor capabilities plus manage_options access to certain plugin settings. Clone the Editor role, name it “Senior Editor”, then add manage_options in the Permission Manager. Done in under 60 seconds.

The cloning API call hits POST /dominorole/v1/roles/clone with source and target role parameters. The server uses get_role($source_id)->capabilities to retrieve the full capability set and passes it to add_role($target_id, $target_name, $capabilities).

Renaming Roles Without Losing Users

The Rename feature (Pro) allows you to update the display name of any custom role while preserving:

• The role’s ID — users and database references remain unchanged
• All capability assignments — no permission changes occur during a rename
• All user assignments — users assigned to the role continue with the same role (now with a new display name)

This is important because WordPress stores role assignments using the role ID (slug), not the display name. Renaming a role through WordPress’ native role system (wp_roles->add_role) would create a new role ID, leaving the old ID orphaned with users still assigned to it. DominoRole’s rename operation correctly uses WordPress’ internal $wp_user_roles option to update only the display name key without changing the role ID.

Resetting a Role to Baseline

The Reset operation removes all capabilities from a custom role except read — returning it to the same state as a freshly created role. This is useful when you want to completely reconfigure a role’s permissions from scratch without deleting it (which would require you to reassign users).

The REST endpoint POST /dominorole/v1/roles/reset handles this by retrieving all current capabilities of the role, iterating through them, calling remove_cap() on each, and then re-adding only read. The operation is atomic — either all capabilities are removed or none are, preventing a half-reset state.

Deleting Custom Roles Safely

Deleting a role removes it from WordPress entirely. DominoRole handles this via DELETE /dominorole/v1/roles/{id} which calls WordPress’ native remove_role($role_id). For users currently assigned the deleted role, WordPress’ behavior is to leave them without a role — they can still log in but have no capabilities beyond those granted by the default no-role state.

Best practice before deleting: use the User Manager to reassign all users of the role to an appropriate replacement role before triggering the delete operation. The role card’s user count badge shows how many users would be affected.

Opening the Permission Manager from the Role Grid

Every role card in the grid has a Manage Permissions button that opens the four-tab Permission Manager modal for that specific role. This modal-based approach — rather than navigating to a separate page — means you can quickly switch between reviewing and editing permissions for multiple roles without losing your place in the role grid. The Permission Manager is covered in detail in the dedicated article.

REST API Architecture

All Role Manager operations use a nonce-secured REST API under the dominorole/v1 namespace. Endpoints:

Real-World Role Creation Use Cases

FAQ