Support

ANGIE, the restoration script included with all Akeeba Backup archives, tries its best to detect and fix potential problems on restored sites. However, there are practically infinite variations of how your site is built, how your site is configured and how your server is set up. In very few cases you'll end up with a site that requires a manual touch to make it work better.

Generally, you have to make sure that there are no settings transferred in files from your old server which are incompatible with your new host. The most notable culprits are .htaccess and local php.ini / .user.ini directives. This page details our experience with these issues, why they happen and how to deal with them.

.user.ini and php.ini files

Some plugins, especially security plugins, put a php.ini and / or a .user.ini file in your site's root and possibly other site folders such as wp-content. These files modify how PHP works and could possibly include references to .php files which have to be forcibly loaded whenever you access any other .php file on your site.

ANGIE tries to detect such files in the site root only and offers to remove them for you. If this was not the case for your site or if you were using a backup taken with a very old version of Akeeba Backup / Akeeba Solo please delete these files manually. Please do keep in mind that the .user.ini file, like all files whose name starts with a dot, is invisible (hidden). You may have to ask your host to help you set up the file browser on your hosting account to display these files.

.htaccess / web.config files and moving your site to a different server, folder, domain, subdomain or disk location

.htaccess files are used with Apache and LiteSpeed web servers to modify how your site works. web.config files have the same purpose on Windows servers which use the IIS (Microsoft Internet Information Services) web server. Both WordPress and some of its plugins will modify the content of these files in a way that's specific to the site currently in use i.e. its URL, its disk location, whether it's single or multisite and whether it's in a subdirectory or the domain's root. This is typically done to make permalinks works as well as adding advanced features on your site such as caching and added security.

ANGIE will not touch web.config files and will not convert from web.config to .htaccess or vice versa. If the site you backed up from or the site you are restoring to is using the IIS web server you will have to handle these files yourself.

ANGIE will modify .htaccess files when you are restoring on a new server. However, not all site transfer and .htaccess files are the same. The following paragraphs will explain the different possibilities and what you can do.

ANGIE knows how to reliably handle a few things that are predictable in every site transfer (only applies since Akeeba Backup for WordPress 3.4.0 -- backups taken older versions require manual changes in the .htaccess):

The rest of the .htaccess rules can be edited automatically in a mostly reliable manner if you are transferring a WordPress site:

When you are transferring your site from the root of your domain / subdomain to a subdirectory (e.g. from http://www.example.com to http://localhost/mysite) things get complicated. ANGIE will attempt to change most common .htaccess rules typically generated by cache and security plugins. However, some rules may not be replaced correctly or at all. This is not a bug, it's a limitation coming from the nature of .htaccess files. Even an experienced human has a hard time editing .htaccess rules in this case.

Therefore, if your site no longer loads correctly, instead throwing 404 errors, we strongly recommend doing a regeneration of the .htaccess file. First, open the .htaccess file with a plain text editor and remove anything outside the # BEGIN WordPress and # END WordPress markers. Then log into your site's wp-admin and visit the settings of the plugins which generate .htaccess directives. These are typically caching and security plugins. Make sure their configuration matches the new site's location and have them regenerate the .htaccess content. Instructions for each plugin should be sought with the developer of the respective plugin; we cannot reasonably know how each version of every plugin works unless its something that we happen to use ourselves. Instructions for Akeeba Admin Tools are to be found below.

If your site was using the .htaccess Maker feature of Akeeba Admin Tools for WordPress

If you have used Admin Tools' .htaccess Maker please remember that after restoring the site to a different location you will need to reconfigure the .htaccess Maker before creating new .htaccess content. This is necessary because of the way its configuration is stored in the database, not allowing ANGIE's data replacement step to modify it.

If you cannot access your site at all first follow the instructions in the previous section to remove Admin Tools' content from your .htaccess. You can find it between the # +-+-+ Admin Tools for WordPress - Start and # +-+-+ Admin Tools for WordPress - End markers. Delete these markers and the content between them before accessing your site. This disables all .htaccess Maker rules so you can log into your site and regenerate this content.

Login to the wp-admin of your site, go to Admin Tools, .htaccess Maker. Change the domains and the directory names at the bottom of the page to reflect the new site's location. Finally click on Save & Create .htaccess. This is mandatory, every time you move your site to a different host, domain name, subdomain or directory.

My site cannot connect to the database

Some hosted WordPress services have a non-standard wp-config.php file. In these cases there's an if-block surrounding two sets of near-identically looking define lines, one for use with the live site hosted on the service and one for use on the local site.

ANGIE only tries to modify the first set of defines with the new database connection information. If this is not the correct one you will need to change the database information on the second set of defines further down the file to reflect your new database connection information. This is a limitation of how PHP works; trying to locate these non-standard if-blocks is nearly impossible in an automated manner.

.htaccess directives which control how PHP works

Look in your site's .htaccess file for directives such as php_value, php_flag and AddHandler. Try commenting them out (putting a hashtag # in front of the line) to see if it helps.

Usually they have a format like this:

AddHandler application/x-httpd-php5 .php

You most probably have to remove those lines beginning with AddHandler, especially if your problem is that you get a bunch of code, or the web browser offers to download index.php, instead of your site's front page. You most certainly have to remove such lines if you are restoring on a local server. Please note that these directives are server-specific. As a result, ANGIE cannot know if they will work on the site you are restoring to or not, so it leaves them in place in the interest of not removing information it can't possibly know how to handle.

You should also try commenting out lines (by placing a single # character in front of them) which look suspicious to you, because any of those directives may cause trouble.

Redirections in .htaccess

Check if you have redirections in your .htaccess file, for example directing all traffic to the www prefixed site or to a specific domain, e.g. all traffic to www.example.com, even if it referenced example.com or example.net in the URL. Such problems are easy to spot because you have put this code in the .htaccess file and you should know about what it does. Just remove it or comment it out.

Please note that by default ANGIE will replace the old site URL with the new one. However, redirection rules may be written to use partial matches or regular expressions which make it impossible to automatically convert them (even as a human, you need to know the intention behind them to modify them). Therefore, not replacing these rules automatically is not a bug.

The mere presence of a .htaccess file

You should note that some servers do not accept .htaccess. Putting such a file on your site's root will make the server throw an HTTP Error 500: Internal Server Error as soon as you try to access your server. If this happens, you need to have a little chat with your host.

Enabling Apache's mod_rewrite

If you are restoring on a local host, you have to make sure that your server is loading the mod_rewrite module, otherwise you will most assuredly get a blank page or a 500 Internal Server Error.

If you are using WAMPserver on Windows you must note that mod_rewrite is not loaded by default. In order to enable it, you have to click on WAMPserver's tray icon, Apache, Modules and make sure that Rewrite is checked. If not, click on it and wait for the server to restart. This is required only the first time you restore to a WAMPserver installation and only if you have SEF URLs turned on and you are using Joomla!'s .htaccess file.

Other local servers, like XAMPP, also come with the mod_rewrite Apache module disabled. These servers require you to edit the httpd.conf or run other system commands. Please consult your server package's documentation for more information on enabling mod_rewrite.

Some live hosts also do not have Apache's mod_rewrite enabled. Please consult your host. We can not help you with that. It's all up to your host and how they configured their server.

Special note for GoDaddy users

GoDaddy users will find out that the .htaccess changes need 10-30 minutes to take effect. This is a limitation of your host. Normally, these changes should take effect immediately, as happens with pretty much every other host including local installations. Feel free to write an email to GoDaddy and urge them to fix this behavior. Please don't write to us claiming that changing the .htaccess bears no result. We know! You just have to wait... and wait... and wait some more. Sorry, this is not up to us and it does affect all software which needs to modify the .htaccess to work properly, including WordPress itself and its permalinks feature!

Redirection and SEO plugins

Sometimes restored websites redirect to the original site even when there is no such parameter in .htaccess and everything else is replaced correctly in your database. In this case, please check if you have any SEO plugins installed, including any plugins which might be redirecting non-SSL to SSL URLs or vice-versa. Many such plugins and components store absolute URLs (URLs which include the domain name) causing wrong redirections. While ANGIE tries to replace all such information in the database, some plugins follow a non-standard format of storing the information (base64 encoded, double escaped, encrypted etc) which makes it impossible for the data replacement step of ANGIE to touch this data. ANGIE can only replace data stored in the standard formats used by WordPress, plain text and serialized data.

Still having trouble?

Please contact us and tell us:

Please note that we may have to ask you for a copy of your backup archive or access to the restored site to identify the issue. This is handled in strict confidence in accordance to the European Union's General Data Protection Regulation. We are legally bound to NOT disclose any of that information to third parties or even use it for ourselves. Your information is held in full privacy and any information you transmitted to us (connection information, backup archives, ...) will be destroyed permanently once we finish helping you or within 30 days of not receiving any further contact from you, whichever is sooner.