Support

ANGIE reads the configuration variables from configuration.php and changes a select few which need to be changed upon restoration. Without a configuration.php file it does not know which variables are present in your Joomla version.

Do not exclude configuration.php. Instead, select your backup profile, go to its Configuration page, find the Database Backup Engine area, and set the Blank out username / password to Yes.

Please note that the ticket you are reading has a date of June 2017. That's almost six years ago. Back in June 2017 there was no Joomla 4 as we know it. Well, there was Alpha 1 which was just Joomla 3.7 plus some namespaces stuff. It wouldn't be until late 2019 when the Joomla project decided to discontinue the configuration.php-dist file which acted as a reference of what are the expected global configuration variables, and add a lot of options to the Global Configuration page. Six years ago when the configuration.php-dist file still existed we still shipped a copy of that file with ANGIE (we still do, it's the j30.php file if you're wondering), and ANGIE was able to create configuration.php files from scratch if none was provided. This is something we had been doing since the Joomla 1.5 days (that's why you see j15.php for Joomla 1.5 and j25.php for Joomla 1.6/1.7/2.5 in the same ANGIE subdirectory).

While I have worked for a workaround for the missing file in Joomla 4 (and do ship it as j40.php) I consider it a bit finicky, as it is based on the configuration.php file created from a default Joomla 4 installation, not a reference file — since the reference file no longer exists. That's why it had not been activated in ANGIE just yet. I wanted to first see if there is a need for it or if I should remove it altogether. It turns out that your is the first ticket in the one and a half year since Joomla 4's release with this issue, making it extremely uncommon to say the least. Now that I see that someone did bump into that problem I know it's not a completely useless feature and will enable it — in the next version of Akeeba Backup scheduled for late February or early March.

In the meantime, here is what you can do.

Option A. After extracting the backup archive edit the file installation/platform/models/jconfig/j40.php and change:

class JConfig

with

class J40Config

This will allow the restoration script to create a (mostly) valid configuration.php file from scratch. This is the change I will be making (plus a few updates to the j40.php file for options which were recently added to Joomla 4) in the next version of Akeeba Backup.

Option B. After extracting the backup archive upload an edited configuration.php file to the site's root. Then click on the Run the Installer button on Kickstart. ANGIE will now read the edited / redacted configuration.php file and everything will work just fine.

Another idea could be to enable an Akeeba Backup user to provide his own "prototype" of a `configuration.php` that will be backed up instead of the original file. That way a user could define best practice values for his own needs without changing the values in the developmental area. But that's just an idea. I also understand that it isn't the natural idea of Akeeba Backup to provide clean "demo packages" for other users.

The best practice for distributing a site is to either take a backup from a server which is not connected to the Internet (e.g. a local server), or dispose of the site after handing over the backup.

If you have a live site you want to distribute, use a local server as an intermediate restoration target. I mean: backup the live site, restore on the local server, make any changes you may need, back up on the local server, send this new backup to your recipient.

Another option is to not back up the configuration.php file and deliver a "sample" one with your site's backup.

A third option is to back up into a ZIP file, excluding the configuration.php file, then add your "sample" configuration.php file into the ZIP file using standard tools. Remember, Kickstart works just fine with ZIP files as long as you use the standard and default Deflate compression algorithm (don't use LZMA, PPMd, or whatever else your archiver supports).

Regarding your suggestion, it's something I had thought of well over a decade ago. I really don't want to add a feature which practically allows replacing files at backup time. I can see the valid use cases, but I can also see some cases of abuse. I'd rather avoid that.