Support

Akeeba Backup for Joomla!

#34664 Update install error

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by on Friday, 02 April 2021 20:17 CDT

bizguy

Please look at the bottom of this page (under Support Policy Summary) for our support policy summary, containing important information regarding our working hours and our support policy. Thank you!


EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.


Description of my issue: 

While updating my Akeeba backup install to v8, I got the following message and have lost all access to my administrator area:

An error has occurred.
0 Class 'FOF40\Container\Container' not found

Please advise if there is a solution that does not involve restoring from backup.

Ed

nicholas
Akeeba Staff
Manager

It may be that Joomla didn't fully complete the update or you still have installed a plugin which is obsolete and we haven't included in our software for years. This is the full list of plugins which may be causing this:

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

Try deleting all of these folders and install Akeeba Backup 8 again.

Please let me know if this works. I am writing an update which does that automatically when you try to update Akeeba Backup.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

bizguy

I tried the update process on a backup I installed on a dev server and got the following error:

 

An error has occurred.
0 Argument 1 passed to FOF40\Utils\ViewManifestMigration::migrateJoomla4MenuXMLFiles() must be an instance of FOF40\Container\Container, instance of Akeeba\Backup\Admin\Container given, called in /home/admin/public_html/car30/libraries/fof40/InstallScript/Component.php on line 317

nicholas
Akeeba Staff
Manager

There are exactly two reasons why this would happen.

One, Joomla did not manage to update the component's files. This could happen, for example, if their ownership/permissions are wrong OR you hit the Joomla issue which fails to update files when doing major extension updates.

Two, the opcode cache didn't update. When the new version of the framework (FOF 4) tries to load the component the new file is not read from disk. Instead, the opcode cache kicks in and loads the old file that still relies on the old version of the framework (FOF 3). This disparity causes the issue you see.

Check the administrator/components/com_akeeba/Container.php file. Line 12 should read exactly:

use FOF40\Container\Container as FOFContainer;

If it reads FOF30 instead of FOF40 on that line check the file permissions. If the file permissions do allow Joomla to overwrite the file you've hit the Joomla bug. In our experience there's approximately 0.3% probability of hitting it. If you can hit it consistently I want a backup of that site because this is a bloody Joomla bug I am trying to reproduce consistently so I can fix it since 2007!

Most likely you'll see that the line reads FOF40, though. In this case the problem is the opcode cache. If this is the case please let me know. I think I have an ace up my sleeve to deal with that.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

bizguy

Sorry, I can't help. The container.php file on Line 12 reads:

use FOF40\Container\Container as FOFContainer;

Best of luck tracking it down in the future.

Ed

bizguy

Just an FYI.

I installed your v8.0.1 Akeeba Pro update on a couple of more sites, and still got a similar error. While the v8.0.1 removed all your outdated extensions, I found that I had to disable:

plg_quickicon_joomlaupdate

To remove the error and gain access to the admin of the site. The Akeeba update did not complete, but after the plugin was disabled, I was able to install the update, along with all other extension updates and the Joomla 3.9.25 update.

Cheers,

Ed

nicholas
Akeeba Staff
Manager

Well, this doesn't make any sense whatsoever since version 8.0.1 DOES NOT HAVE THE CODE that would result in the same error message! How is it possible that your site runs code that's not there?!

Moreover, pig_quickicon_joomlaupdate is part of Joomla itself and is in absolutely no way related to our software. It does not interact with it and we do not interact with it in any way. Furthermore, it doesn't even load in the extensions installer page. All quick icon plugins only load on Joomla's Control Panel page.

I think that the actual problem is PHP opcode on your server and configured to not check files' timestamps for a very long time. Since Joomla copies the pre-/post-installation script file into the extension's folder (administrator/components/com_akeeba) your server doesn't know that it's a different, new file. Therefore it tries to run the code it has cached from version 8.0.0.

While you were toggling plugins the cache time expired. This is the actual reason why disabling a totally unrelated plugin seemed to have any effect at all. It wasn't the plugin that you disabled, it was the time you spent between successive attempts to install Akeeba Backup that made the difference.

Unfortunately, there is nothing we can do to work around that. The only code we can run during Joomla updating extensions is in the pre-/post-installation script. Your problem is that your server doesn't see this file's latest version.

The correct solution here is that Joomla SHOULD be resetting the opcache three times when updating an extension: before running the pre-installation script, before running the post-installation script and before the installer code returns. Unfortunately, this means that the people who write Joomla need to understand how servers work. They don't and they don't listen to me. I have had much better luck trying to explain quantum physics to a toddler. I am not even kidding. I have tried explaining the opcache issue to Joomla core contributors but it was like talking to a brick wall. I have explained quantum physics (Schroedinger's cat) to my 3 year old and she mostly got the idea that the we don't know if the cat is, er, "awake" or "asleep" unless we open the box.

A different solution would be not using Joomla's update system to install updates. However, this is not a practical one. Using Joomla's update system is a requirement to be listed in JED. If you uncheck the "uses Joomla updater" box you cannot make a new JED listing or update an existing one. Moreover, you (I mean the plural you, my clients) want me to support the painfully subpar Joomla extensions updater which is why I started using it years ago despite knowing how bad it is.

So, there's nothing I can tell you except to either temporarily disable opcache or wait an hour or two with a broken site before retrying to install the update because the problem lies outside my software and there's nothing more I can do about it :(

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!