> 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.
