 |
This page allows you to partially reconfigure your site. Changes will only be necessary when you are restoring to a new server, subdirectory, subdomain, or domain. If you are restoring into the same location you backed up from just click on Next.
The default values you see on this page are read from your configuration.php file, and the site's database.
Site Parameters
- Site name
The name of your site, as used by Joomla and your current template.
- Site e-mail address
The e-mail address your site's e-mails are sent from.
- Site e-mail sender name
The sender name for the e-mails your site is sending.
Tip
Using a sender name containing the word “duck” is strongly inadvisable due to the potential transposition of the treacherously proximate keys D and F on the standard QWERTY layout, and the unfortunate fact that said transposition results in a distinctly non-anatine, and rather vulgar noun. The words “tuck”, “ruck”, and their derivative adjectives are also strongly discouraged due to a similar scatological potential.
- Generate a new secret
Each Joomla installation has a secret key stored in
configuration.phpwhich controls the name of the site's session / login cookie, the form anti-CSRF token generation, and the encryption of core and third party data in the site's database.When making a clone of a site into a different server, subdomain, domain, or subdirectory it's generally advised to generate a new secret. This prevents authentication bypass by users who know the secret of the old site, and can log into the old site as a privileged user (they could reuse a login cookie on the new site to impersonate the same user account on the new site). In these restoration cases, this option is enabled by default.
Note
BRS will automatically re-encrypt Joomla's Multi-factor Authentication configuration with the newly generated secret. It cannot, however, do that for third party extensions' data.
Important
If you know you have encrypted third party data you may want to disable generating a new secret even if you are creating a clone of the site into a different server, subdomain, domain, or subdirectory.
When restoring into the exact same site that was backed up it's generally advised to NOT generate a new secret, as it would invalidate encrypted data in the database. In this restoration case, this option is disabled by default.
- Live site URL
This is an optional configuration parameter, which should be left blank on the vast majority of sites.
If your site doesn't seem to work properly – e.g. missing pictures, all links resulting in 404 errors, etc – you may want to fill in your site's URL, for example
http://www.example.com(include thehttp://part, but not a trailing slash orindex.php!).http:// vs https:// matters. If you are going to use your site over HTTPS (recommended!), or over both HTTP and HTTPS, your Live site URL must be EITHER blank OR start with https://. A Live site URL starting with http:// will cause your site to appear broken.
Subdomains matter. www.example.com is NOT the same example.com. If you cannot leave the Live site URL blank, use the fully qualified domain name which will be used by your site in your Live site URL
Important
Virtually every “my restored site is broken / I can see no images / the CSS has disappeared” issue we've seen ever since our backup software was created in 2006 has been solved by telling the user to redo the restoration, but blank out the Live site URL on this page.
- Force SSL
This badly named option –we keep Joomla's incorrect terminology in its Global Configuration– controls what happens to your site in relation to HTTPS. There are three options:
None. If your site is accessed over plain http:// it will remain over plain http://.Administrator only. Accessing your site'sadministratorover http:// will result in a redirection to https://. Accessing the public area of your site –including the API application– over http:// will NOT redirect to https://.Entire site. Accessing any part of your site over http:// will result in a redirection to https://. STRONGLY RECOMMENDED.
Please note that server configuration –including server configuration files such as
.htaccess,web.config, andnginx.conf– as well as first and third party extensions also have a say on that. It is possible that you use None or Administrator Only but your entire site is served over HTTPS because of a redirection in the .htaccess file, the HSTS header, or a third party plugin enforcing the redirection. Remember, BRS only sets the corresponding Joomla option in Joomla'sconfiguration.phpfile; it does not control the outcome of that option, or what happens on your site!Note
The None option is incredibly bad for security on a live site. Your login cookies can be stolen and spoofed, leading to a site takeover. It's only meant to be used on localhost.
The Administrator Only option is a major pitfall. It effectively offers the same non-protection as the None option since Super Users can still log into the site's frontend (where no protection exists!), something which happens automatically when Joomla's Shared Sessions option is enabled. In fact, we'd call this option misleadingly dangerous because it may make you think you are protected as a backend, privileged user when you are actually not.
Only the Entire Site option is safe for live sites, as long as you have a valid TLS (HTTPS) certificate installed. On most hosts it's absolutely free, thanks to Let's Encrypt.
- Cookie domain
For most sites this should be left blank; Joomla can work it out automatically. If you have a server which does not communicate the correct domain name for your site when setting cookies you can use this setting to specify the domain name for the session cookie. Including a period (.) in front of the domain (i.e.
.example.com) will allow the cookie to be set across all subdomains of the specified domain name. Please note that using the wrong domain name in this setting will make it impossible to log into your site.- Cookie path
For most sites this should be left blank; Joomla can work it out automatically. If you have a server which does not communicate the correct URL path for your site's root when setting cookies you can use this setting to specify the URL path to your site's root for use with the session cookie. Please note that using the wrong oath in this setting will make it impossible to log into your site.
- Robots (Search Engine)
This setting controls whether your restored site should be indexed by search engines. You have the following options:
No change. Keeps the Robots settings already present in the backed up site's
configuration.phpfile. Default setting. Recommended if you do not understand what the other options do.Index, and follow links. Ask search engines to fully index your site, following any links to inner or external pages. Recommended for most production sites, especially when you move a site from a development / staging server to a production server.
Index, but don't follow links. Ask search engines to index the pages on your site they know about, but not follow any links to inner or external pages.
Do not index, do not follow links. Ask search engines not to index your site at all. Recommended for development sites.
Note
Joomla's Robots option is merely a recommendation to search engines. Most search engines and crawlers follow the recommendation. Some crawlers, however, blatantly ignore it, e.g. some crawlers from “AI” companies. You may want to use a third party service, such as CloudFlare, to block these misbehaving crawlers.
- Turn on mail sending
Should Joomla be allowed to send email? It is recommended that you turn this off when restoring a copy of a production site to a development or staging server, thus avoiding the potential problem of having a development / staging site inadvertently send live emails to real clients.
- Reset session options
Check this box to reset Joomla's session management options to their default settings. This is recommended when you are restoring your site to a different server or user account than the one it was backed up from.
- Reset caching options
Check this box to reset Joomla's cache management options to their default settings. This is recommended when you are restoring your site to a different server or user account than the one it was backed up from.
- Override tmp, log and cache paths
Click this button to populate the fields in the Directories fine-tuning area with the default paths used by Joomla. This is recommended whenever you are restoring your site to a new subdirectory, subdomain, domain, or server.
Super User Settings
You can select exactly one Super User to modify. You can change the user's email and password, but not their username. If you do not wish to use this feature select the “—” entry.
You may want to use this feature when you are restoring a backup taken by another person, on a site you do not normally have Super User access to. You need to somehow be able to log into the restored site as a Super User. Pick an existing Super User, and change their password. You will be able to log into the site using the username of the administrator you modified, and the new password you selected.
Tip
This comes in very handy when you want to understand how the site works when you've sold a support contract to new client. You don't know how the site works, and you don't want to learn in production. Take a backup with Akeeba Backup, restore it on a development server, and dissect the site without worrying about breaking it.
Server-specific configuration files
When moving a site between hosts, servers, domains, subdomains, or directories it is possible that the contents of certain server-specific configuration files might cause errors with the restored site. BRS allows you to take preemptive action to prevent such issues from occurring.
Important
Not all options may be visible, or enabled. Which options you see and / or are enabled depend on whether the corresponding configuration files exist, and their contents.
If you see a disabled option you can safely ignore it. It does not apply to your site. Instead of misleading you by letting you set an option which does nothing on your site, we simply display it as disabled.
If an option is completely missing it also means that it does not apply to your site. Don't be alarmed by its absence.
The .htaccess Handling drop-down appears if BRS detects that your .htaccess file in your site's root has AddHandler or SetHandler lines. These lines tell your server which PHP version to use. Their presence means that you are probably not using your server's default PHP version, therefore BRS needs to transcribe them into your site's .htaccess files. When you read “.htaccess” below you should understand “.htaccess and / or htaccess.bak”.
Note
If no such lines are detected, or you are restoring on a server which does not support .htaccess files (e.g. Microsoft IIS, NginX, …) the drop-down does not appear at all.
As a result, the option you select here will modify your site's main .htaccess file, stored in your site's root. Please note that if you have a file named htaccess.bak the options here apply to that file as well. The reason is that upon clicking on at the end of the restoration this file will be renamed to .htaccess.
- None
Leaves the
.htaccessfile as-is.- Use default
Replaces the
.htaccessfile with the default file contents provided by Joomla, renaming your existing file tohtaccess.bak. BRS will try to download the latest version of this file from Joomla's GitHub repository. If this is not possible, it will fall back to a copy of the file included with BRS.- Remove PHP handler lines
Remove the
AddHandler/SetHandlerlines from the file.You may want to do that if you are transferring the file across different hosts, or even different servers within the same host.
The reason is that the the
AddHandler/SetHandlerlines which select which PHP version you were going to be using on your site are specific to the configuration of the server. Different servers may have different configurations. Leaving the wrongAddHandler/SetHandlerlines from a previous / different server will cause an error in the new server.Do note that if you select this option and after clicking you might get an error, or you may find that the button at the end of the restoration no longer works. If this is the case please log into your hosting control panel and select a newer version of PHP.
- Replace PHP handler lines
This is the recommended option. BRS will transcribe the
AddHandler/SetHandlerlines from your current.htaccessto the final.htaccessfile of your restored site.The typical use of this feature is that you start by going to your hosting control panel and select a newer PHP version before extracting your backup. What happens in most cases is that your host modifies your
.htaccessfile with anAddHandlerorSetHandlerline which tells the server to use a newer PHP version.When you extract your backup, your original site's
.htaccessfile will be extractedhtaccess.bak. This is on purpose. The.htaccessfile from your backup may contain differentAddHandler/SetHandlerlines which do not work with your current server, or no such lines which would make your new server use its default version of PHP, one which might not be compatible with the restoration script and/or the backed up site. By renaming the extracted file this issue is sidestepped.This leaves us with the problem that once the backup is complete, the htaccess.bak file would be renamed back to .htaccess, therefore the problem with invalid lines causing a server error, or the wrong PHP version being used preventing you from accessing your site would remain. By enabling this option here you are telling BRS to transcribe the known-good
AddHandler/SetHandlerlines into the htaccess.bak file. Therefore, when it's renamed back to .htaccess at the end of the restoration clean-up your site will be running under the correct PHP version.It is a bit confusing, but that's how server works. What you need to keep in mind is this:
Select the correct PHP version on your site before extracting your backup archive.
Extract the backup archive and run the restoration.
If you see the .htaccess Handling option, select Replace PHP handler lines. It is the default, anyway, so you don't have to think much about it!
- Replace main web.config file with default
Only appears on sites hosted on Microsoft IIS. Replaces the content of the
web.configfile on your site's root with the content of the stockweb.config.txtthat ships with Joomla. The old file is renamed toweb.config.bak. BRS will try to download the latest version of this file from Joomla's GitHub repository. If this is not possible, it will fall back to a copy of the file included with BRS.
The Remove .user.ini and / or php.ini files from the main site directories option appears if there is a .user.ini or a php.ini file in your site's root and/or your administrator directory. These files are used to modify PHP configuration parameters. When transferring your site between different hosts, or even different servers on the same hot they are likely to cause problems, preventing you from accessing your site. Enabling this option will remove these files, fixing the problem.
The Delete the .htaccess and .htpasswd files in the administrator directory option is always shown on servers which support .htaccess files (Apache, LiteSpeed), and is available to be selected if BRS detects that your administrator directory has a .htaccess and/or .htpasswd file, commonly used to implement password protection of the administrator directory. Enabling this option will remove these files. You need to do that if you are transferring your site between hosts, servers within the same host, subdomains, domains, or directories. This is for two reasons. First problem is that the .htaccess file in the administrator folder contains an absolute filesystem path to the .htpasswd file which is different on each server, subdomain, domain, or directory. Second, .htpasswd files may require different formats on each server. Removing the administrator password protection is the best approach to ensure you can log into your site's administrator after restoration. You can use your hosting control panel or third party software, such as Admin Tools, to reapply administrator login password protection on your restored site.
Directories fine-tuning
- Site Root
Shows you the absolute filesystem path to the site's root directory. Helps you construct the directories you need to enter below.
Tip
You can always use the button to automatically populate the Temporary and Log directory using the Site Root.
- Temporary directory
The absolute filesystem path where Joomla will store its temporary files. Temporary files are supposed to go away at any time, usually by the time Joomla returns the request results back to the web server. It must NOT be the site's root, or any other directory where permanent files are supposed to be stored (such as the
components,mediaetc directories). The recommended Joomla setting is your Site Root plus/tmp.- Log directory
The absolute filesystem path where Joomla will store its log files. It must NOT be the site's root, or any other directory where permanent files are supposed to be stored (such as the
components,mediaetc directories). The recommended Joomla setting is your Site Root plus/administrator/logs.- Cache directory
Joomla! 5.1.0 or later only. The absolute filesystem path where Joomla will store its cache files. Cache files are very similar to temporary files, but they may remain on the server longer than the end of serving the request. The recommended setting is leaving it blank; this will make Joomla use the cache directories defined in its
defines.phpfiles, by defaultcacheunder your site's root for the frontend andadministrator/cachefor the site's backend. It only makes sense to enter a custom directory path here if you plan on using a directory outside the web root of your server.Important
Since Joomla! 1.5.0 (which was released back in 2007) the cache directory is meant to be customisable and its contents NOT accessible over the web. However, some badly written extensions wrongly assume that it's web accessible, and that it's always the directory
cacheunder your site's root. If you use a custom cache directory, especially one outside your site's root, your site may not work properly. Do not contact us about it; contact the developers of the misbehaving extensions and let them know that their software is using Joomla wrong, as per the security recommendations Joomla has made for the better part of the last two decades.Note
Joomla will always store some files in the
administrator/cachedirectory, e.g. theautoload_psr4.phpwhich tells it how to load core and third party extensions installed on your site. As a result, you must never attempt to remove that directory altogether; your site will break.
FTP Layer Options
This area only appears on Joomla! 1.6, 1.7, 2.5, and 3.x sites. The FTP layer was deprecated in Joomla! 3.7 and removed in Joomla! 4.0. It is strongly recommended NOT to enable the FTP layer for security reasons.
The Enable the FTP layer option will activate Joomla!'s FTP layer, which forces the Joomla! core and several conforming extensions to write to your site's files using FTP instead of direct file access through PHP. This is designed to work around permissions issues with a minotiry of badly configured servers.
If you enabled the FTP layer, you need to fill in the rest of its settings:
- Host name
Use the domain name to access your site's FTP server
- Port
Leave the default value (21) unless your host tells you otherwise. Do note that Joomla! only supports plain FTP. If your host tells you to use port 22 – which is used only by SFTP – it won't work.
- Username and password
The username and password to connect to your site's FTP server
- Directory
The absolute FTP path to your site's root. The easiest way to find it is using FileZilla to connect to your site and navigate to your site's root, which is usually a directory named
htdocs,httpdocs,http_docs,public_htmlorwww. Look at the right hand pane, above the folder tree (Remote site text box). Copy it and paste it in the Directory box.
Movingn forward
Finally, click on the button to let BRS write your site's new configuration.php file and display the final page.