Support

Are you sure the column read “oublish up”, not “publish_up”? If so, someone screwed up and used an invalid column name. This is the first time I've seen that in 16 years. Find that developer and flog them have a friendly discussion with them about how database tables are supposed to be built.

Have you tried restoring your Joomla 4 site on top of an older site made with Joomla 3?

It does not work fine. Your site is subtly broken. When you do an upgrade from Joomla 3 to 4 some files are removed. By restoring a backup of a Joomla 4 site on top of a Joomla 3 file these files are not removed and cause subtle but important issues.

You need to DELETE all files and folders of the Joomla 3 site, then REMOVE the Joomla 3 tables from the database. Only then should you try to restore the Joomla 4 backup.

You can choose to ignore my warning at your own risk and peril. If you ignore my advice your site WILL be broken and I will NOT be able to help you fix it. That's why I have been warning people about that since 2007, when Joomla 1.5 was released and we had the first run-in with this problem. This is also documented in https://www.akeeba.com/documentation/akeeba-backup-joomla/restoring-backups.html#general-guidelines:

Do not try to overwrite one Joomla! version family with a different one. Overwriting a major version with another (e.g. restoring a backup taken on Joomla! 3.7 on top of a site running Joomla! 2.5 or vice versa) or between different minor versions (e.g. restoring a backup taken on Joomla! 3.7 on top of a site running Joomla! 3.6 or vice versa) will NOT work. Joomla! moves files around between minor and major versions. Since the backup does not delete files not present in the backup archive this will end up with Joomla! being "confused" and malfunctioning. In these cases you should delete the existing files and folders (except, perhaps, user generated content) before restoring the backup. You can safely restore a sub-minor (path-level) version on top of another. For example, you can safely restore a Joomla! 3.7.5 site on top of a Joomla! 3.7.3 site or vice versa.

OK, now we're getting somewhere.

On that restored site I want you to set Debug Site to Yes, reproduce the issue, and take a screenshot of it including the debug trace (VERY IMPORTANT!). Upload the screenshot here so I can see exactly what the error is and where it is coming from.

It looks like you have excluded your site's #__menu table from the backup.

The screenshots are useless to me. I need two different pieces of information.

First, I need the backup log file. This will tell me what went into the backup. I am looking to see if the #__menu table is included in the backup.

Actionable item: Please ZIP and attach the backup log file from when you took that backup.

The next thing I need, is you to tell me if there are any errors during restoration. If so, I need a screenshot.

Actionable item: Screenshots of errors during the site's restoration, if any.

I only have screenshots, I do not have the log file.

I do not need screenshots or a video, I need the backup log file. You need to go to the Manage Backups page and click on View Log on the backup record which corresponds to the backup you are trying to restore. In the new page click on the Download Backup Log File button. It downloads a .txt file. Put this txt file in a ZIP archive. Attach the ZIP archive to your next reply.

If the ZIP archive is over 10MiB please let me know, we'll need to do something a little bit different.

THANK YOU! I can now see the problem.

You have two sets of tables using the prefixes q31H4_ and q31h4_. Note that they are not the same. The are ALMOST the same, but the first one has a capital H and the second one has a lowercase h.

The tables with the q31H4_ prefix are from an old installation, presumably a Joomla 3 or older site which was upgraded at some point.

The tables with the q31h4_ prefix are the ones from your current Joomla 4.2.5 site.

Depending on the configuration of both your Linux server and your local server this CAN cause problems because of the way MySQL works with uppercase letters in table names. Please see https://www.akeeba.com/documentation/warnings/q106.html

The solution in your case is to exclude all tables with the UPPERCASE letter (q31H4_) prefix before backing up your site. You can do that in Akeeba Backup, RegEx Database Exclusion. Create a new row of the type Exclude a table and with the Filter Item set to !/^#__/   This excludes all tables which do not have the prefix configured in your site. Take a new backup and restore it.

Please note that depending on how your Linux host is configured this may not work. If that's the case, you will need to delete all tables which have the the UPPERCASE letter (q31H4_) prefix from your site.

Also note that this problem only happens when restoring your site on a target server which stores the MySQL data in a case-sensitive filesystem. This is every Windows machine (all Windows filesystems are case-insensitive), most macOS machines (HFS+ and APFS are case-insensitive by default, both as they come out of the factory and when you format an HDD/SSD), and extremely rarely on Linux machines (e.g. when they are using a Samba share to a case-insensitive Windows machine, a disk formatted in NTFS or FAT32, etc). In short, you will practically only see this problem when restoring on Windows or macOS but not when restoring to a live site which runs on a Linux server.