Support

Hi!

As we mention in the documentation, the .ini files are translation files, whereas kickstart.php is the executable code. Just place kickstart.php and the INI file for the language of your choice in the same directory. The first character of each INI file specify the language in the same way Joomla! language files work. Since en-GB stands for "English, Great Britain", en-GB.kickstart.ini is the British English translation file.

You can extract your archive wherever you want. Just note that the archive file will be extracted in the same directory as kickstart.php. As noted in our documentation, place kickstart.php, the translation INI files and your backup archive inside the directory you want the archive to be extracted.

Yes, you need to create a database beforehand. Kickstart is an archive extraction script and has nothing to do with the database. The Akeeba Backup Installer script (which is inside the backup archive and extracted when you extract the archive) handles the database restoration, but creating the database is your responsibility. Just think about it. It's very likely that your database user doesn't have adequate privileges to create a new database. How would Akeeba Backup Installer create a new database if the user it uses to connect doesn't have enough privileges to do so?

Regarding 3: WARNING! DANGER AHEAD! If you just want to create a copy of the site, never, ever use the same database connection information as the original site! If you do that, you will end up with entangled sites. Please read this troubleshooter page first: https://www.akeebabackup.com/documentation/troubleshooter/prentangled.html

As I implied, it's an extremely good idea to first read the documentation (at least the Quick Start Guide) before trying to restore a site. Remember that site restoration is a potentailly dangerous operation which overwrites files and replaces database contents. Unless you have read the documentation and are pretty sure of what you're doing, you could easily kill a live site and have to ultimately restore it from the last known good backup. It's generally safer to experiment on a local testing server first.

You read that correctly. Due to technical reasons, Apache (the web server software running on your host's server machine) may not be able to properly process requests until you have a domain name assigned to your account. I've checked with hosting engineers in case we could come up with a solution, but our mutual conclusion was that it's not something we can fix - it's just the way Apache works.

Do note that, in those case, even if you would manually restore your site, it wouldn't work properly for the same reasons. You'd have huge problems with SEF URLs and most forms, including login forms (therefore you'd simply have an unusable site).

The workaround I have found is a really dumb one. I have registered a few "scrap" domains, i.e. domain names that I am not using for live sites and have them only for testing purposes. You can assign one of those scrap domain names to your account, wait for 3-72 hours for the DNS change to come in effect (sometimes it only takes 10 minutes!), perform the restoration and -when you're ready- assign the final domain name to your site. Works every time for me :)

You're welcome!

You're welcome!