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!