Support

Hello,

Some people had a problem installing Akeeba Backup 8.0.0 or Admin Tools 6.0.0. We have released versions 8.0.1 and 6.0.1 which should address most of these problems, none of which was caused by the update in and of itself but were the result of:

• old plugins we have stopped shipping with our software between 1 and 8 years ago still being installed
• Joomla not installing / replacing all files during the update
• PHP opcode caching (opcache) causing problems after the update

We have also unpublished Akeeba Backup 8.0.0 and Admin Tools 6.0.0 to prevent you trying to use the update without the workarounds.

However, no solution is absolutely perfect. With our software being used in hundreds of thousands of sites you may still run into a problem such as using an update method which still uses the x.0.0 version, the obsolete plugins' files not being removed due to any number of hosting and Joomla related issues, hitting the occasional Joomla bug which executes a partial update, your host not allowing PHP scripts to reset the opcache etc.

The combination of issues outside or control persisting despite anything we can reasonably do, the fact that these new versions are a big update compared to the previous versions and the fact that our software is essentially system software mean that any issue outside our control may result in what appears to be a broken site. This does not happen very frequently; we have updated dozens of sites without a problem already. However, with an impossibly large number of server environments, site development/migration/update histories and the weird Joomla issue that only happens sometimes you may have been hit by an issue during the update.

The following is a COMPREHENSIVE manual workaround to EVERY issue we have seen so far. Please follow it to the letter even if you think something is unnecessary.

Akeeba Backup

The problems typically manifest themselves as an error similar to the following:

• Argument 1 passed to FOF30\Platform\Joomla\Platform::__construct() must be an instance of FOF30\Container\Container
• Class FOF30\Container\Container not found

Here is how to solve this:

1. Make a copy of the file administrator/components/com_akeeba/BackupEngine/serverkey.php
2. Move the folder administrator/components/com_akeeba/backup
3. Delete the following folders (not all folders may exist on your server):
   • administrator/components/com_akeeba
   • components/com_akeeba
   • plugins/actionlog/akeebabackup
   • plugins/console/akeebabackup
   • plugins/installer/akeebabackup
   • plugins/quickicon/akeebabackup
   • plugins/system/backuponupdate
   • plugins/system/akeebaactionlog
   • plugins/system/akeebaupdatecheck
   • plugins/system/aklazy
   • plugins/system/srp
4. If you still cannot access your site's backend go to the Admin Tools section of this reply, follow its instructions and come back here.
5. Download the latest version of Akeeba Backup from our site's Downloads page
6. Go to Extensions, Manage, Install and install Akeeba Backup, twice in a row, without uninstalling it before or in between.
7. Replace the file administrator/components/com_akeeba/BackupEngine/serverkey.php with the one you made a copy of in the first step.
8. Replace the folder administrator/components/com_akeeba/backup with the one you moved in the second step.

If you have Admin Tools continue reading below. Otherwise skip over the Admin Tools section and go to the FOF 3 & 4 sections.

Admin Tools

1. Delete the following folders (not all folders may exist on your server):
   • administrator/components/com_admintools
   • components/com_admintools
   • plugins/actionlog/admintools
   • plugins/installer/admintools
   • plugins/system/admintools
   • plugins/system/atoolsjupdatecheck
   • plugins/system/atoolsupdatecheck
   • plugins/system/oneclickaction
2. Download the latest version of Admin Tools from our site's Downloads page
3. Go to Extensions, Manage, Install and install Admin Tools, twice in a row, without uninstalling it before or in between.

FOF 3 was uninstalled but it's still required

Our software released between mid-2015 and February 2021 inclusive was using version 3 of our FOF backend framework. Software released on and after March 2nd, 2021 is using version 4 of the framework.

Since FOF might be used by multiple extensions, either our own or third party, we check if any extension has been marked as dependent on FOF 3. If none is marked as such we uninstall FOF 3.

This might be a problem in the following cases:

• You have used Discover & Install to install an extension depending on FOF 3.
• You are using a third party extension which does not mark itself or its sub-extensions (plugins, modules etc) as dependent on FOF 3.

In these cases the dependency is not marked in any way and there is no way to know that a FOF 3 dependent extension is installed on your site. As a result FOF 3 might be removed when it's actually needed. You will very likely see an error message saying that a class is missing whose name starts with FOF30\.

In order to gain access back to your site do the following.

• Download the latest version of FOF 3.x from our site's Downloads page. Please note that this is a THREE, not a FOUR.
• Extract the ZIP file.
• There is a folder named fof extracted from the archive. Rename it to fof30.
• Upload the fof30 folder into your site's libraries folder so now you have a libraries/fof30 folder.
  Please note that there might be other folder with similar names in there such as fof, f0f, fof40. DO NOT REPLACE OR DELETE THESE OTHER FOLDERS. The folder fof is part of Joomla 3; if you remove it your site WILL break. The folder f0f is a very old version of our framework used by third party extensions; removing it will most likely break your site. The folder fof40 is FOF 4, used by versions of our software released after March 2nd, 2021; removing it WILL break your site.
• Do NOT try to install the FOF 3.x ZIP file you downloaded in a previous step. This would cause the next time a FOF 4 extension is installed to remove the libraries/fof30 folder again and you'd need to repeat these instructions.

After doing that you may have to clear your server's PHP opcode cache (opcache) per the PHP opcache section in this reply.

FOF 4 was not installed fully or at all

Our software released between mid-2015 and February 2021 inclusive was using version 3 of our FOF backend framework. Software released on and after March 2nd, 2021 is using version 4 of the framework.

There is a long-standing Joomla issue which may prevent the new version of an extension, such as FOF, to be installed fully or at all. It happens rarely but with thousands of sites using our software it's an issue we see every time we publish a new release.

This will usually manifest itself with an error similar to:

• Class 'FOF40\Container\Container' not found

• Class 'FOF40\Dispatcher\Dispatcher' not found

There is a way to work around this.

• Download the latest version of FOF 4.x from our site's Downloads page. Please note that this is a FOUR, not a THREE.
• Extract the ZIP file.
• There is a folder named fof extracted from the archive. Rename it to fof40.
• Upload the fof40 folder into your site's libraries folder so now you have a libraries/fof40 folder. If there was already a folder by that name, overwrite it.
  Please note that there might be other folder with similar names in there such as fof, f0f, fof30. DO NOT REPLACE OR DELETE THESE OTHER FOLDERS. The folder fof is part of Joomla 3; if you remove it your site WILL break. The folder f0f is a very old version of our framework used by third party extensions; removing it will most likely break your site. The folder fof30 is FOF 3, used by versions of our software released before March 2nd, 2021 and third party extensions; removing it will most likely break your site.

After doing that you may have to clear your server's PHP opcode cache (opcache) per the PHP opcache section in this reply.

PHP opcache

Many servers use PHP's opcode cache to speed up the site. PHP is an interpreted language. The source code of every .php file needs to be read, parsed, converted into an intermediate binary representation called "opcode" and then executed. The read, parse and convert stages take a lot of time. The PHP opcode cache stores the opcode representation of files in memory to speed up your site.

However, when you are updating software on your site the opcode may not be cleared (we do try to clear it in the post-installation script of our software but whether this words depends on your server). If it's not cleared your site "sees" the old version of the file. When this happens right after an update the result is that the cached version of the file is out of sync with the rest of the site, similar to what would have happened if the extension failed to update correctly.

In this case you need to ask your host to reset the PHP opcode cache after updating our software.

FEF was not upgraded to version 2 fully or at all

Our software released between 2017 and February 2021 inclusive was using version 1 of our FEF frontend framework. Software released on and after March 2nd, 2021 is using version 2 of the framework.

There's an issue with Joomla which happens rarely and which results in Joomla not replacing all of the files when performing an update.

You can verify this is the case by opening the file media/fef/fef.php and checking if the line

public static function loadCSSFramework(bool $withReset = true, bool $dark = false)

is present in the file. If not, you've been hit by this Joomla issue and need to work around it manually.

• Download the latest version of FEF from our site's Downloads page.
• Extract the ZIP file.
• Upload all extracted files and folders into your site's media/fef folder, overwriting existing files and folders by the same name.

After doing that you may have to clear your server's PHP opcode cache (opcache) per the PHP opcode section in this reply.

Out of date template overrides

This only applies if you have problems in the frontend of your site, you are using one of our extensions with a frontend part (e.g. Akeeba Ticket System, LoginGuard etc) and you have done template overrides to style it.

Please note that the new versions of our software may have changed the view template files you used to create your template overrides or changed their names. Please review your template overrides. This is especially important when you are upgrading to a new minor or major release of our software, i.e. the first or digit before the second or first dot in the version number respectively has changed compared to the previous version of our software you had installed on your site.

The first issue is that you probably have not entered the Download ID in all of your professional Akeeba extensions installed on your site: Akeeba Backup, Admin Tools, Akeeba Ticket System.

If you have not entered a Download ID in all of them one of our installer plugins will kick in. Which one is a big unknown due to the way Joomla works. As a result it's possible to call an older installer plugin which will fail to get the Download ID and halt with this error message.

A viable workaround is to FIRST update the extensions which do not have a Download ID entered, THEN update the extensions which have the Download ID entered. After updating make sure to enter your Download ID in all of our extensions.

If the Download ID is entered correctly in all extensions you've hit one of two issues we can't do anything about.

Open the file administrator/components/com_akeeba/Container.php

Does it have the following line?

use FOF40\Container\Container as FOFContainer;

Yes --> Your problem is with the opcache. You need to reset it.(Reinstalling the component does reset the opcache as part of its post-installation script which would probably be why this solution worked for you. 

No --> Your problem is that Joomla, which handles the update, did NOT copy all the files. Reinstalling the component is the only way to fix it.

We do not have any control over either root cause. Therefore the double installation is probably the best approach in this case.

This problem is definitely caused by opcache. I spent all 8 hours since my last reply to reliably reproduce this issue, understand why it is happening and address it.

Akeeba Backup ships with a file administrator/components/com_akeeba/Container.php which contains a custom component Container class. This extends from the base container class of the backend FOF framework used in all of our software.

Akeeba Backup 4, 5, 6 and 7 were using FOF 3. Akeeba Backup 8 uses FOF 4. Therefore the Container.php file extends from a differently namespaced class.

After Joomla has finished installing the component (but not the entire package) it runs the post-installation script of the component. The post-installation script needs to load the component's container to check if there are old backup profiles that need to be migrated to new settings, if your component settings regarding the front-end backup / JSON API need to be migrated from the old, unified to option to per-feature options and to check whether it should send anonymous information about the Joomla, PHP and MySQL versions used on your server. 

It does that by calling the FOF framework code to get a container. FOF will check if there is a custom container class and use it instead.

If opcache is disabled this is not a problem. FOF 4 has been installed. The new Container.php extends from FOF 4's container. Both are in the same framework family and there is no error.

When opcache is enabled it's possible that PHP had already seen the old Container.php and kept its compiled opcode in the PHP opcode cache. This could happen if your server is configured to not revalidate (check for changed timestamps on) .php files, or if the revalidation frequency is set to something longer than it took between the server last seeing the Container.php and the post-installation script running. This is why we never saw that during our testing. Our servers are configured to do revalidation every 5 to 10 seconds. The only way I was able to reproduce this was to set the revalidation frequency to 60 seconds, go to Joomla's Control Panel, wait for Joomla to show there are updates available and then immediately go to the Update page and install the update.

Why is waiting on the Control Panel page critical? Because looking for updates Joomla will load the installer plugins. If at least one of the installer plugins for Akeeba Backup, Admin Tools or Akeeba Ticket System is enabled this will end up trying to get the container for Akeeba Backup using its then-current framework version which, before the update, is FOF 3. The framework code will load the Container.php file in Akeeba backup's directory and opcache will cache it.

From that point on, the clock is ticking.

You need to go to Extensions, Manage, Update, select Akeeba Backup and click on Update. Joomla will download the ZIP file, extract it, and start installing the contained extensions. The first extension it installs is the Akeeba Backup component. After it's done copying files around it will run the post-restoration script. Mark the time.

If the time elapsed is less than the opcache revalidation frequency OR if opcache is set to never revalidate files the attempt to load the component's container will fail because the custom container is FOF 3 but the framework is FOF 4. This disparity causes the error message

Argument 1 passed to FOF40\Platform\Joomla\Platform::__construct() must be an instance of FOF40\Container\Container, instance of Akeeba\Backup\Admin\Container given, called in /var/www/vhosts/master.my-landingpages.de/j3_master/libraries/fof30/Container/Container.php on line 217

The tricky part is that error message references Akeeba\Backup\Admin\Container which is the namespaced class contained in the Container.php file. Frustratingly, the file said this class extends the FOF 4 container but the error message said that it doesn't. Why? Because opcache was NOT loading the file, it was serving the precompiled file from before the update started which was, indeed, extending the FOF 3 container.

We were trying to invalidate the opcode cache using opcache_reset(). The PHP documentation says that it invalidates the opcode cache. Reading that any sane person understand "resets the opcode cache when called" especially since it returns a boolean which, per the documentation, is true when the opcache has been invalidated.

In actual fact it DOES NOT reset the opcache when called! It WILL reset the opcache AFTER PHP finishes processing the request. You'd think that this massively important point would be documented and put into a big, fat warning box. But no. They never mention it. There is a downrated, greyed out, user comment in PHP's documentation page saying as much. Seeing it I thought "you don't suppose the PHP developer did something that stupid, do you?". So I decided to try a different approach.

Instead of using opcache_reset() I used opcache_invalidate(). The difference is that opcache_invalidate() takes a parameter, the path to a file, and only invalidates this particular file. I did that for the Container.php file. This solved the issue.

Seeing that this worked I wanted to know if I was on to something or not. I restored the site I was using as a test, the one where I was able to reliable reproduce the issue the previous 80-odd times already. Sure enough, installing 8.0.1 reproduced the issue. Restore the site again, install the version with opcache_invalidate(). The problem disappeared.

Then I disabled opcache completely. Restored the site again. 8.0.1 installed without a problem. Another restore. Install the modified version. Installed without a problem.

I repeated these tests in different order another 20 times. In every single case the only way that this could be reproduced was if and only if the opcache was enabled and I was NOT using opcache_invalidate().

So I am, definitely, 100% certain that the problem is with opcache. I have full understanding of the internal workings now.

Which brings us back to your claim that you disabled opcache and had the same issue. HOW did you disable opcache? You cannot disable it in php.ini, .user.ini or .htaccess because OPcache's configuration options are marked PHP_INI_ALL, i.e. they only apply in the main, server-wide php.ini file. After changing that file you need to restart PHP-FPM (if you're using it) and/or your web server. If you did anything different you have not, in fact, disabled opcache. You can verify this from the site's System, System Information page. opcache.enabled will show On instead of Off. I know not only because I read the PHP documentation but also because I did try using php.ini and .user.ini to make sure that they do not, in fact, allow the OPcache to be disabled.

When I replied to you yesterday I had already been working 32 out of the previous 37 hours. I wasn't exactly lucid. You are right that per PHP's documentation these opcache options SHOULD be overridable in .user.ini. In my tests they had no effect and I did restart PHP in case the .user.ini 5 minute cache had kicked in. Thinking I was crazy I did Google it and other people had the same problem. So I shrugged it off and changed it globally. Now that I had 8 hours of sleep (more than I had in the previous 2 days combined) I can see that this makes no sense. It shouldn't happen. I guess there's some server setup debugging in my near future.

Now, what is interesting is that 8.0.2 which uses opcache_invalidate DOES work but 8.0.1/8.0.0 which does not use opcache_invalidate DOESN'T even though OPcache is ostensibly disabled on your site.

The only logical conclusion is that this is not the change in 8.0.2 which made the difference. I have added other workarounds, e.g. trying to load that class file from the temporary location Joomla used to extract the component's ZIP file instead of the component's folder. This would also work around any OS-level filesystem cache gone wrong. This is something that shouldn't be happening but I have seen it before. I guess being paranoid about impossible issues paid off? In any case I am glad 8.0.2 works for you and apparently most other people who had an installation problem.