Support

Do not trust the broken and untrustworthy information in the so-called “Pre-update check”. Its logic is completely broken. It tries to use the extension update information to determine if a version of an extension is compatible with the new version of Joomla. This is completely wrong, and I have told the Joomla! maintainers four times between August 2020 and July 2021 (the year prior to the Joomla 4.0 stable release).

Extension developers will of course choose to not make available an older version of their extension to a newer Joomla version. We do not want people installing Akeeba Backup 8 on Joomla 4, even though technically it is compatible. The reason is that it does not and cannot have full support for some Joomla 4 features which are not present in Joomla 3. Joomla shows that in the “pre-update check” as Akeeba Backup 8 not being compatible with Joomla 4 which is, not to put too fine a point on it, utter nonsense. Akeeba Backup 8 was released as the “bridge” version between Joomla 3 and 4.

Ignore the wrong and slanderous information in Joomla's useless “pre-update check” page. Use the process outlined in our official migration guide.

 So I decided I would just start fresh with Joomla4 and rebuild everything from scratch. It will be cleaner over all, but the work involved will be nuts between copy/pasting articles (I have over 2000) and redoing the menu but hopefully in the end it will be worth it as I won't have to worry about old code etc. 

There is a better way to do that without having to copy over content.

Take a backup. Restore it in a new subdomain or test server. Uninstall every third party extension. Install Akeeba Backup and take a backup. Upgrade to Joomla 4.x. No need to copy articles, no upgrade issues.

If this is an issue, I have been told that if this is a problem "You can take an export of your MySQL database (e.g. through phpMyAdmin), then use a text editor to replace all instances of your table name prefix with a lower case equivalent. You would then re-create your database, import your modified backup, then adjust your 'configuration.php' for Joomla accordingly."

Yes, it will be an issue in many cases. If you do what I described above, when restoring choose a new prefix with all lowercase letters.

Thanks Nicholas.  I keep wishing that you were the one in charge of Joomla and you could bring your expertise and professionalism to the system.  :)

A few months ago my wife got elected as the President of the OpenSourceMatters board, the body overseeing Joomla. She's been trying to restore sanity to the project's leadership structure ever since (a mighty feat if you ever saw one). Just give it a while, people need to change one way or another (either change their mentality, or replaced with those who have the right mentality).

Yeah, I know that Softaculous does that. The problem is with MySQL itself and case–insensitive filesystems.

Softaculous only runs on Linux which only has case–sensitive filesystems. MySQL can run on Operating Systems with case–insensitive filesystems such as Windows (NTFS, FAT, FAT32, and exFAT are all case–insensitive) or macOS (if the volume is formatted as case–insensitive HFS+ or APFS, which is the default since several years ago).

The problem lies in the on–disk layout of MySQL databases and how that relates to MySQL listing the tables of a database. MySQL creates .ibd (InnoDB tables) or .frm (MyISAM) files for each and every database table. For example, an InnoDB table named F0O_users has a file named F0O_users.ibd created in MySQL's folder for that database. When you ask MySQL to list the tables in a database it looks for these files and prints out their filenames, without their extensions.

Here comes the fun part.

If you are on a case–sensitive filesystem, e.g. your Linux server, MySQL returns the filename without the extension verbatim. This table is listed as F0o_bar and the backup engine knows it belongs to your site. It's backed up as #__bar which allows you to change its prefix when restoring it. The backup can be restored on any server.

If you are on a case–insensitive filesystem, e.g. a Windows or macOS computer, MySQL returns the filename without the extension in lowercase by default. This means that the aforementioned table is reported as f0o_users, not F0O_users. Because of this issue in MySQL, the backup engine cannot know that the table is the same as F0o_users, therefore it backs it up as f0o_users unless you have a filter to exclude any tables not belonging to your site (in this case no tables are backed up and the backup is unusable). The backup with the lowercase tables can be restored as long as you set the table name prefix to its lowercase version: f0o_. If you use the original table name prefix (f0o_) then the restored site will be unusable if you are restoring to a case-sensitive filesystem (because your site will be looking for F0o_bar, not the created f0o_bar) and any subsequent backup will suffer from the same issue.

This is not a problem in Akeeba Backup itself, though. It is a problem with MySQL. You will get exactly the same problem if you use phpMyAdmin to backup your database tables. That's a point that nobody gets and a reason why people who run into this problem use Akeeba Backup. We warn them about the problem, propose a solution, and they can solve their problem very neatly.

Unfortunately, solutions like Softaculous are disconnected from real world users. Their business model is that they only care about the hosting company running their software on a Linux server which runs one of the Linux distribution versions they support. The fact that what their software is doing is screwing up users who want to transfer their site between their server and their local computer, or between servers with different Operating Systems, is not a use case they care to support. We have to support every use case, hence the warning that what you have right now will cause problems, and the suggestion to fix it.

That said, I've been thinking about a solution to this problem — but I do need to run a few more tests. It boils down to this. If we have a mixed case or all uppercase table name prefix (e.g. f0O_) we can check if we can list any tables with that prefix. If not, but we do have tables with the all–lowercase prefix (e.g. f0o_) then we know for a fact we have hit MySQL's stupid case-sensitivity issue. This should let us magically change the prefix we expect to all–lowercase, alleviating the problem. Well, that's the theory. Once I fix some time I will put it to the test. If things work the way I suspect they do, this warning will be a thing of the past and Akeeba Backup will be able to magically back up and restore your site regardless of the database prefix case sensitivity.

As I've always said, it really pays to listen to your users; they will let you know about use cases you would have never thought about on your own. I know that my wife is trying to build a Joomla! leadership team which believes the same and is willing to use us 3PDs as a proxy for getting feedback from the myriads of users. We're good at filtering the noise, identifying patterns, and come up with solutions — we kinda do this for a living, right?! If Joomla will let us be its wingmen we will all be better for it. This change has already started, if somewhat slowly. Hope's not lost 🤞🏼

I noticed you have an update for Akeeba, any chance this resolves the prefix issue?

No, not yet. This is a change which requires some time to work on and affects all backup products. As a result, I am going to be working on it in late July and August, when our support load is minimal and we have no releases planned.

Thank you! Have an awesome day :)