WP ADMIN : Sorry, you are not allowed to access this page

@roitsco Nope. I still have the same problem. I can get past it to the , but I cannot access the dashboard main page, or the update page or use JetPack.

After loggin in I am taken to the url https://www.mysite.org/wp-admin/ with the message “Sorry, you are not allowed to access this page”.

If I then delete the “/wp-admin” part of the url I go to my website and am still logged in.

If I mouse over the speedometer icon with my site name there is no drop down menu.

If I click the updates icon I am taken to the url https://www.mysite.org/wp-admin/update-core.php with the message “Sorry, you are not allowed to access this page”.

If I click the comments icon I am correctly taken to the url https://www.mysite.org/wp-admin/edit-comments.php with no error. From there I have access to the left hand wordpress menu and all menu choices seem to be working. Apart from JetPack that is.

@geirrosset Good job, at least you found your own way to bypass it.
It won’t work for me though. I literally have no access to my own site. I don’t know what else to try.

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.
Its resolved here https://www.naijatechzone.com/wp-admin-login-error-sorry-you-are-not-allowed-to-access-this-page/

@roitsco @geirrosset

Solution that worked best for me was simply recreating the wp-config.php file. All information was copied from the old wp-config.php, and was placed into a copy of the default WordPress wp-config.php

I assume that there may have been a piece of information placed in the wrong area inside the old file, or perhaps a special character that was visually similar but interpreted as code preventing the file from executing properly.

Anyway, it beats having to mess with your database and it worked for me. I thought I’d share just in case it helps you. Let me know.

• This reply was modified 7 years, 5 months ago by goblack.
• This reply was modified 7 years, 5 months ago by goblack.

@andy-schmidt

Although not likely the problem for THIS user, this particular message will occur when someone “consolidates” various WordPress projects into a single MySQL schema, and in the process CHANGES the table prefix in the wp-config and renames the tables to match the new table prefix (e.g. from “wp_…” to “mywp_…”.

There is a very unexpected dependency of the table prefix in a handful of records in the wp_usermeta table and one in the wp_options

Thanks so much. Your suggestion saved me hours. I would not have thought of that at all and was just about to start going through plugins and themes.

@andy-schmidt Brilliant, sir. This is the right answer. I had followed instructions to add a wordpress administrator, which included using ‘wp_capabilities’ as an entry for ‘meta_key’, on a website which used a custom prefix. Changing wp_ to the correct prefix allowed me access to the admin dashboard.

@brimfulof @stevenmartis – Gents, thanks for confirming this was behind your troubles. According to the source code the table name mismatch seems the most likely scenario.

I do realize, others have not been as lucky – but I haven’t been able to get a backup to one of their tables to track down how their situation differs.

@andy-schmidt you’re the man! This is very useful information to keep in mind for future implementations! I’ve setup several multisites and with this one we had to change the prefix during multisite setup and got the dreaded access message – you came to the rescue!

Although not likely the problem for THIS user, this particular message will occur when someone “consolidates” various WordPress projects into a single MySQL schema, and in the process CHANGES the table prefix in the wp-config and renames the tables to match the new table prefix (e.g. from “wp_…” to “mywp_…”.

There is a very unexpected dependency of the table prefix in a handful of records in the wp_usermeta table and one in the wp_options. Fortunately, it’s very easy to fix. Just look for a key starting with “wp_” (the default table prefix) and then change those rows to the keys matching the new table prefix in your wp-config, e.g. “mywp_”.

Basically, your “admin” user has “login” permission, but those records in wp_usermeta and wp_options are the ones that give that logged-in user permission to manipulate the data stored in a particular set of tables. It’s likely a carry-over from the MultiSite implementation.

I followed this (https://edwiser.org/bridge/documentation/) but I can’t synchronize users between wp and moodle and I can’t find “‘Users‘ tab in the admin menu”

Example when WordPress create user then the same user has to work in the moodle also but its not working

@dmishra – I don’t know how you ended up on THIS thread. But if you have a question that is about “edwiser”, “moodle” etc, then I suggest you contact THEIR support resources because THERE will be experienced users who have succeeded at what your are attempting.

Or, you could start a NEW topic here at the WordPress support site, but with a telling subject line that has a chance to be noticed by other users of “edwiser” and “moodle”.

THIS thread is about a very specific error message in WordPress. Hijacking it for mainly non-related questions will prevent your question from being noticed by competent others.

Thanks @andy-schmidt
Problem resolved by updating table prefix in wc_<prefix>_users, wc_<prefix>_metadata and wc_<prefix>_options.

@andy-schmidt, big thanks! I migrated over my subsite via direct database import and forgot to change the database row in wp_options named wp_user_roles. It should have been labeled the subsite ID which is wp_7_user_roles. I changed it, and my editor could gain access to admin. : )

If it helps anyone, I had a client who had buddypress installed and removed it, left his user roles as Administrator/Keymaster, was able to fix the issue by logging in, going to the front of the site, editing the page from the admin bar and then installing a plugin called Role Editor, and giving Keymaster all the same permissions as the administrator.

Nothing from this helped me(