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
directives. This page details our experience with these issues, why
they happen and how to deal with them.
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 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 core WordPress section i.e. the stuff that's between
# BEGIN WordPress and
RewriteBase commands anywhere in the file
the .htaccess commands required for multisite operation as long as you copied verbatim the content WordPress suggested when setting up the multisite
The rest of the .htaccess rules can be edited automatically in a mostly reliable manner if you are transferring a WordPress site:
from the domain's / subdomain's root to the same or different domain's / subdomain's root e.g. from http://www.example.com to http://foobar.example.net
from a subdirectory to a subdirectory (with the same or a different name, in the same or different domain/subdomain) e.g. from http://www.example.com/foo to http://example.net/bar
from a subdirectory to the same or different domain's / subdomain's root e.g. from http://www.example.com/foo to http://bar.example.org
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
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 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.
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.
Look in your site's .htaccess file for directives such as
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.
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
www.example.com, even if it referenced
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.
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.
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
Other local servers, like XAMPP, also come with the
mod_rewrite Apache module disabled. These servers require you to
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.
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
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.
Please contact us and tell us:
The URL of the site you backed up.
The URL of the site you are restoring to.
The version of ANGIE, printed at the top of the restoration page.
The PHP version of the site you are restoring to (printed towards the bottom of the first page of the restoration script).
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.