Contents
Migrating from other role plugins - Plugixa Advanced User Role Editor
If you have been using Members, User Role Editor or another role plugin, you do not have to start again. In most cases there is nothing to migrate at all.
Roles on the same site need no migration
Roles and their permissions are WordPress’s own data. A role plugin edits them; it does not own them. So the roles you built with another plugin are ordinary WordPress roles, and when you open Plugixa Role Editor -> Roles they are already there, exactly as they are, with the people who hold them.
The same is true of permissions another plugin set directly on an account. They appear on that person’s page as extra permissions, and Health check reports how many accounts have them.
This plugin does not read another role plugin’s settings and does not need to. Everything it shows comes from WordPress itself.
What you will notice
- Blocks are kept. A permission another plugin stored as explicitly denied shows as blocked on the role page.
- Unusual combinations show as “Custom”. A role whose permissions for an area match none of the plain-language levels shows “Custom” and the exact permissions, never the nearest level. See Editing a role.
- Your starting point is saved. When this plugin is first activated it takes a restore point named Before this plugin was installed. Whatever you do afterwards, you can return to the roles as the other plugin left them. See History and restore.
Moving roles from another site
When the roles are on a different site, bring them over as a file under Safety -> Export and import. The importer reads three formats:
| From | File | What arrives |
|---|---|---|
| Members | Its JSON export | Each role’s name, its granted capabilities, and its denied capabilities as blocks. |
| User Role Editor | A role CSV, with roles across the first row and one capability per row | Each role’s name and its granted capabilities. |
| This plugin | Its own JSON export | Each role’s name, with granted and blocked permissions. |
Details worth knowing before you start:
- Members. If a capability is listed as both granted and denied for a role, it is imported as blocked.
- User Role Editor CSV. A cell that is filled in (and not
0) counts as granted. The CSV format cannot express a block, so nothing imported from it is blocked. An empty cell means “not granted”, never “blocked”. - Detection is by content. The file is recognised by its structure, not its name.
Nothing is written when you choose the file. You get a preview role by role and decide for each one: Create it, Replace what is here, or Leave it alone. Roles that already exist on the site start as Leave it alone. The full walk-through is in Export and import.
What a file does not carry
- People. None of the three formats says who holds which role. After importing, assign roles in People.
- Permissions set on individual accounts.
- Anything else the other plugin did, such as content restrictions or menu rules. Those are that plugin’s own features, not roles.
If a role cannot be imported
You can only import permissions you hold yourself. A role containing one you do not hold is marked Cannot be imported with the reason. Import from an administrator account.
Leftovers and “Unknown source”
Every plugin that adds permissions leaves them on your roles when it is deleted. After years of plugins coming and going, roles often hold permissions nothing uses any more.
The editor labels each permission with where it comes from. A permission that a role holds but nothing active on the site registers is filed under Unknown source, on role pages and in Configuration -> All permissions.
An unknown source is not always a leftover, so the plugin looks at what is installed and says which case it is:
| What you see | Meaning | Clean-up |
|---|---|---|
| “Probably from [plugin]” | It looks like it belongs to a plugin that is installed and active but does not announce its permissions. | Not offered. “Kept, because an installed plugin probably uses it.” |
| “Probably from [plugin], which is switched off” | The plugin is installed but deactivated. | Not offered, for the same reason. |
| “Nothing active on this site says it uses this. It may be left over from a plugin that was removed.” | A real leftover. | Offered. |
For a real leftover there are two actions:
| Action | What it does |
|---|---|
| Remove from all roles | Takes the permission off every role. “A restore point is saved first, so this can be undone.” |
| Manage as added by you | Keeps it and lists it under “Added by you”, so site administrators can give it out and take it back like a permission they added by name. Use this when your own code or theme checks it. |
If you have just deactivated your old role plugin and it added permissions of its own, this is where they turn up. Delete that plugin first and they become ordinary leftovers you can remove.
A sensible order of work
- Install and activate this plugin while the old one is still there. The “before this plugin was installed” restore point is taken.
- Look at Roles and People. Check that what you see matches what you expect.
- Open Health. It lists roles that can take over the site, identical roles, accounts with no role and leftovers.
- Export your roles from Export and import and keep the file.
- Deactivate the old plugin. Your roles do not change when a role editor is deactivated; they belong to WordPress.
- Tidy up leftovers under Unknown source once the old plugin is deleted.
Running two role editors at the same time means two tools changing the same data. If somebody changes a role elsewhere while you have it open here, your save is refused with a message asking you to reload, so their change is not silently undone.
What to do next
- Import a file with Export and import.
- Review leftovers in All permissions.
- Run the Health check.