You have to make sure that there are no settings transferred
in files from your old server which are not compatible with your new
host. The most notable culprits are
If you have used Admin Tools' .htaccess Maker please remember that after restoring the site to a different location you will need to reconfigure and create a new .htaccess. Login to the back-end of your site, go to Components, Admin Tools, .htaccess Maker, then change the domain and directory names at the bottom of the page and finally click on Save & Create .htaccess. This is mandatory, every time you move your site to a different host, domain name, subdomain or directory.
This is a very common mistake with Joomla! 1.6/1.7 and later
versions. What you probably not remember is that you modified the
cookie setup parameters in your site's Global Configuration page.
The thing is, if you modify the cookie domain name and/or path, it's
very likely that you will no longer be able to log in to your site
if the domain name, subdomain or directory changes - exactly what
happens when you restore a site to anywhere except its original
location! Luckily, the workaround is very simple. Please edit the
configuration.php file in the root of your site
and find the lines starting with
public $cookie_path. Modify them so that they
public $cookie_domain = ''; public $cookie_path = '';
Save the file, clear your browser's cookies and cache, quit and restart your browser and try logging in to your site. You should be able to login without any problem now.
Another thing that you should be aware of is that the same problem could be caused by your .htaccess file. It's always a good idea to at least temporarily rename .htaccess to something else (e.g. htaccess.bak) when you're trying to troubleshoot a login issue. A .htaccess file may define redirections which get in the way during login.
Since Akeeba Backup 3.4.a1 you can change these parameters when restoring your site. We advise to clear (delete the contents of) these settings on most servers. In fact, if you need to set them to something other than blank (blank means "Joomla!, figure it out yourself") you would have already known what to set them to and why you need to do that.
There is one more thing which has to do with your caching and
session storage options in your site's
configuration.php file. If you are using apc,
memcache, memcached and so on it is possible that these are not
supported by your new host. Just to be on the safe side, edit your
configuration.php file and change the following
lines to read:
public $cache_handler = 'file'; public $caching = '0'; public $session_handler = 'database';
The first two lines set the cache handler to use files and disables caching which addresses blank page / 500 error when accessing your site. The latter line sets the session handler to the default (database) which addresses log in issues.
If you are restoring to a local server, please make sure that
your PHP memory limit is adequately high. On some local hosts the
default setting is 8Mb, which is too low for Joomla!. You can
determine this be editing your local server's
php.ini file. Look for this line:
memory_limit = 8M
Change it so that it reads:
memory_limit = 64M
If you are on a live host, please ask your host and make sure that your PHP memory limit is at least 32M. If it's not, ask your host for the proper way to increase it.
Look in your site's .htaccess file for directives such as
AddHandler. Try commenting them out (putting a hash
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.
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. If in doubt, get a fresh
Joomla! package, extract the
from it, rename it to
.htaccess and upload it
to your host.
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.
Another thing you should look into is the
RewriteBase line. Normally, you need something
RewriteBase / if your site is on the root of the
RewriteBase /mydirectory if it's inside a
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. If trying to use Joomla!'s stock htaccess.txt renamed to .htaccess causes an immediate blank page or Internal Server Error 500 page on your site, please consult your host. We can not help you with that. It's all up to your host.
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. You can feel free to write
an email to GoDaddy and urge them to fix this broken 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. We can't fix their
broken servers and we are as much frustrated with their service as
Sometimes you might be getting URL errors. For example, the
first page might display but clicking on any link returns a 404
error, while some other times the first page displays very weird,
like the CSS and images are not loading. Both of those issues have
nothing to do with the restoration itself, but your server setup and
a clash with how Joomla! works. The easiest way to work around it is
$live_site variable in your configuration.php
file, if you haven't already set it up in ABI's Site
Setup page. Edit the
configuration.php file in the root of your site
and modify it so that the line starting with var
$live_site looks like this:
public $live_site = "http://www.mysite.com";
or (if you have installed in a subdirectory):
public $live_site = "http://www.mysite.com/mypath";
This will let Joomla! figure out the correct URLs to your site's CSS files, images and links and these errors will go away.
If you restored to a server which required the
$live_site hack, next time do yourself a favour: use
ABI's feature for changing the
$live_site variable. It
is available in the second to last step of the restoration
procedure, just under the text boxes where you define your site's
name and email details.
Sometimes restored websites redirect to the original site even when there is no such parameter in .htaccess and $live_site is correcty set in the configuration.php. In this case, please check if you have any SEF or redirection 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. If this is not the case, read further down this page.
If none of this helps, look for a file named
php.ini inside your site's root. If it exists,
try renaming it to
php.ini.bak and retry
loading your site. Also do the same thing in your site's
As a side note, we might also add that some third party components, such as DOCman 1.4.x and VirtueMart 1.x, store absolute paths in their configuration files. If you restored to a different location / server than the one you originally had the site you backed up, trying to access your new web site's public front-end might result in blank pages or HTTP Error 500. You will have to edit the configuration of those components and ensure that you have changed the paths to reflect the correct paths on your new server / location. Special notes for VirtueMart are available in the previous page of this troubleshooter.
Some other software store the database table prefix of your site in their configuration. For instance, SQL2Excel stores the database table prefix of your site inside the SQL queries attached to each worksheet. If you changed the database table prefix when restoring the site you also have to change these SQL queries. If unsure, ask the developer of that specific software. We can't know how all 6,000+ Joomla! extensions listed on the Joomla! Extensions Directory work. We can only provide support for our own software.