I'm curious to know why information regarding certain plugins was not checked before the upgrade began.  I have two applications that have now been 'locked' because of some PHP 8 incompatibilities.  My site is now completely crippled because the app that is locked is the mainstay of the site.  As it stands my site is now useless.  Had the below warning appeared prior to upgrade I would not have proceeded.

As mentioned in the message there, you need to contact the author of those items to correct the issue with the applications in question. This has been done in order to prevent your site from crashing entirely and being inoperable.

2 minutes ago, Marc Stridgen said:

As mentioned in the message there, you need to contact the author of those items to correct the issue with the applications in question. This has been done in order to prevent your site from crashing entirely and being inoperable.

is there a chance of a stand alone check script being made available ?

one that will check apps and plugins before committing to the upgrade?

Just now, Marc Stridgen said:

As mentioned in the message there, you need to contact the author of those items to correct the issue with the applications in question. This has been done in order to prevent your site from crashing entirely and being inoperable.

I've contacted the author, but my issue is not with something that needs to be corrected, rather it is that this information was provided 'after the upgrade' had that warning appeared prior then I would have contacted the author and waited for a solution before updating.  I'm now at the mercy of the app provided to discover the issue, correct it/them and provide and update to the marketplace where it will be queued for approval.  

I'm wondering how many apps will fall under this lock out as the apps are still available in the marketplace and they can still be installed from the ACP.  There should have been a warning prior to upgrade to prevent clients sites from being rendered inoperable.

Unfortunately not. If your site heavily relies on specific applications or plug-ins, I'd advise checking to see if 4.7 compatible versions exist before upgrading.

Hi @Matt 

I found out apps/plugins work on 4.7.1 but not on 4.7.2.

Regards,

Yes, it's quite frustrating but the PHP 8 upgrade is very destructive and what were harmless notices are now fatal errors.

We had to add quite robust checking and even disabling applications to prevent bricked upgrades. It's taken us a few revisions to get it completely accurate.

15 minutes ago, Matt said:

Unfortunately not. If your site heavily relies on specific applications or plug-ins, I'd advise checking to see if 4.7 compatible versions exist before upgrading.

That is the issue @Matt these apps 'are' 4.7 compatible and they are in the marketplace.  I've received a reply from the author who has provided replacement files and the support page now shows no errors at all, but the app is still locked.

 

 

 

Edited September 13, 20222 yr by Davyc

Just now, Davyc said:

I've received a reply from the author who has provided replacement files and the support page now shows no errors at all, but the app is still locked.

Have you rebuilt the cache?

Just now, Davyc said:

That is the issue @Matt these apps 'are' 4.7 compatible and they are in the marketplace.  I've received a reply from the author who has provided replacement files and the support page now shows no errors at all, but the app is still locked.

The way to unlock it is to upload a new version. As mentioned above, it's a bit of a frustrating time given PHP 8s drastic changes.

Just now, Matt said:

The way to unlock it is to upload a new version.

@Davyc, new version is already awaiting for review.

Just now, Adriano Faria said:

new version is already awaiting for review.

Thanks @Adriano Faria you are on the ball and even though you provided me with the two files that were causing the issue, the app remains locked.  So I will have to wait until the new version is approved.

To IPS I would say that you really need to inform people that some/all of their apps, even though they are Marketplace validated for 4.7 may cease to function because of these issues.  Some kind of pre-upgrade check should be made, rather than waiting until after the fact which then puts pressure on developers to update their apps and then get them into the Marketplace.  In this instance I would advise a more swift approval of affected apps so your clients sites are not rendered inoperable, which is an incredibly frustrating issue.

A pre-upgrade check wouldn't solve much as once you have the files up there, you either proceed, or you restore a back-up which is not a great choice either.

We are going to be working through the marketplace queue to ensure we can get as many apps as possible through the approval process.

 

Will I avoid this hassle as I'm still on 7.4?

But then after upgraded be able to run the check before upgrading to PHP 8?

No. It wouldnt matter what version of PHP you are currently on. The system will check that your applications/plugins are ready in preparation for our minimum version being PHP 8, and our recommended version currently being PHP 8

Not sure if you notified all the third party devs but if they had been they would not be scrambling at the last minute. In a perfect world, for such a major shift, you'd think that third party developers would have upgraded their apps BEFORE 4.7.2 was released.

Not looking for an answer or explanation inasmuch as what's done is done, but it would have been smoother.

There have been plenty of betas and a blog about the changes earlier in August. 

 

It should be noted that PHP 8 as a recommendation has actually been the case for some time also.

8 minutes ago, Marc Stridgen said:

It should be noted that PHP 8 as a recommendation has actually been the case for some time also.

I've been using PHP 8 ever since it was recommended and the apps that were locked out in the 4.7.2 update worked fine in 4.7.1 without issue.  Also as @Matt noted it was prudent to check if the apps were 4.7 compatible in the Marketplace, which they were and are still available to purchase and install on 4.7.2 however anyone doing so will find these apps do not work, at least not until they are updated.  So, the compatible with 4.7 flag is really no longer valid in, potentially, many instances.  There should be some kind of warning 'before' updating to ensure that apps people are using will actually work.

19 minutes ago, Dll said:

There have been plenty of betas and a blog about the changes earlier in August. 

 

Fair enough. This said, for a major shift, in a mission-critical situation, you check and double check that all are on board. This AM, I awoke to a great upgrade, yay. Launched, and before you know it, half of my apps are locked. All I'm saying is that, as a rule, and perhaps as a reflection of our view of the IPS - Dev relationship, this could have been handled better, that's all. Let's move on, but let's learn.

3 hours ago, Marc Stridgen said:

As mentioned in the message there, you need to contact the author of those items to correct the issue with the applications in question. This has been done in order to prevent your site from crashing entirely and being inoperable.

Isn't that too aggressive? The question is, is this a sure thing that doesn't work or maybe it works but the system is ignoring this possibility?

Because it would force administrators to look for an update that may not even be necessary yet if everything works normally.

18 minutes ago, Davyc said:

I've been using PHP 8 ever since it was recommended and the apps that were locked out in the 4.7.2 update worked fine in 4.7.1 without issue.

I have created a support ticket for you so we can look further into that app that was disabled

1 minute ago, Hisashi said:

Isn't that too aggressive? The question is, is this a sure thing that doesn't work or maybe it works but the system is ignoring this possibility?

Because it would force administrators to look for an update that may not even be necessary yet if everything works normally.

Unfortunately due to PHP 8+ changes it has to be this way. If you update and you have something that isn't compatible with the codebase, you will have a completely unusable site.

Just now, Stuart Silvester said:

I have created a support ticket for you so we can look further into that app that was disabled

I appreciate that Stuart, but the app has been updated and submitted to the marketplace for review.  What would have been good, would be available a reassessment by the system if new compatible files are uploaded, as in this instance the dev was on the ball and provided the two files that were causing the issue, but there was no way to get the system to recognise that these files which mitigated the lockout are now corrected.

3 minutes ago, Stuart Silvester said:

Unfortunately due to PHP 8+ changes it has to be this way. If you update and you have something that isn't compatible with the codebase, you will have a completely unusable site.

This is a completely acceptable and understandable viewpoint, but for the fact that there could have been a warning to check with the dev of any apps used to be sure that they were 4.7.2 compatible, not just 4.7 which of course they are in the marketplace.  So in my case, I can't speak for anyone else but I will hazard a guess there will be quite a few, the fact that this app was locked out made my site inoperable, the very thing the system was attempting avoid lol.

I can wait, it's annoying to say the least, as my site is just a hobby, but for someone running their site as a business this issue could cause a lot of damage, just saying 🙂

 

8 minutes ago, Stuart Silvester said:

Unfortunately due to PHP 8+ changes it has to be this way. If you update and you have something that isn't compatible with the codebase, you will have a completely unusable site.

Another question is... if self-hosted is still running PHP7.4, will it still run into this blocking?

6 minutes ago, Hisashi said:

Another question is... if self-hosted is still running PHP7.4, will it still run into this blocking?

Yes, because you can upgrade to PHP 8 after the upgrade and then have a bricked install. Given that PHP 7 is EOL and security support ends in November this year, I'd suspect most hosts will start planning their upgrades to PHP 8 very soon.

As mentioned above, PHP 8 have made things that used to send a hidden notice now throw a fatal error we cannot capture or adjust.