Support

Attachments are private; only the person filing the ticket and our support staff see them. Otherwise it'd be outright impossible to have public tickets, given the nature of our software :)

The error message you sent me (“Oops! Your Akeeba Backup database tables are corrupt...”) only shows when Akeeba Backup encounters a fatal error while trying to load data from the #__akeebabackup_profiles table.

I am wondering if what you see happens because you are working on a site locally on Windows or macOS and the site has an uppercase character in its database table name prefix, or if the table is genuinely corrupt (as in: MySQL can no longer read the table). Neither issue would be fixed by Joomla's database fix page. That page only addresses a minimum of table row changes and missing tables.

Try uninstalling Akeeba Backup. Make sure the #__akeebabackup_profiles table is removed. The reinstall it.

Hello Sigrid,

Harald emailed me that his transparent translation extension was involved in this. I have created a workaround based on the information he gave me, without having a copy to test it myself.

Could you please install the dev release from https://www.akeeba.com/download/developer-releases/akeebabackuppro-dev/rev8c25d86.html and tell me if that fixes the problem you have on your site?

If you give me a positive test I will include this change in Akeeba Backup 9.0.9.

Thank you in advance!

The problem has to do with Akeeba Backup trying to figure out how to reuse Joomla's database connection object with its own wrapper. Since Harald's extension overrides the default mysqli driver with something that does not have “mysqli” in its name we cannot find a suitable driver. This triggers an error condition which is picked up by the initialisation code and reports an error.

The backup works either because it runs on CLI (where Harald's extension does not kick in) or because of a fail–over in the backup code which tries to create a new connection using the Global Configuration information when reusing Joomla's connection is not possible.

The fix I applied does a more involved detection of the database connection type in Joomla's database driver object. If the name does not match any known core Joomla driver we start checking the object inheritance hierarchy by object type — most third party drivers will extend a core Joomla database driver. If we still can't figure it out we check the class names in the class hierarchy and try to divine the database connection type. We were doing that in Joomla 3 / Akeeba Backup 8 to some extent but we had not ported that to Joomla 4 / Akeeba Backup 9 because we were not aware of any third party drivers. Now that we are it was easy adapting and improving our old code.

Harald says it works but I'd like another test from you — since you have a positively affected real world site — to be extra sure that we really did get it right with this fix.

When you get an error like that delete the administrator/cache/autoload_psr4.php file and reload the page. This file is regenerated automatically by the XML manifest information of all installed extensions.

Also note that the backup and restoration have not changed in the version I sent you. The only change was the detection of the database driver.

Please redo the restoration and delete the aforementioned file. Make sure that the plugins/quickicon/akeebabackup/akeebabackup.xml file exists after restoring. That's all there is to it.

You don't need to redo the restoration on this server. Just test another restoration on a different server (local server works great for that) to make sure the file is there. If it's there then the problem post–restoration wasn't related to the restoration, it was just Joomla doing its own silly thing when you restored on top of an existing Joomla 4 site.

If you confirm it was the latter case I will add a small change in the restoration script to delete that file automatically so this issue doesn't happen again for you or anyone else..

Thank you very much for the update!

Have a great day :)