Support

Hello,

some of them are available as CLI scripts, others as features of the System plugin

Others are not possible at all using the CLI (the ones you numbered 1,2,3). Could you please explain your use case? Why you feel the need for that?

The short answer: no, you do not need a CLI script for reconfiguring a transferred site and one will not be provided.

Here's the much longer answer.

While I understand the use case I am not convinced that having a CLI script would be practical for you to use or for us to document and support.

It is technically feasible to create a CLI script which would allow you to set parameters like:

php imaginary-script.php wafopt set nofesalogin 1

or something like

php imaginary-script.php htmaker add fepexdirs subfolder

What I typed above is not deliberately obfuscated. It's what you would be actually getting with a script like you asked. These are the internal parameter names of the "Forbid frontend Super Administrator login" and "Frontend directories where file type exceptions are allowed" options in WAF and .htaccess Maker respectively. They are indecipherable to you and extremely complicated for us to document. More so when we have options which internally are represented as arrays, strings, integers (with certain limits) or booleans. Even worse when you realize there are interconnected parameters. The potential for breaking your site with a script like that is more than real, it's a near certainty.

Now let me explain why you don't need a CLI script.

If you are making changes to the WAF configuration on your dev site they are transferred and applied to the live site by restoring the #__admintools_storage table. If, quite to the contrary, you DO NOT want any changes you made to the WAF configuration to survive the site transfer then quite simply don't include the #__admintools_strage table when transferring the site.

Regarding the .htaccess, you could have the configuration ready when transferring the site and just click on the Save and Create .htaccess button. That's something that can be automated with Selenium or a similar tool.

But that's complicated. A simpler thing to do is set up the .htaccess Maker before the site transfer and generate the .htaccess. Your dev site will break BUT you have the .htaccess that you need on the live site. This can be transferred with the site itself or, if you are using Akeeba Backup, rename it to htaccess.bak, do not include a .htaccess in the backup archive and you can rest assured that this file will be renamed to .htaccess at the end of the (manual or automatic) restoration.

File permissions: you SHOULD NOT use Admin Tools after the site transfer to enforce permissions! By definition, your site transfer process transfers files. This is where the correct ownership and permissions need to be applied. If you are getting the wrong permissions to begin with you are doing the site transfer wrong or, at least, in a very suboptimal manner.

Same with the temporary directory and logs directory. If you expect to use Admin Tools after the transfer to fix glaring configuration.php issues you are doing the site transfer wrong. FWIW Akeeba Backup handles that automatically and it can be automated in the Pro version using Akeeba UNiTE.

As you understand, there really is no need for a CLI control script just for transferring sites. Admin Tools and Akeeba Backup are designed to work together. With a minimum of planning you can transfer your sites automatically without having to click anything. Take that from the guy who is restoring a backup of the akeebabackup.com live site on a dev server every day, unattended, without either the live or dev site requiring manual reconfiguration :)

But this means thanks to Akeeba Backup, I will be able to schedule an automatic rename of .htaccess.bak file from DEV website to .htaccess file on PROD website?

It does that automatically, no configuration necessary. However, the file name is htaccess.bak (without a dot in front).

You must also NOT include the .htaccess file in the backup.

Here's how it works. During archive extraction, Kickstart will extract .htaccess (if it exists) renamed to htaccess.bak. At the end of the restoration if a htaccess.bak exists it will be renamed back to .htaccess to "undo" this change. These two events are independent. Therefore if there is no .htaccess file in the backup archive BUT there is a htaccess.bak then we know for sure that htaccess.bak will be renamed to .htaccess at the end of the restoration. Ta-da! What we wanted :)

Of so what is the goal of admin tools permission tool?

Some FTP servers have a default umask (permissions mask) for uploaded files which causes the files to be uploaded to have the wrong permissions, either too wide (e.g. 0755) or too narrow (e.g. 0600 -- that's the most typical case). This can either be a security issue or simply not allow you to access these files over the web e.g. making images impossible to display. Normally you'd have to trawl your site to find which files have screwed up permissions and fix them manually. Admin Tools does that for you.

Furthermore, some configuration files need not have any permissions but read access for their owner (0400). However, every time you modify them (manually or through a web interface) you may get the wrong permissions, e.g. 0644. You can configure these permissions per file or folder in Admin Tools and apply them en masse, without thinking about it.

What can do Akeeba UNiTE exactly?

When you say : it can be automated ?

Akeeba UNiTE is an unattended site restoration script. You give it a configuration file and a backup archive and it performs the entire restoration without human interaction. At the end of the process you can also have it extract additional ZIP file(s) and / or restore additional SQL file(s). ZIP files can be used to deploy files which are not in the backup archive. SQL files can be used to apply database changes which are not in the backup. In your use case you could use a ZIP file to deploy the customized .htaccess and the SQL files to deploy customized Admin Tools configuration settings.

If you want, you can give it only a configuration file with information to take a backup of a site remotely (using the Akeeba Backup JSON API), download the backup archive from the remote server and restore it on the target server — WITHOUT any human interaction whatsoever.

Combining all these features you can end up with a solution that has unite.phar (the executable file of Akeeba UNiTE), a unite XML configuration file, a ZIP file with the custom .htaccess and a SQL file with the custom Admin Tools settings. Put all of that in an off-side directory of the target site and launch UNiTE with a CRON job. Sit back while your site is being automatically transferred from your (accessible over the Internet) dev server to your live server. The same can be done of course to clone your live site to a dev server when you want to start working on it again.

FYI I am using UNiTE to restore a backup of our live site to my dev server. Using the features I pointed out I can automatically wipe it clean of personally identifiable information (so my local copy is GDPR compliant), create a custom .htaccess (there are things in our live site's .htaccess which wouldn't work on my dev server) and even deploy a customized configuration.php file which redirects all mail to a Docker image that runs a development catch-all mail server so that the dev site's email doesn't get sent over the Internet and I can review what was sent.

As I've been saying for the last 14 years, Akeeba Backup doesn't make site backup and site transfers possible, it makes it easier as a whole and particularly easier to automate. That's why I started writing its predecessor, JoomlaPack, all those years ago. I was building sites and I was fed up with the manual site transfer method. I wanted to automate things. That's why I got into computers at the age of 11. I wanted to have a machine do things for me instead of the other way around ;)

UNiTE can only be used with backup archives created with Akeeba Backup. It actually uses the backup restoration script included in the archive to restore your site. Flat backups like yours lack not only the code for restoration but also the necessary information and structure to restore them reliably on any server.