chivitli

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" }

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

Not that I'm affected (yet), but I find the answer to people with broken forums on PHP 8.4 quite unsatisfying for a paid product. If you look at your own checker at https://invisioncommunity.com/files/file/7046-invision-community-requirements-checker/ and linked from https://invisioncommunity.com/buy/self-hosted/ you will see on the screenshot that version 8.4.3 is highlighted as valid. You also said "Rather than stating we support over x version, we now explicitly state which versions we support". This situation is really not fault of the client then, because Invision broke for them something that was working when you "unsupported" newer PHP. Even though what you tried is understandable, it's still a major regression. Any chance priority can be put on the recent PHP support going forward? I mean PHP 8.4 was released 1.5 year ago! I know cloud customers are unaffected, and us in self-hosted are a bit third-tier client, but still... Once you deal with implicitly nullable params, which could be practically automated to fix, the rest of the PHP upgrade issues should hopefully be even easier 😅