can't access backend anymore after migration

i wanted to migrate a wordpress site that was hosted on microsoft azure to a new hosting company. i had some troubles making a backup with wp-clone so i asked for a sql dump, imported the database to the new hosting and uploaded all the files that i saved via ftp. now the page is running, i can login, but i'm always redirected to the home page and there's no way to access the backend. if i click on the admin bar nothing happens, if i add "wp-admin" to the url i get an error message "Du bist leider nicht berechtigt, auf diese Seite zuzugreifen." (you're not allowed to access this page).

any ideas what the problem could be? solutions? :slight_smile:

thank you already in advance!

ps: the affected website is http://highend-logistik.ch/ – as i can't access the backend, i couldnt add this page to the hub.

  • David
    • The Crimson Coder

    Hi Planzer, check if you have a firewall plugin on this site and if you just rename the folder for now. Then you should check .htacches file if there are some rules from that firewall in it.

    Check also if there are some special lines in wp-config.php file

    As I can see I get login screen without a problem may be the firewall just blocks your IP try to log in from other IP or go to the Database find the table where lockouts are stored and remove your IP from there.

    Kind regards

    David

  • Planzer
    • New Recruit

    hi david,

    thanks for your answer. i disabled all plugins, but the problem persists. i deleted the .htaccess file and uploaded a new one with only

    “# BEGIN WordPress

    <IfModule mod_rewrite.c>

    RewriteEngine On

    RewriteBase /

    RewriteRule ^index.php$ – [L]

    RewriteCond %{REQUEST_FILENAME} !-f

    RewriteCond %{REQUEST_FILENAME} !-d

    RewriteRule . /index.php [L]

    </IfModule>

    # END WordPress”

    that the permalink structure works, so there’s nothing in the file that shouldnt be there.

    i downloaded a fresh version of wp-config.php and just added the required infos, but it didnt help at all.

    if my ip was blocked by a firewall i couldnt login, but actually i CAN, but i can’t get to the backend :S any other ideas?

  • David
    • The Crimson Coder

    Hi Planzer,

    If I am understood you correctly you don’t even get to the login screen. Am I right? If that is the case please can you try using another network to log in? Try thro your phone provider and not to use your wifi from the same network you are currently connected.

    That is often the case when moving the site and you forgot to clear the cache before backup.

    Regards

    David

  • Adam Czajczyk
    • Support Gorilla

    Hello Planzer

    This looks to me like an issue with user roles/capabilities. You were importing a database dump to a new database, correct?

    Are you sure that this db dump used was full and wasn’t missing any tables and/or wasn’t corrupted? Did all the tables got imported properly?

    And: is a different db table prefix used on that migrated site than it was used on the original one? If so, you’ll probably also need to update options names in the db. Easiest way would be to use phpMyAdmin and check this, let me explain:

    Let’s say that my site was using default db prefix of “wp_”. The “usermeta” table name would be then “wp_usermeta”. If I migrate the site and the prefix changes to, let’s say, “free_” the table name will become “free_usermeta”, right?

    Then the thing to check in that table would be the “capabilities” and “user_level” option names. In many cases like this that option name would still be

    “wp_capabilities” and “wp_user_level”

    instead of

    “free_capabilities” and “free_user_level” respectively.

    To sum it up: those options’ names must use “prefix” that is matching db table current prefix and it often is an issue after migration.

    The other thing that also happens often is that actually the default role capabilites get messed up in the database and must be restored but if that was a “manual” migration that’s rather unlikely.

    Best regards,

    Adam

  • Planzer
    • New Recruit

    hi adam,

    yes, thats what i think as well… must be some user role problem. correct, i imported a dump to the new database. to me it looks like all the tables were imported properly – i checked with “http://highend-logistik.ch/wp-admin/maint/repair.php&#8221; and there were no errors.

    it actually is a different prefix – i just changed it for al the tables, but not in the options. question: do i have to replace ALL wp_ to the new prefix or just on _capabilities and _user_level? cause doing it on these two options for my admin user it didnt help yet.

    how could i reset the role capabilities?

  • Adam Czajczyk
    • Support Gorilla

    Hello Planzer

    Thank you for response and I’m sorry for the delay

    do i have to replace ALL wp_ to the new prefix or just on _capabilities and _user_level? cause doing it on these two options for my admin user it didnt help yet.

    For all the users the “_capabilities” and “_user_level” should start with the same prefix as the current prefix of the db tables is.

    One more thing that you might want to check is if there’s any server-side caching. If there’s anything kind of “object cache” there this might need to be flushed after changes were made.

    The other thing to do might be, as we mentioned earlier, restoring default WP user roles. That’s something that can be done via database (just make sure that you do have full DB backup, you can e.g. make export to the file from phpMyAdmin – just to stay safe) but be careful as it’s so called “serialized array” so it’s very easy to break.

    The best way to do this would be to do as follows:

    1. setup a default, fresh WP install (single site) anywhere – on that new server in some subfolder or in some local environment, that doesn’t matter, the point is to have a minimal default working installation (of course using a different database – fresh one as well).

    2. on that new install access the database via PHP my admin and in the “wp_options” search for the “wp_user_roles” option_name

    3. copy entire content of the option_value and replace the “wp_user_roles” option value on that install that you’re trying to fix with it.

    I hope you got the idea, I’m not sure if I explained it clearly.

    However, that being said, before doing that, this would be also the option that needs to use correct prefix. So before trying to restore the roles, first fine “wp_user_roles” option in “wp_options” table on your broken site and make sure that the _user_roles prefix is matching db table prefix.

    Please note: I’m still using “wp_”prefix here just for explanations so you’ll have to adjust that to match your site’s current setting.

    Best regards,

    Adam