Site Restoration

#34855 Problems using kickstart to move to new server

Posted in ‘Site restoration’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
CMS Type
CMS Version
Backup Tool Version
Kickstart version


I have already solved this problem but I am posting it because, I had to do steps that were not documented, it took me a week to figure it out and I am puzzled by why it did not work initially as it was supposed to.

I recently moved my site that is hosted on a CENTOS server using Cpanel to a test server using Ubuntu and Virtualmin.  The backup was uneventful and I transferred the result and Kickstarter to a directory on my new server.  I ran kickstarter which also ran as expected.  It created and placed my database as expected and setup the directories on my new server.

When I tried to run the site it did not work  So I renamed .htaccess as you recommended.  Yay, I was able to see the homepage of my site.  I was unable to go to any other page (500 errors) and was unable to login on the administrator site as the superuser.  I did not change my user name or password.  I was also unable to have Joomla mail me a new link.  I made all the suggested changes to the configuration.php file.  This did not help.  I looked at everything on my server and it all looked perfect.

I then had the brilliant idea to copy the configuration.php file from another Joomla directory (not transferred by Akeeba, but rather created by Rocketlaucher as a new Joomla site) to my site's root directory.  I of course modified the database entries, the $secret entry (even though I have no idea what that does) and the $live_site entry.  I also modified the $log_path and $tmp_path entries.  And Yay it worked.

I still was unable to use the superuser password which seemed changed to one that I did not know.  I was able to use another user to enter the site so I knew it was not a database issue.  I then had the ideas to compare in the database the encrypted password filed for the superuser on my production and development sites (which did not match) and copied the encrypted password field from my production server to the proper portion of the development joomla database.  This then fixed the authentication problem.  So now the site is working.

So why am I contacting you--I have questions so that I can avoid all this the next time I try to do this:

1) I compared the configuration.php files to see what was different other than the items that I mentioned I changed above"

        a) $captcha  recaptcha on non-working, '0' on working  (I don't think this is the problem)

        b) $editor     JCE on non-working, Rokpad on working (also probably not the problem)

        c) $force_ssl   non-working '2', working '0'   I suspect this might be a problem

        d) $ftp_port    non-working '21',  working '0'  I also doubt this is the problem

        e) $mailer      non-working 'mail' ,  working 'smtp'      also prob not problem

        f)  $sef_rewrite  non-working '1',  working '0'   unsure about this

        g) $smtpauth   non-working '0',  working '1' 

  2) These entries were in non-working file but not in working file

       a) $offset_user = 'UTC'

       b) $proxy_pass = ' ';

These are all the changes I saw, I am curious which one was the problem

Also I do not know why my super-user password was changed--I don't think I accidently typed in another password when Kickstarter was run.  I was careful.


Akeeba Staff
First, let me clarify for the umpteenth time that Kickstart only extract the backup archive. The restoration is performed by ANGIE, the restoration script included in your backup archive at the time the backup is taken.
This information is printed on you screen eery time you run Kickstart, it is included in our documentation and also spoken aloud in the video tutorials.
Saying that you have a problem with Kickstart when describing a problem with the restoration (not the archive extraction) is like saying that you have a problem with your car's ignition when you are describing a problem where you entered a wheel lock while breaking in a tight curve and got off the road. Sure, you had to turn the ignition to get moving and eventually crash but turning the ignition was unrelated to the root cause of your problem.
So I renamed .htaccess as you recommended.  Yay, I was able to see the homepage of my site.  I was unable to go to any other page (500 errors) and was unable to login on the administrator site as the superuser.  
Renaming the .htaccess file disables SEF URLs. That's why you could not go to any other page.
Please note that the Site Setup step in the restoration script (ANGIE) does offer to replace your .htaccess with the Joomla default.
 $captcha  recaptcha on non-working, '0' on working  (I don't think this is the problem)
This controls Joomla's CAPTCHA. You do not fill a CAPTCHA when growing through pages or logging into your site. Therefore it is unrelated.

        b) $editor     JCE on non-working, Rokpad on working (also probably not the problem)

This is unrelated. It is the default editor your site is using. You are nowhere close an editor when logging in.

        c) $force_ssl   non-working '2', working '0'   I suspect this might be a problem

This controls whether you site is going to be using HTTPS. The value 2 corresponds to "Entire site" meaning that your frontend and backend will be using HTTPS.

Do note that the Site Setup page in the restoration script (ANGIE) allows you to change this. You do not have to edit the configuration.php file after the fact.

Since I do not know if HTTPS was set up on your restored site prior to restoration I cannot tell you if this is related or not.

        d) $ftp_port    non-working '21',  working '0'  I also doubt this is the problem

Both values have the same effect. 0 is an invalid port so Joomla would fall back to the default FTP port, 21. However, this is only used if your site is using Joomla's FTP layer which it probably doesn't.

Also note that this can also be changed in the Site Setup page in ANGIE.

        e) $mailer      non-working 'mail' ,  working 'smtp'      also prob not problem

This controls the mail function used to send emails. 'mail' uses PHP's built-in mail() function. 'smtp' uses the configured SMTP server. Considering that you didn't find any other changes in the files to indicate an SMTP server or a different mail from address you have probably just broken Joomla's built-in mail function by telling it to use SMTP without configuring a server.

This, however, would not prevent you from logging into your site. It would simply display an error when email is attempted to be sent.

Do note that the Site Setup page in ANGIE allows you to disable mail sending if you need to reconfigure mail in the Global Configuration post-restoration.

        f)  $sef_rewrite  non-working '1',  working '0'   unsure about this

This controls whether Joomla will use SEF URLs or not.

Since you removed your .htaccess file, instead of replacing it (which is what we tell you to ultimately do; renaming is just a test to confirm that your issue is with the .htaccess and not something else) you did have to change this value to navigate to other pages of your site.

I consider this change wrong because you changed the URL structure of your site. If enabling URL rewriting in the .htaccess, something that happens even in the default .htaccess content shipped with Joomla in its htaccess.txt file (i.e. if you copied the htaccess.txt file to .htaccess), results in an error then the problem is with your server configuration. Ask your host to enable Apache's mod_rewrite in their global Apache configuration.

        g) $smtpauth   non-working '0',  working '1' 

This is related to item "e". It controls whether the SMTP server requires authentication or not. There is no production SMTP server this side of 2010 which works without authentication; it would end up being abused by spammers. This probably has no effect because you don't seem to be using an SMTP server at all. Again, this is unrelated to your issues.

  2) These entries were in non-working file but not in working file

       a) $offset_user = 'UTC'

This is just the default timezone for users who have not specified something different. Unrelated to your issues.

       b) $proxy_pass = ' ';

This is most definitely unrelated. It is only used when you have set up a proxy server with Joomla.

Based on all of the above I understand that your problem comes down to one of the following issues which could have been mitigated in the Site Setup page of the restoration script:

  • Force SSL may have been an issue if the new server had not been set up to use HTTPS with a valid certificate prior to the restoration. You could have turned it off.
  • Your .htaccess file may contain directives which are incompatible with your server. You could have replaced it with the default .htaccess content.
  • Your new server may not understand URL rewrites (if even using the default .htaccess content causes problems). This would require the Apache server to be configured properly by the host.
  • If you changed the domain name of your site you'd need to remove or change the Live Site URL in the Site Setup Page. You didn't mention it so I am not sure if $live_site is empty or not in your configuration.php file. You can change that in the Site Setup page.
  • Again, if you changed the domain name of your site OR its path you may need to change the Cookie Domain and Cookie Path in the Site Setup page. If they are empty Joomla tries to automatically detect them from the site URL reported by the server (or overridden by the Live Site URL parameter i.e. the $live_site in your configuration.php). Some servers are misconfigured and report the wrong hostname or path, in which case you not only need to change the Live Site URL but also the cookie domain and path. This can also be changed in the Site Setup page of the restoration.

All of the above are documented.

When you are restoring to a new server you have to review the Site Setup page and possibly change things there. None of these are anything that can be automatically detected or we wouldn't show you that page at all, we'd just use the settings that would work for you. Please do review the documentation and experiment with these settings on restoration to see what works on your server.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

System Task
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!

Summer vacations: Our support will be closed for replies and new tickets from August 6th to August 21st, 2022 due to summer vacations.