Support

Akeeba Backup for Joomla!

#36709 Restoration error 'SESSION variable 'max_allowed_packet' is read-only.

Posted in ‘Akeeba Backup for Joomla!’
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

cursulak

Hello, 

This is not an existing site back/restore error but a new install of the template that came as a site restore via Akeeba backup. 

I do have Akeeba on my functioning site as well, which makes me very concerned about this problem as I suspect my restorations will not given this error on my functioning sites. I control my own server and here are the specs, I cannot provide an aleeka backup log at this time. 

Server: Mac OS X

PHP: 8.1.2, mysql 8.0.25, Joomla 4.1.0

From my understanding from what I've read:

1) the new mysql cannot be adjusted to allow writeable as indicated in the error

2) there seems to be some issues with Akeeba and PHP 8* and mysql 8*. 

 

If this is true, then updating Akeeba ASAP is critically important. 

Please advise. 

nicholas
Akeeba Staff
Manager

This is already fixed in Akeeba Backup 9.2.0 released today.

It was indeed only an issue with PHP 8.1 when using the PDO MySQL driver (the MySQLi driver seems to be unaffected).

So, yes, we were aware of how critical fixing this was which is why I worked over the past week like crazy to finalise version 9.2.0 two weeks ahead of schedule and release it today.

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!

cursulak

Thanks for that and I will install the update on the functioning sites. 

So for a package that has been delivered to me with a kickstart wrapper likely, how do I get that to use the new code of the recent update?

Keep in mind there is no functioning install for that site, it's a start from scratch rebuild from a sold template.

Advice would be greatly appreciated, thank you. 

nicholas
Akeeba Staff
Manager

There are three options for you, from easiest to hardest:

  1. Use the MySQLi driver instead of the PDOMySQL driver during restoration, as long as your server supports it. As I said, this only happens with the PDOMySQL driver on PHP 8.1.
  2. Use PHP 8.0 or 7.4 for the restoration. As I said, this only happens with the PDOMySQL driver on PHP 8.1. 
  3. Replace the restoration script.

If you want to go with the latter option, here's how to do it.

  1. Take a backup of any site. It doesn't matter which site as long as it's a Joomla 4 site being backed up with Akeeba Backup 9.2.0 or later and it's a full site backup.
  2. Extract the backup on a temporary server e.g. a local server.
  3. Keep the installation directory.
  4. Remove the following:
    • installation/sql (directory)
    • installation/README.html
    • installation/extrainfo.json
    • installation/tmp
  5. Upload your backup archive and kickstart.php to the target server
  6. Extract the backup archive on the target server, i.e. run Kickstart up to the point it shows the Run The Installer button WITHOUT clicking that  button. Leave the window open.
  7. Upload the installation directory from step e, overwriting existing files.
  8. Go back to your browser and click on Run The Installer. You are now using the Akeeba Backup 9.2.0 restoration script.

I'd recommend trying the solutions I gave you in this order 2, 1, 3. Solution 2 will prevent post-restoration troubles, especially if the site has extensions which are not fully 8.1 compatible. Given how much has broken in PHP 8.1 I'd say that's all extensions and even Joomla itself at this point in time.

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!

cursulak

You mention this only happens on the PDO driver, I have never used that driver and always use the MySQLi - I get the error on this version. 

I've alway had php 8.1.2 installed if you read the first post. 

 

So in terms of your recommendation I've already done 2 and 1 and have been trying under those conditions. 

As for #3 - the script is in a purchased package based on an older akeeba archive. You mention in your latter comment, take a backup of a site - that is not my problem. I have a bundled purchase product which I cannot go back and get rebounded with the 9.2.0 version. I also suspect there will be many which have this issue from joomla 4 being out for a while. 

Is there a way to update the Angie engine in it to be compatible with the above php and mysql conditions which the installed version of code has been updated for. 

In essence I'm hoping to just update angie and have it complete the recovery. Please advise if this can be done. 

nicholas
Akeeba Staff
Manager

> You mention this only happens on the PDO driver, I have never used that driver and always use the MySQLi - I get the error on this version. 

Nobody reported it with the MySQLi driver and we couldn't reproduce that with that driver either.

However, while fixing it last week, I did see that the same code was present in both the PDO MySQL and MySQLi driver. On my server I could only reproduce the issue with PDO MySQL. It didn't make sense as in both cases there was error catching around the erroneous statement which is why in previous versions it did not cause a problem. In theory, PHP should never throw an uncatchable error since PHP 7.0 — that's how it's designed. So why this issue even happens seems to be a bug in the PHP database drivers.

The logical conclusion of that would be that on some servers the MySQLi driver might be affected as well. I assumed this might indeed happen to your server too which is why I gave you three solutions, not just one.

I was trying to keep my reply short and simple. If you want me to give you a seminar on software architecture with each of my replies, sorry, that's not included per our Terms of Service and just like your doctor doesn't give you a seminar on pathology before giving you a prescription and your car mechanic doesn't give you a seminar on internal combustion engines before telling you how to start a choked engine with a fuel injection line instead of a carburettor (the latter is something we've all learned in our youth, even though, again, nobody told us WHY we had to change the choke setting).

> I've alway had php 8.1.2 installed if you read the first post.

First of all, let's start with the fact that I did carefully read your issue like I do with every ticket I reply to. In fact, I do go through the entire conversation every time I reply to a ticket. That's why we have a ticket system instead of doing support over email. I did see that you are using PHP 8.1 and did say that this issue occurs only with PHP 8.1.

So, yes, of course I am aware you have PHP 8.1.2 and correctly identified it as a prerequisite for the issue to occur.

> So in terms of your recommendation I've already done 2 and 1 and have been trying under those conditions.

No, you have not.

What you did is equivalent to solution #1 only.

Solution #2 asks you to downgrade to PHP 8.0 or 7.4. Instead, you explicitly told me that you HAVE NOT. Therefore, by doing the exact opposite of solution #2 you have NOT followed solution #2.

Are you clear on the fundamental concept that PHP 8.0 comes before (is lower than) PHP 8.1.2? I am not being sarcastic, I am being factual.

> the script is in a purchased package based on an older akeeba archive

We do not publish site packages or site packaging software. We publish backup software.  A third party can take a backup of a site and publish it as a “site package”.

You can call it whatever you want. A site backup. A site package. A thingamagic. Clint Eastwood (if you appreciate a Back To The Future reference). The name is irrelevant.

Whatever you call it, it's a site backup. I hope that makes it clear.

> You mention in your latter comment, take a backup of a site - that is not my problem.

As you already know (it's in our documentation AND on Kickstart's first screen), the installation script is included in the backup archive at the time of the backup. Therefore the canonical way to get a copy of the installation script is to take a backup of a site, any site will do.

Furthermore, the only way to “update” the installation script is to first extract the backup archive, then extract the new installation script over it. This is exactly because the installation script is included in the backup. Extracting the backup also extracts the (and overwrites any existing) installation script. Therefore the “update” must be applied after the backup archive is extracted.

This is solution #3 in my previous reply.

So, no, you are wrong. It is exactly your problem.

Remember what I wrote very clearly in point (a) of solution #3? “Take a backup of any site. It doesn't matter which site as long as it's a Joomla 4 site being backed up with Akeeba Backup 9.2.0 or later and it's a full site backup.

If you have a Joomla 4 site, install Akeeba Backup 9.2.0 on it and follow my instructions.

If you do not have a Joomla 4 site, install Joomla 4 on any server (local or live, IT DOES NOT MATTER), install Akeeba Backup 9.2.0 on it and follow my instructions. If you don't need that site anymore, delete it. We don't care. We just want a backup of a site to grab its installer!

> I also suspect there will be many which have this issue from joomla 4 being out for a while. 

Your suspicions are unfounded. We've been publishing the top rated Joomla extension for 16 years. We have a very good way of rating the severity of issues and prioritising them accordingly.

For starters, we have already published a version of our software which resolves this issue. So your point of it needing to be fixed is moot. This is literally the very first thing I told you and the entire reason solution #3 works.

Moreover, this only happens with PHP 8.1, a version of PHP installed on merely 3% of the Joomla 4 sites, themselves only being just shy of 20% of the total number of Joomla sites per our usage statistics. This means that 0.6% of all sites using Akeeba Backup are affected at the time we published a new version.

Only ~5% of the site owners restore a backup older than a few days to a few weeks. Therefore within the next month only 0.03% of site owners would have that problem. Only 10% of these people ask for support instead of looking at past issues which means that only 0.003% of site owners with be asking for support.

So, no, this is not going to be a big issue because we correctly prioritised the resolution of this issue before it became a significant issue.

Having a problem with the installer is not a novel case. We are not just now trying to find out how to best address it, nor are we newbies who'd be at a loss to find a solution. Installer issues have very obviously happened before and will happen again; we are under no illusions that any amount of testing can catch all of the issues which may arise in the myriads of combinations of PHP, MySQL, server software, their settings, Joomla versions, extensions, database structures, data etc. If there's something 16 years of doing this has taught us is that there a lot of “impossible” issues which do happen — like having a try/catch block which does not catch an exception on PHP 8.1 even though all PHP errors, including fatal errors, are exceptions since PHP 7.0 released 7 years ago! (That's the issue you've hit.) Impossible! And yet, this is not even the most weird of impossible issues we have dealt with.

We know we will definitely have installer issues when PHP breaks backwards compatibility hard as it happened most recently in 2015 with PHP 7.0, in 2018 with PHP 7.4, and now with PHP 8.1. In every single case we addressed whatever was the issue very early and we had a total of 2–3 tickets per PHP version. For all affected users we were giving the same instructions as solution #1 and #3 I gave you.

So, no, this is not an emergency because of the way we handled it. It's a bog standard simple issue which doesn't even remotely qualify for us throwing in the towel and pointing you to our documented emergency restoration procedure. It can be dealt with very easily, as long as you follow my instructions.

> Is there a way to update the Angie engine in it to be compatible with the above php and mysql conditions which the installed version of code has been updated for.

Yes, of course. It's solution #3. Remember what I called it? “Replace the restoration script”.

> In essence I'm hoping to just update angie and have it complete the recovery. Please advise if this can be done.

As I have already advised you it can be done by following the steps of the third solution in my previous reply.

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: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

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!

Summer vacations: Our support will be closed for replies and new tickets from August 6th to August 21st, 2022 due to summer vacations.