Support

Hello,

We have received a number of reports regarding the updates to Akeeba Backup 8.0.0/8.0.1 and Admin Tools 6.0.0/6.0.1.

We have released versions 8.0.2 and 6.0.2 which address the root causes of all of the issues which have been reported to us. If you still have access to your site's backend please install these new versions. If not, please keep reading.

The root causes of all of the problems identified were the following:

• Old plugins we have stopped shipping with our software between 1 and 8 years ago were still installed. These plugins made assumptions about which backend framework our extensions were using and failed during or after the update.
• Joomla not installing / replacing all files during the update. This was especially problematic when it happened in the backend (FOF) or frontend (FEF) framework used in our extensions because it could make all these extensions failed which could cause anything from display issues to outright inability to use your site's backend.
• PHP opcode caching (opcache) causing several problems in the course or after the conclusion of the extension update. These problems only happen on hosts which are misconfigured to not check if the files have been updated — a bad idea if you are running an off-the-shelf CMS which updates itself and its extensions / plugins / modules, i.e. replaces .php file during the course of a page load — or had a revalidation (check if files have changed) frequency that was too big. These servers ended up not “seeing” the updated files which would either cause the update to fail (needing to run it a second time to clear the error) OR made it look like there were missing or broken files by throwing messages about missing classes or methods when, in fact, the correct classes were there.
• Your template overrides are out of date (only applies to frontend components).

If you have been locked out of your site after installing any of the previous versions of our software please follow the solutions below.

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 you are modifying the same .php files it uses to process every page request. If the opcache is not invalidated (cleared) your server “sees” an old version of the file. This can result in error because your server “sees” a mixed bag of versions of different .php files, versions which may not be designed to be work together and which do not reflect the actual files stored on your server's disk.

We were trying to address this issue by asking PHP to reset the opcode cache (opcache) by using the opcache_reset() function it provides for this purpose. However, the official PHP documentation about how opcache_reset works is wrong! The documentation says that it invalidates the opcode cache, implying that this happens immediately. In fact, it happens asynchronously, after PHP has finished executing the current request. This meant that the opcache was effectively not reset while Joomla was running the post-installation script included in our software. Depending on which pages on your site you had visited before and when, which plugins you run on your site and the configuration of opcache (especially whether and how often it looks for file changes) this would mean that might very well end up with opcache “seeing” old versions of the file during the election of the post-installation scripts or right after the installation had concluded. As a result, you might have experienced errors during or after the installation.

We are now using a different approach with opcache_invalidate() on each .php file included in our software package which addresses this issue.

If you are stuck after installing a previous version of our software you might need to ask your host to reset the opcache or tell you how to do it yourself.

Akeeba Backup: old plugins and Joomla issues causing problems

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: old plugins and Joomla issues causing problems

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.

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.

I reject your passive aggressive dig at my professionalism but I am willing to excuse it on the grounds of ignorance of the root cause of the error you are receiving.

I will give you a few quick workarounds before going into the details of what is going on and why, what we do about it and why it might not work on your server. Here are the quick solutions (you can use ANY ONE of them, not ALL of them):

• Disable opcache on your host before updating extensions.
• Configure opcache so that it revalidates files (checks their timestamps) and has a revalidation frequency between 2 and 15 seconds. Make sure that you DO NOT disable the opcache_reset and opcache_invalidate functions in your php.ini or you are shooting your own two feet.
• Install the update twice, waiting in between as many seconds as your opcache revalidation frequency is.
• Delete the file administrator/components/com_akeeba/Container.php before updating Akeeba Backup

And now let's get to the details.

I've actually spent the last 40 days working twelve hour days, 7 days a week to prepare these releases. I spent February 25th to March 2nd testing the software installation on a plethora of live, testing and development sites. Issues were discovered and fixed, thank you very much. Despite that, there's a relatively small number of sites which had some issues installing the updates, none of which actually having to do with our software. They come down to the following:

• Old plugins we haven't shipped for 1 to 8 years still being installed and published. This is a user problem.
• Joomla not copying all files on update. This is a Joomla problem — we don't control that part of the update process.
• Third party software using our FOF framework version 3 not having marked themselves as dependent on FOF 3, against our very strict admonition that doing that would result in FOF 3 being uninstalled when someone uninstalled or upgraded any other FOF powered extension (like Akeeba Backup). This is a third party problem.
• Badly configured PHP opcache on your server not being invalidated when the extension files are being updated, causing problems during and after the upgrade. This is a Joomla problem (it should be invalidating all .php files being copied during an udpate) and a server configuration problem (obviously, PHP opcache is set up at the server level).

Despite the fact that none of these issues are of our own making I have been working 32 (and counting) of the past 37 hours to identify the root causes of these issues, come up with workaround and test the workarounds on affected sites. I could have easily said that it's not my job to fix user issues, Joomla issues, third party issues and server issues because, frankly, it is not. Yet here I am doing exactly that because I actually care.

Your issue is caused because your server is seeing an older file, not the one we put in the package.

Both the old and the new versions of the software have the class \Akeeba\Backup\Admin\Container defined in the file administrator/components/com_akeeba/Container.php

In the old version the class extends from \FOF30\Container\Container whereas in the new version it extends from \FOF40\Container\Container. This is because, as I have already said, the two versions use a different major version of the backend framework (FOF 3 in the old, FOF 4 in the new).

When installing the update the file is overwritten by the new version. If it's not overwritten it's because of a Joomla bug that has existed since Joomla 1.5.5, it happens infrequently and causes some files to not be copied over during an update. We have documented it; go check the documentation now. This is Joomla code we cannot change. What we can do about it and have been doing for the past two years is try to see if any files are missing and copy them over manually. The check depends on file size (since Joomla does not preserve the file date on update; another Joomla failure) which means that it will not work for this particular file since it has the exact same length in both versions. So, check that file after update. If it still references FOF30 instead of FOF40 go be mad at Joomla, not me. The reason being that Joomla didn't copy the file we put in the package, therefore you have a partial update for reasons OUTSIDE our control.

If the file is copied over correctly by Joomla the question becomes, does PHP actually load it? This is where opcache comes into play. If opcache has encountered that file in a page request happening within the last X seconds it will not load it from the server storage. It will use its cached version. Since the old file extends the FOF 3 Container class but the new version of the software expects it to extend the FOF 4 Container class you get the error you posted.

We are of course aware that this can happen, so we do try to reset the PHP opcache. In versions 8.0.0 and 8.0.1 we were using opcache_reset(). The PHP manual says that it reset the opcache and returns true when it does. THE PHP MANUAL IS WRONG. This is NOT what this function does. When it returns true it means that at some point in the future it will reset the opcache; after PHP has finished handling the request. Since Joomla is trying to effect the update within a single request this will fail to have any effect. Your PHP installation will use the old, cached file and fail with the error you posted.

I spent eight hours today trying to identify why this happens. Since the PHP manual was wrong it took a very long time to figure out why the code that's clearly there does not work. Once it was obvious that the PHP manual is wrong I tried different things. What worked, the ONLY thing that worked, was using opcache_invalidate to tell PHP to invalidate this particular file before it's used in the post-installation script of Akeeba Backup. I did 20 sets of 4 installation tests each (with this change, without this change and with opcache enabled or disable), each set of tests having different opcache settings to confirm that the workaround to an impossible issue works. It does work.

HOWEVER! Whether it works is contingent on YOUR server setup. PHP may have disabled the opcache_invalidate function or it may not be supported in your server environment or, otherwise, PHP may have decided that it cannot in fact invalidate the file in opcache. In this case you will STILL get the same error and there is nothing else we can do.

Deleting the file in any point of the installation process does not work because it's already cached. Force loading the class from a different file doesn't work either; PHP has already loaded it so doing that results in a fatal error. PHP cannot unload classes. Renaming the class is not feasible. Going back in time to remove that class is also impossible. This leaves us with a very small number of servers with really problematic configurations where you have to disable opcache, or either delete the file or reinstall the extension waiting for at least as many seconds as the opcache revalidation frequency set up on your server.

So, yes, of course I have tested before releasing. 80 installations, each one requiring a site restore so I can start from a clean slate is not exactly what you'd call "untested".

No, it's not my job trying to address any of these issues that have nothing to do with my software and everything to do with external factors. I do it anyway because I care. There are objective, technical limits to what I can do to work around crappy server environments and third party bugs in my software.

No, it's not my job to ensure that your server is correctly configured for use with a mass distributed CMS which updates its own files and the files of third party software it uses; that's your job and if you don't understand the implications of opcache in updating software you shouldn't be using it. More so if you don't understand that its default configuration is geared towards Symfony applications with the reasonable expectation that the DevOps team deploying new versions of the application will do so atomically, outside of the PHP execution context, and will restart all running PHP processes at the end of the deployment i.e. the EXACT OPPOSITE of what happens when you update a Joomla extension or WordPress plugin. The fact that you hadn't bumped into something breaking spectacularly is happenstance, it's not that other software is better tested. They are simpler, using older code which simply throws PHP warnings you never got to see. Our software is using modern PHP and is system-level so yes, when it breaks, it's a very visible failure as opposed to, say, a newsletter component simply not showing the add me to the mailing list button correctly for a while before it "magically" fixes itself after a while.

Are we clear about the root causes and whose job is what?

Thank you. I understand the frustration — believe me, I do.

I am trying to figure out if there is yet another magic trick or two to pull out. I am doing some tests now. If they work within the next three hours I will re-release 8.0.2. Otherwise that's pretty much it, I have given it more than I've got.

If only Joomla had taken me up on the offer to make a better installer back in 2012-ish when I'd written a white paper about it. I fully expected that having the pre-installation, installation/update and post-installation code run in the same page load be a problem so I had proposed to split them in separate page loads. Had this been the case this would be a trivial issue to fix. Disable old plugins and delete the Container.php file in pre-installation, re-enable current plugins in post installation and Bob's your uncle. Well, if only...

And done. I am doing some really evil tricks now. I delete the file on pre-installation. If the installation fails you're pretty much guaranteed the next attempt will work because the formerly cached file no longer exists. I am doing some ugly things to load the Container.php file from the temporary directory Joomla creates when installing the update if the class is not already loaded to avoid hitting opcache (the folder's name is random and pretty much guaranteed not to be seen before). Finally, if all else fails, I just skip over some post-installation tasks which are only really useful if upgrading from versions before 7.0 which I presume are far less common if you have hit the bingo of weird server conditions.