Support

Kickstart most definitely does not have a default dbprefix (or any dbprefix at all) since it only extracts backup archive files. It does not restore them. You are probably mistaking Kickstart – the archive extraction script – with ANGIE. ANGIE is the restoration script which is included in the backup archive.

ANGIE is interactive. UNiTE is non-interactive; The "UN" in its name stands for UNattanded.

An interactive application like ANGIE can present you with defaults because you can override them before proceeding with the restoration.

A non-interactive, unattended application cannot do that by definition. It needs to be explicitly given all of the parameters it will be using for restoration which, at a minimum, are the location of the archive file, the absolute path to the site's root and the database connection information (hostname, database name, username, password, table name prefix).

As for your question, dbprefix is already documented to be a mandatory configuration parameter:

If AND ONLY if you are restoring an extra database, NOT the main database of your site, which already didn't have a prefix attached to it during backup, you can leave the value blank, that is the tag should read <dbprefix />



Warning

YOU MUST NEVER LEAVE THIS BLANK FOR THE MAIN DATABASE OF A JOOMLA! OR WORDPRESS SITE! Using a blank prefix WILL lead to a restoration FAILURE as neither Joomla! nor WordPress are designed to work with an empty database prefix.

The information you are looking for is stored in the installation/sql/databases.json. However, you don't have that file until you extract the backup archive... which means that UNiTE has already read its configuration and is currently running.

Obviously time travel is not a solution :)

The next best thing is creating backup archive in ZIP format. Since you know the name of the JSON file you can use unzip on the command line to extract just this file. Or you could use JPA / JPS archives and Kickstart command-line (something like: php kickstart.php your_file.jpa --extract=installation/sql/databases.json)

You could then use something like JSON.awk to extract the prefix, pass it through sed and update your XML file, then run UNiTE.

As with all things command-line there are several ways to skin a cat.

No, this will not be implemented. There are some very good architectural reasons for that.

UNiTE's configuration needs to be immutable. If we start trading it as mutable we risk introducing bugs.

Even if we accept this risk (which we don't, but for the sake of argument let's say we were unscrupulous and did), Akeeba Backup allows you to exclude the database settings from the backup archive. In this case the databases.json file contains empty values. We wouldn't know until it's too late: the archive is extracted, people can't access your site and UNiTE reports an error that's hard to debug because the validation passed even though the database connection information is empty.

Furthermore, allowing the validation to pass with empty / delegated configuration values opens up the possibility of a genuine mistake in UNiTE's configuration. Think about someone blithely restoring a backup archive on a different hosting account on the same server, without realizing that they are now overwriting the main site's database. I know you think that's unlikely but 13 years of tech support tell me that until I introduced the aforementioned check and had ANGIE explicitly blank out the db connection information if the domain name and path in the URL doesn't match exactly the ones the backup was taken from we had half a dozen people a month with that issue. It's not just the increase in our support load, it's the fact that each and every of these cases represents a broken live site and one person losing trust in our software.

Furthermore, UNiTE hands over the restoration process to ANGIE itself. We construct ANGIE's configuration state from the UNiTE configuration and simply call ANGIE's models to run the restoration. The Models, as they should in an MVC world, are oblivious to the source of the method call. They will dutifully carry out their task based on the provided configuration state. If we removed ANGIE's checks for empty / delegated database connection information we'd re-introduce the problem we solved or, worse, would allow ANGIE to use the default MySQL connection defined in php.ini with an empty database prefix. The resulting site cannot be backed up and it's basically trashed. That's one big honkin' bug!

Finally, your use case is extremely rare. You are talking about restoring a site with the same prefix as the site you backed up without knowing what you backed up. Frankly, that's not what UNiTE is designed to do. It's designed to automate site restoration when you know WHAT you are restoring and WHERE you are restoring it to. But even if you do want to abuse it like that I told you how you can automate it. Just make sure that you do cover for the case that databases.json does not include a prefix so you can apply a default one (e.g. "res_").

Based on the rarity of your use case, the problems implementing a solution for it would introduce to the overwhelming majority of our clients and the availability of alternative automation options outlined previously I can tell you in no uncertain terms that your feature request will not be implemented.

As a side note, we are currently working on a new major version of UNiTE. The direction we are moving towards is removing all features which can be reproduced with standard command line tools. For example, sending emails after the restoration is complete or fails had a reason for existence in 2009 when UNiTE was born but are completely irrelevant in 2020; the standard output of UNiTE can be redirected to a mail script or automatically mailed to you by the CRON daemon, depending on how you launch it. Considering that your use case can be automated with standard command line tools there's a further reason for us not to implement your feature request on the principle that it moves against the direction we are taking UNiTE. Monolithic tools are not the way to go. They are restrictive. The direction we need to move is nimble tools which are conducive to automation, i.e. the UNIX way.

You're welcome!