Fixing “You do not have sufficient permissions to access this page” Errors
Chances are, you’ve run into this WordPress error at one time or another:
That’s a pretty unhelpful error message, isn’t it? Not only does it tell you nothing about what the exact problem is or how it occurred, but it’s also sometimes just plain wrong. Pretty often, it has nothing to do with insufficient permissions.
In this post, I will explain the most common reasons for why this error might show up, and offer some pointers for fixing it.
Probable cause
Below is a list of things that can cause a “You do not have sufficient permissions to access this page” error. Note that this list is necessarily incomplete – it only includes things that I’ve run into myself. If none of these match your situation, see the end of this post for additional resources.
– Wrong Dashboard page URL / Outdated plugins
Usually clicking on a broken link will result in a 404 Not Found error. Not so with the WordPress admin backend. Depending on the URL you try, you might actually get the “You do not have sufficient permissions…” message instead.
Specifically, this applies to all URLs that follow the “/wp-admin/something.php?page=menu_slug” pattern. If the “menu_slug” part is wrong, you’ll get the permissions-related error message instead of a 404. One way this can happen is if the plugin responsible for the menu uses spaces in the menu slug. That worked in old versions WordPress, but WP 3.0 and later will automatically remove spaces from menu slugs, resulting in a broken menu link. See this post for more details and a fix.
– Changing the table prefix
If you have recently changed the $table_prefix setting in wp-config.php – e.g. while migrating your site to a different server, or for security reasons – that’s probably why you’re seeing this error.
WordPress includes the table prefix in a couple of DB options and user meta keys, including those used to store user roles and capabilities. If you change the prefix without updating these options, WordPress won’t be able to load any roles or capabilities and all users will lose their access privileges.
To solve the problem, update the relevant entries in *_options and *_usermeta with the new prefix. See this page for details.
– Trying to modify the admin menu – moving items, changing access settings, and so on
Lets say you want to move Settings -> Cool Plugin Page to Posts -> Cool Plugin Page. Or maybe you’re trying to change the capability associated with a certain menu. Whatever the case, you’re likely to run into the “insufficient permissions” error sooner rather than later.
If you’re a WordPress developer, your best bet will probably be to invest a few hours in studying the WordPress source code to figure out how the admin menu works “under the hood”.
Here are a few specific gotchas to watch out for:
- Incorrect menu slugs or invalid characters in slugs (stick to alphanumerics).
- Slugs should be unique, but WordPress doesn’t count on it. It uses parent file + slug as the unique ID (hook name) instead. Move a page to a different parent, and it’s hook name will change, causing the menu to break.
- A slug can also be interpreted as a file name under the right conditions.
- If you want to change the required capability, updating
$menu
/$submenu
is usually not enough. Most plugins contain an extra hard-coded capability check.
Alternatively, if you’re not a programmer or just don’t have time to mess around, give my Admin Menu Editor Pro plugin a try. It’s specifically designed to work around most of the problems inherent in the current admin menu implementation.
Mini rant: Not to put too fine a point on it, but the current WordPress admin menu implementation is a terrifying mess of undocumented hacks and legacy code that’s liable to blow up in your face at the slightest provocation. Hopefully, WordPress 3.5 will include a saner admin menu API.
– You actually don’t have sufficient permissions
Though unlikely, it is possible that your user account really doesn’t have the capability or role required to access the page.
This is easy to verify: find the page you’re trying to access in the capability list on WordPress Codex and check if your user role has the necessary capability. If not, either add it yourself using User Role Editor, or ask your site admin to do it. If the page you need is not listed in the Codex (e.g. because it’s a plugin page), ask the plugin author about it, or use Admin Menu Editor to find out the capability associated with that page.
– Other possibilities
- Overly paranoid mod_security configuration.
- Registering admin menus on admin_init instead of admin_menu.
- Apache masquerading as IIS, or migrating from Apache to IIS.
- No security keys set in wp-config.php (only applies to users upgrading from WP 2.x to 3.x).
If you’re still getting the error…
- Search the WordPress support forum for the error message.
- Post a question in the How-To and Troubleshooting forum.
- Post a question on WordPress StackExchange.
- Hire a WordPres consultant to fix it for you.
- (Developers only) Set a break-point on wp_die() – that’s the WordPress function that displays the error message – and find out where it’s called from. Then move up through the call stack until you find the culprit. If you don’t know how to set a breakpoint or your IDE doesn’t support them, debug_print_backtrace() will do in a pinch.
Great article, solved my problem, actually in my case registering admin menus on admin_init instead of admin_menu was the issue. Thanks.
Hello! I see this is very useful in terms of navigation issues. Would you share any tips on how to make your site gain more traffic during this COVID-19 crisis? Thanks