Within WordPress, site owners give control over different hierarchical permissions of users by using roles. For multisite configurations, the six available roles, in descending order of authority, are:
- Super Admin
- Administrator
- Editor
- Author
- Contributor
- Subscriber
Now, if you’re a project leader or run an editorial team, it probably makes sense to want to take the highest rank available. But let me explain why you should never use a Super Admin account on WordPress.
When you’re onboarded to a new project, you might have encountered something like this in the Local Setup section of the readme or wiki:
- Import database dump and replace URLs.
- Create yourself a user account.
- Make that account a Super Admin.
Here’s the question: is the last step a good default?
While for some projects there might be a (good) reason for this default behaviour – fixing lots of issues in a hurry, for example – it’s worth asking if underlying issues can be resolved so that people no longer have to be a Super Admin just so that certain functionality works as intended.
Things should break for you just like for anyone else
Super Admins are special in several ways. One is that ‘Super Admin’ is not an actual role in WordPress: it’s a special designation for users in a WordPress multisite installation, where each user has one or several roles on a per-site basis. They also have some extra-special network-wide administrator privileges.
Super Admins have certain capabilities that other users don’t have. Also, there are several places in WordPress that include special exceptions for Super Admins. This could mean that certain functionality or restrictions work differently between Super Admins and other users, or that certain restrictions do not apply at all. Here are some examples:
No matter what (meta) capability check, Super Admins can always do everything, unless someone explicitly disallowed this by using the do_not_allow special capability. Imagine you are using custom capabilities for managing a post type, or accessing a certain admin page. If you are a Super Admin, you have access no matter what. On the flip side, imagine there is a typo in a hard-coded capability string, or there is a bug in some permission-specific logic. If you are a Super Admin, it doesn’t matter, and you wouldn’t even know about it. But for other users, even other Administrators, it does!
Super Admins can use any HTML tag or attribute in the post content, but this can lead to problems. For example, imagine there were issues with SVG elements, or that a project is using a custom post type to prepare content for email newsletters with a specific or outdated list of tags and attributes used. This would get even more interesting in the Block Editor context due to the interactive block validation.
If a Super Admin user saved a post, it would look good on the front end for everyone. However, if a regular Administrator or Editor tries to edit that post, they will see broken/invalid blocks all over the place.
These are just a few examples, and there are more situations where being a Super Admin can accidentally allow or hide/mask things which, if you were not a Super Admin, you would realise instantly.
You don’t need to be a permanent Super Admin
If you really need to perform several or complex actions in the Network Admin, or something else that requires you to be a Super Admin, then be a Super Admin. You can do that in one of two ways:
- Temporarily make your user a Super Admin, and revert back once you’re done.
- Switch to a separate Super Admin user account.
Granting Super Admin capabilities to a user can easily be done with WP-CLI:
wp super-admin add <USER>And of course, it’s just as easy to revoke:
wp super-admin remove <USER>This means that you can act as a Super Admin just as long as you need to.
Or you could use a dedicated Super Admin account, either by logging in as that user—maybe in another browser or private tab—or by (temporarily) switching to that user.
Maybe you don’t need to be a Super Admin at all
Depending on what it is that you need to do, maybe you don’t actually have to be a Super Admin user. Instead, you might be able to use WP-CLI to do what you need.
Need to manage or add a new user? wp user <COMMAND> allows you to do just that.
Network-activate a plugin? You can do that by using wp plugin activate <PLUGIN> --network.
Manage the sites in your network? That’s what wp site <COMMAND> can help you with.
WP-CLI enables you to do so much, and most of the things take you much less time than in the admin interface. Maybe brush up on your WP-CLI skills? I, for one, use WC-CLI for certain things, but I know there’s a lot more I could/should do with it.
What about other tools or systems?
When working in your local terminal, or on some online stack, do you always execute commands as root? What’s your user when interacting with a DB? Is it the root-level admin? Presumably, the answer, most of the time, is ‘no’. So why would WordPress be treated differently?
Your WordPress experts are here
Ready to power your website with enterprise-grade performance?