Just now, Dreadknux said:

There really needs to be a 'cancel upgrade' function on future updates here, because I got completely blindsided by this php upgrade thing and wouldn't have hit the upgrade button if I had known about this prior... now I'm stuck unless I roll back to a backup? Pretty inconvenient...

Absolutely. I'd never have done it if warned!

Just now, Dreadknux said:

There really needs to be a 'cancel upgrade' function on future updates here, because I got completely blindsided by this php upgrade thing and wouldn't have hit the upgrade button if I had known about this prior... now I'm stuck unless I roll back to a backup? Pretty inconvenient...

This is not something that is possible, as the files have already been overwrittten at that point in time. We would advise not to upgrade to newer versions of PHP as they are released, until we state we have provided support for those versions.

The quote button on mobile versions has moved down!

2 hours ago, Omri Amos said:

So to clarify, PHP 8.4 will basically "never" be supported? and PHP 8.5 support will come before PHP 8.4 support?

When will PHP 8.5 be supported?

I should have clarified, by saying we'll be supporting PHP 8.5, I was also implying PHP 8.4 support at the same time. It'll be later this year.

42 minutes ago, Barry Richmond said:

No warning about PHP level prior to system check...so I'm now stuck here and forums are down. I'm happy just to go back to the way it was until I get our host to upgrade first...can't find how to do that, can anyone help?

I've deployed an upgrade blocker for v4. Your AdminCP has told you for years that PHP 8.0 will not be supported in a future update. 8.0 and 8.1 are end-of-life and should be considered insecure.

@Stuart Silvester Perhaps changing the upgrade procedure slightly would prevent a lot of issues, both for clients, and the support. To give an example as someone who uses composer daily, if I try to update/upgrade something and requirements are not met, it won't proceed, and no changes will be made. It won't leave me mid way with broken things. I would expect this from any SW to be honest. In your process it seems the requirement check is at the wrong step of the process, once it's too late. Here's an example error message I triggered now:

> composer update

Loading composer repositories with package information
Updating dependencies

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Root composer.json requires php 8.3 (exact version match: 8.3, 8.3.0 or 8.3.0.0) but your php version (8.4.4) does not satisfy that requirement.

4 minutes ago, chivitli said:

@Stuart Silvester Perhaps changing the upgrade procedure slightly would prevent a lot of issues, both for clients, and the support. To give an example as someone who uses composer daily, if I try to update/upgrade something and requirements are not met, it won't proceed, and no changes will be made. It won't leave me mid way with broken things. I would expect this from any SW to be honest. In your process it seems the requirement check is at the wrong step of the process, once it's too late. Here's an example error message I triggered now:

> composer update

Loading composer repositories with package information
Updating dependencies

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Root composer.json requires php 8.3 (exact version match: 8.3, 8.3.0 or 8.3.0.0) but your php version (8.4.4) does not satisfy that requirement.

This is how it works now. The problem is that < 5.0.16 didn't have the concept of a maximum or supported versions. It would only check that you had a minimum of X version. As you've seen some comments here, those using 5.0.17 with PHP 8.4 are blocked from upgrading to 5.0.18 until they fix the version issue.

Umm... what's this all about? .18 with no announcement here?

4 minutes ago, My Sharona said:

Umm... what's this all about? .18 with no announcement here?

I went ahead with the upgrade regardless and encountered no issues. 👌

@Gary https://invisioncommunity.com/release-notes-v5/5018-r52/

5 minutes ago, My Sharona said:

Umm... what's this all about? .18 with no announcement here?

We've had quite a few bits going on, so its likely the announcement of that was simply overlooked. However I would say, you shouldn't rely on announcements for you upgrades. You should really be looking at the notices are you have screenshot, and ensure you are notified by your own instance if required.

2 minutes ago, Gary said:

I went ahead with the upgrade regardless and encountered no issues. 👌

It says that it has already been applied to Cloud customers. If that is so, then why am I seeing the update prompt with an option to upgrade?

1 minute ago, Marc said:

We've had quite a few bits going on, so its likely the announcement of that was simply overlooked. However I would say, you shouldn't rely on announcements for you upgrades. You should really be looking at the notices are you have screenshot, and ensure you are notified by your own instance if required.

See the above...

Edited April 10Apr 10 by My Sharona

5 minutes ago, My Sharona said:

It says that it has already been applied to Cloud customers. If that is so, then why am I seeing the update prompt with an option to upgrade?

It actually tells you on the update notice at the top

Cloud customers already have this update applied; you may need to run the upgrade process when you next visit your community.

It is actually a security update only, so there isnt actually much to post an announcement on really

Just now, Marc said:

It actually tells you on the update notice at the top

So... just because the update has been applied, that means it is not actually installed? It sounds like that is what you're saying here...

Just now, My Sharona said:

So... just because the update has been applied, that means it is not actually installed? It sounds like that is what you're saying here...

The upgrade is just in files. However the upgrader updates the number in the database too. Which is why you will see the notice. Run that through and it will get rid of the notice. Your site is however safe from that security issue

Just now, Marc said:

The upgrade is just in files. However the upgrader updates the number in the database too. Which is why you will see the notice. Run that through and it will get rid of the notice. Your site is however safe from that security issue

Okay so... The security aspect has been applied but the actual x.x.18 version has not? Apologies for being apparently dense this morning. Still working that first cuppa.

Edited April 10Apr 10 by My Sharona

Just now, My Sharona said:

Okay so.. The security aspect has been applied but the actual x.x.18 version has not? Apologies for being apparently dense this morning. Still working that first cuppa.

When you run an update it:

• Applies the files

• Applies any database changes that are made

• Updates the version number
  

In the case of this one, there arent any database changes. So the update itself weas applied, but you need to run the upgrader so the database knows

50 minutes ago, Stuart Silvester said:

This is how it works now. The problem is that < 5.0.16 didn't have the concept of a maximum or supported versions. It would only check that you had a minimum of X version. As you've seen some comments here, those using 5.0.17 with PHP 8.4 are blocked from upgrading to 5.0.18 until they fix the version issue.

That's great. May I suggest doing the same pattern for MySQL as well, because in requirements.json it looks like the PHP part was before this last update, so it wouldn't block 8+ versions? 9.7 LTS is coming out this month with vector support, and I guess there will be different people eager to update their servers, if they have different apps there. I am one of those people 😅 Not sure if anything would be broken in 9.7, but I guess you'll need to test in detail

"php": {
"deprecated": [ "8.1.0" ],
"supported": [ "8.1.0", "8.2.0", "8.3.0" ]
},
"mysql": {
"required": "8.0.13",
"recommended": "8.0.13"
}

Edited April 10Apr 10 by chivitli

3 minutes ago, chivitli said:

That's great. May I suggest doing the same pattern for MySQL as well, because in requirements.json it looks like the PHP part was before this last update? 9.7 LTS is coming out this month with vector support, and I guess there will be different people eager to update their servers, if they have different apps there. I am one of those people 😅 Not sure if anything would be broken in 9.7, but I guess you'll need to test in detail

"php": { "deprecated": [ "8.1.0" ], "supported": [ "8.1.0", "8.2.0", "8.3.0" ] }, "mysql": { "required": "8.0.13", "recommended": "8.0.13" }

Yes, I think we'll get to a point where we need to do that. A good example is MySQL 9.6, which removes (by default) the SHA1 and MD5 functions. However, we need to be smarter about it; an upper limit or specific supported versions would most likely block MariaDB versions (because they're so much higher). That would be problematic.

10 minutes ago, Marc said:

When you run an update it:

• Applies the files

• Applies any database changes that are made

• Updates the version number
  

In the case of this one, there arent any database changes. So the update itself weas applied, but you need to run the upgrader so the database knows

Okay, thank you for the explanation. I am glad to hear that the .18 (database files) update was not applied automatically by IPS. I know v5 is supposed to be quite a bit more stable from version to version but, I guess there is still a possibility of a version breaking something (customizations).

We've been running Invision Community v5 without an issue on PHP 8.4 for about a year now. I know it is not supported.

However with this new 'supported' version checks we ran in to issue not being able to upgrade. We bypassed it by switching temporary to PHP 8.3.

However the tasks are also failing if you use cron. If you comment out in applications/core/interface/task/task.php supported check it will work again.

Hopefully we get support soon for newer PHP versions as they improve performance a bit for websites.

Edited April 12Apr 12 by Joriz

Thankfully I tried this on a test server first. We've been happily on php 8.4.

Perhaps if the security notice led with a line on 8.4 no longer being supported, or ever as it turns out... That might of saved a few headaches. Now downgrading to 8.3.

It took me 3 attempts to upgrade to 5.0.18, the upgrade would just randomly stop. No errors, or anything. Also, the last two versions have seen part of the upgrade progress bar shrink and go out of the area.

I wished I had managed to get a screenshot, but that part progressed quicker.

I personally preferred when IPS products/features were offered as one solid block, not split among different tiers.

4 minutes ago, PatrickRQ said:

I personally preferred when IPS products/features were offered as one solid block, not split among different tiers.

That ship has sailed!

It is still unclear to me if I will get sadly surprised after upgrader from v4 to v5. My doubts are if I will find out any limits regarding features or possibilities. I prefer and I am partly forced to use self-hosted version. V4 gave freedom, is v5 still like this?