4

I just upgraded to WordPress 4.6, and now when I try to click on the Settings link on some of my plugins I get this "Sorry, you are not allowed to access this page." message.

I can active/deactivate the plugin fine but for some reason I can't go under the settings view.

I tried following some of the methods that other people used to fix this; like adding a new administrator and updating the "wp_capabilities" and "wp_user_level" values in the DB but it still does not work.

Does anyone know how I can further debug or resolve this issue?

6
  • How did you perform the upgrade and did you upgrade the plugins at the same time? I've seen that error on occasion when a file or folder within a plugin had the wrong permissions - like maybe I uploaded a file via FTP that had a security block on it.
    – Michelle
    Commented Nov 22, 2016 at 18:05
  • I upgraded to 4.6 from admin first and then I updated the plugins afterwards from admin as well.
    – olimits7
    Commented Nov 22, 2016 at 18:06
  • Have you tried uninstalling / reinstalling one of the plugins that's not working? Sometimes deactivating isn't enough.
    – Michelle
    Commented Nov 22, 2016 at 18:07
  • One of the plugins I'm having this issue with is the "Hello Bar" plugin. I just tried uninstalling / reinstalling this plugin and it gives me the same message when I click on the "Settings" link...WP can be very frustrating at times!
    – olimits7
    Commented Nov 22, 2016 at 18:13
  • Here's a bunch more things to try: wordpress.org/support/topic/…
    – Michelle
    Commented Nov 22, 2016 at 18:16

8 Answers 8

0

I discover this message “Sorry, you are not allowed to access this page” mostly occur when various WordPress sites are in the same phpMyAdmin – all bearing the same table prefix, irrespective of the database name. I can’t tell how many WordPress sites are expected to be in the same phpMyAdmin with the same table prefix.

2
  • Hi - as links to external resources can become stale, could you please expand your answer so it can stand alone? Commented Jun 8, 2017 at 20:49
  • 1
    This makes no sense. phpMyAdmin has nothing to do with it. Your Wordpress install will only look at one database in your MySQL server. Assuming your not trying to install multiple sites to the same database with the same prefix this should never be a problem. Can you explain how this answer actually solves the problem from a technical point of view?
    – Lightbulb1
    Commented Nov 10, 2018 at 0:10
13

If you have https on WordPress and you added below code on wp-config.php,then be sure that lines must be on top of page. I found this issue. And may be it can help.

define('FORCE_SSL_ADMIN', true);
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
    $_SERVER['HTTPS']='on';
2
  • How is this related to the error on one specific page only? Please explain this in your answer.
    – fuxia
    Commented Oct 23, 2018 at 15:04
  • 4
    This fixed it for me. To clarify why this is relevant: people who use a reverse proxy and https may need to add those lines, see: wordpress.org/support/article/administration-over-ssl The documentation, however, does not clarify that they need to be on top of wp-config. I put them at the bottom, and got the message "sorry you are not allowed.." Wasted time on all other solutions which were of no use, until I found this one.
    – giocomai
    Commented Nov 2, 2019 at 20:33
2

According to me Login into PHPMyAdmin goto wp_usermeta then edit wp32_capabilities of any user and add this a:1:{s:13:"administrator";s:1:"1";} It will change the user Privilege to admin. There are several reasons it will change and you will get the error.

I was getting this error on my website and I try this only once and it was resolved.

1
  • Yes, in my case there was no row for 'wp_capabilities' or 'wp_user_level' in wp_usermeta for the new admin user I had created. I created 2 new rows with the above & wp_user_level = 10
    – 00-BBB
    Commented Sep 3, 2019 at 14:02
1

Also search wp-setting.php file for "define('DISALLOW_FILE_MODS',true);" and delete it. Non of the above solutions worked for me except this one!

1
  • But your change will be lost after WP update, won't it? Commented Nov 29, 2018 at 7:08
1

You can keep more than one WP as long the prefixes are different and do not collide, this post has the fix for the access error when changed the prefix but facing the error: https://www.mysysadmintips.com/other/web/743-wordpress-admin-sorry-you-are-not-allowed-to-access-this-page

0

By default, capabilities will be assigned to “Administrative” and “Editor” role when plugin runs for the first time. You can add or remove capabilities for user by using a great plugin named Members if its not there.

0

Wordpress shows a default 403 page when any of a handful of backend events occur:

  1. The user is not allowed access because their role has incorrect permissions
  2. The backend page is not found, which happens when a plugin or theme is no longer active and left relic data in the database, or when it is misrouting its admin page because it is misconfigured. This often happens if you use url rewrite plugins, and they do not handle the backend uris correctly or omit rewriting them. This often also leads to being locked out of the login screen.
  3. There is an error with the internal core routing mechanism, and it receives a result it doesn't understand, can't process, or maps to an unrecognized schema
  4. A critical but not fatal error occurs during the routing step for the dashboard

In your case, it is probably the 3rd possibility. Wordpress core code does not do very rigorous type checking, and it typically proceeds through its internals without really spending much time on verifying that the data it received was properly formatted or is valid for the current purpose. This results in very strange and difficult to diagnose errors frequently if you do not understand how the core internals work.

The following remedies are in order as a preliminary preflight:

  • Make sure that each site running on the same installation has its own database assigned, which has its own dedicated user that does not have permission to access any other database within your cluster. For example, when you login to PhpMyAdmin as root, you have access to the entire cluster. For any given application, it should have a dedicated database and user within your cluster, and the user should not have access to any other database in your cluster unless it is a shared resource created explicitly for data to pass between two applications. This alleviates the likelihood of your application getting confused by trying to fetch data from the wrong database, and prevents any issues with collisions between two or more wordpress installs with identical prefixes. Do not put two wordpress installs in the same database or they will both break.
  • Check the network panel in your browser web inspector and check the error code for the request. If it is a 403 (it should be), then the issue is either the page doesn't actually exist, or the user lacks permissions. If it is a 500 (it should not be), then it means that the server encountered an error and fell back to the standard exit procedure. If it is a 500, you have a bad plugin, theme, or database issue to handle. If it is a 403, it is most likely one of a bad update, incorrect configuration, or legitimate access denied.
0

Change table prefix to "_" in wp-config.php and save. Then try load wp-admin/. you might see a new install message. Don't install, go back and change prefix again to "WP". This worked for me. I am not sure this will work for everyone.

before: $table_prefix = 'wp_';
in between: $table_prefix = '_';
after: $table_prefix = 'WP_';

1
  • A similar resolution resolved the 403: Sorry, you are not allowed to access this page message. In my case on migrating to a new server the database table names were changed to lowercase, including those referenced by $table_prefix. Updating $table_prefix to lowercase allowed the frontend to function however /wp-admin threw the 403 error. The solution was to check the database for references to the original uppercase prefix. For example the _usermeta.meta_key table had multiple instances of the original uppercase prefix. Commented Jan 10, 2023 at 12:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.