Support

It looks like you have a mix of files from different versions. Try installing Akeeba Backup twice in a row, without uninstalling it before or in between.

The thing is, the error message does not make sense unless you have a mixed set of files. Namely, I expect that the plugins/console/akeebabackup/services/provider.php file is updated, but the plugins/console/akeebabackup/src/Extension/AkeebaBackup.php file is not. This is one of two ways PHP can be throwing this error.

Please open the file plugins/console/akeebabackup/src/Extension/AkeebaBackup.php and check line 40. It should read exactly this:

public function setCLICommandFactory(CommandFactoryInterface $factory)

Moreover, please open the file plugins/console/akeebabackup/services/provider.php and check lines 48 to 55. They should read exactly this:

$plugin = version_compare(JVERSION, '5.4.0', 'ge')
    ? new AkeebaBackup($config)
    : new AkeebaBackup(
       $subject, $config
    );

$plugin->setApplication(Factory::getApplication());
$plugin->setCLICommandFactory($container->get(CommandFactoryInterface::class));

If either file's lines are different it means that the plugin –which is part of the installation package– has not been updated properly. Delete the folder plugins/console/akeebabackup and install Akeeba Backup twice in a row, without uninstalling it before or in between. Then check the files again; their contents should be as I described above.

The other reason PHP might be freaking out is if your host has set up PHP's OPcache code cache in a way which does not allow Joomla to reset it when updating an extension. If the files are correct as per the information I gave you above but you still have the exact same problem you stated (the error message MUST be “Attempted to call an undefined method named "setCLICommandFactory" of class "Akeeba\Plugin\Console\AkeebaBackup\Extension\AkeebaBackup".”) then contact your host and ask them to reset OPcache.

To clarify, OPcache can be configured in such a way that your server "remembers" the contents of .php files without reading them again from the storage. This makes your site faster, since PHP does not have to read and parse each .php file being used every time someone accesses a page on your site, or every time you run a CLI script. However, this also means that if the .php files chance, PHP won't know about it (always depending on server configuration!). This is a problem when updating Joomla and extensions; the new code is there, but your server is unaware. At best, you get an immediate error like you have here, alerting you to the problem. At worst, your server still runs an older version of the software with unknown security and stability consequences. Joomla DOES try to tell your server to reset the OPcache for each file it installs during an update BUT it's possible that a bug in Joomla or a configuration setting in your server prevent that from taking effect. That's why I am saying that you may have to ask your host to reset the OPcache.

There is really nothing else. If the files are correct, the method the error message claims does not exist actually does exist – it's in  the file plugins/console/akeebabackup/src/Extension/AkeebaBackup.php on lines 40 to 43. If PHP does not see the code that you can read with your own two eyes then it's an op-code cache which has cached the old contents of the file  in memory and hasn't looked at the updated files since.

OPcache is the only op-code cache available for your PHP version, that's why I told you that you need to reset OPcache. In the server where this took place, Akeeba Backup works fine exactly because the cached old code was expunged from memory, forcing OPcache to reload it.

Two more bits of information for completeness' sake.

In the past, another two op-code caches existed: APC and WinCache. The APC cache stopped being compatible with PHP back in PHP 5.5 release in June 2013. WinCache stopped being compatible with PHP back in PHP 7.2 released in November 2017. Therefore, the only op-code cache since PHP 7.2 has been OPcache which is bundled with PHP itself.

OPcache can be configured in many different ways. What makes the most difference is a. how long the compiled PHP source code (op-code) is cached for and b. whether PHP scripts can request that the OPcache for a specific file is cleared.

How long op-code is cached for is determined mainly –though not solely– by the configuration options opcache.validate_timestamps and opcache.revalidate_freq. If the former is disabled and/or the latter is set too high, PHP will NOT "see" updated .php files. It will instead run the already cached compiled version of the files predating the update of Joomla and/or its extensions. I believe that this is what your host is doing, causing the problem you are experiencing. Another problem you are experiencing but have not observed is that you update Joomla and its extensions, but the old code (with known security issues!) is still running on your site despite the fact that you can see the updated files on your server's storage. This kind of configuration makes sense for bespoke servers which are restarted or created afresh as part if a CI/CD pipeline, but it's completely inappropriate for a commercial, generic host.

Whether PHP scripts, like Joomla itself, can request that the OPcache for a specific file is cleared is determined by the opcache.restrict_api configuration option. Access to the opcache_invalidate function may also be disabled by the host using PHP's disable_functions configuration option. When Joomla cannot use opcache_invalidate it will still proceed with updating itself and its extensions, but the newly installed / updated code will NOT run until your server's OPcache decides to re-read and re-parse those files.

I would recommend sending a link to this public ticket to your host and ask them to check whether any of these is taking place on their server. I do not know how their server is configured. I do not even have access to your site to check these option values myself. I can only make an educated guess based on the error message you reported, my knowledge of setting up my own servers, and my experience dealing with this kind of issues, as well as the feedback you provided (you already told me that on the one site where the PHP config was "tidied up", i.e. OPcache was cleared as a result, the software works which tells me that I am most likely correct about my educated guess on what is going on).

Ah, I see where the miscommunication lies. I had told you this:

Delete the folder plugins/console/akeebabackup and install Akeeba Backup twice in a row, without uninstalling it before or in between. Then check the files again; their contents should be as I described above.

To which you replied:

I before deleted the directory and reinstalled the component twice in a row.

So, between these two the picture I got is that the plugins/console/akeebabackup directory was deleted and then a new copy without mixed files was installed when you did the double installation of the extension package (note that it's a package, not a component; the package contains the component and all of the plugins).

I will also note that doing grep -R "class AkeebaBackup" -n plugins | grep Extension will find multiple hits since you're only looking for a class named AkeebaBackup in a namespace whose name ends with Extension. This is all of Akeeba Backup's plugins which have akeebabackup in their name, as per Joomla's convention. At the time of this writing, you will find five classes for the quickicon, actionlog, webservices, console, and task plugins.

So, what you really found is that there are multiple plugins shipped with Akeeba Backup which is true and has nothing to do with your problem. However, this prompted you to revisit the earlier instructions I gave you which indeed solved the problem as you completely replaced the outdated files under plugins/console/akeebabackup.