Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.
IMPORTANT CAVEAT:One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!
Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.
1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host.
2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host.
3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.
1. Check to be sure your site is configured to use .htaccess files.
- Make a backup of the .htaccess file in your root public_http directory. If you don’t have a .htaccess file at this location, create one now.
There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.
AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php
Delete the backup .htaccess file. Don’t leave backups of .htaccess files in public directories.
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
.htaccess and local
If your site was using Admin Tools’ .htaccess Maker
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.
I can’t log in to my site after I restored it to a new location
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_domain and
public $cookie_path. Modify them so that they read:
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.|
I cannot log in or my site crashes with a blank page / Internal Server Error 500 page as soon as I try accessing it
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.
PHP memory 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
htaccess.txt file from it, rename it to
.htaccess and upload it to your host.
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.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.
RewriteBase in .htaccess
Another thing you should look into is the
RewriteBase line. Normally, you need something
RewriteBase / if your site is on the root of the domain, or
RewriteBase /mydirectory if it’s inside a directory named
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
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. 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.
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. 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 you are.
The $live_site variable in configuration.php
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 using the
$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.
Redirection and SEF components and plugins
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 includCommon issues on restored sites and how to solve theme the domain name) causing wrong redirections. If this is not the case, read further down this page.
Problems with php.ini
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 administrator directory.
Third party components with absolute paths / URLs
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.