Just anecdata. My SO is currently working for a very small regional dairy producer (think 18 people total). Naturally they have a website no one really knows how to handle. My SO needed to update stuff, received the login info and the first thing we saw was WordPress stating that php5.6 is too old and should be updated.

After some arguing with the company that is payed to manage their IT environment she got them to finally update the php version and now the server is running 8.1.

I was glad that at least wp was up to date. Current wp running on quite old php version and exactly nothing broke with the update.

I was positively surprised. Would have expected more problems from my experience with other projects in other languages.

The WordPress core team does a great job of updating to support new PHP versions as soon as betas are released. Hell, in the most recent version, they even patched in some of the new PHP8.1 functions so they can be used before the official release.

We all know the tech is out of date at its core, but I don’t think it’s fair when people say they’re holding PHP back when there is an active effort to keep things compatible.

It's holding PHP back in the sense that because there's so many WordPress installations out there running on old versions of PHP and old versions of WordPress, that _will_ have to update at some point, it means that PHP internal devs need to always consider how any breaking change they make would affect those users.

In general, the WordPress community is _slow_ and plugin authors and users definitely do not keep up at the same pace at the rest of the community using more modern frameworks. They tend to have written worse code in general, which are proportionately more impacted by deprecations and error promotions where the code wasn't using best practices.

The PHP internals maintainers hear complaints from people in the WordPress space saying "whoa you're making too many breaking changes too fast, I can't keep up", meanwhile having the developers of modern frameworks getting impatient, wanting all the new features to save them time in writing new code.

If PHP didn't have all these legacy projects still in use, deprecations/strictness changes could move at a faster pace.

Are you tracking warnings/deprecations in logs? Usually PHP gives ample warning time (at least one major version) before producing errors.

I tracked the warnings and I keep up with changes out of necessity. But that's the least they can do - anything else would be insanity. However it does not make me feel any better when debugging version/compatibility/configuration issues between the language, different libraries and the environment.

I'm not saying there aren't good reasons for _some_ of the changes, including historical error prone baggage. I'm also not in any way try to disrespect the maintainers. But to say PHP is a stable language and ecosystem still does not reflect my experience with it.

A good test suite does wonders, too.

The tests are there to give us confidence about _our_ code. They can help in those situations, but they don't protect us from others pulling the rug from under us.

Unless you're upgrading production before lower environments, you'll still find out exactly what you need to fix, won't you? And unless you're waiting until the last possible moment to upgrade core infrastructure I don't see how anyone is getting any rug pulled out from anywhere.

Again, seeing what will be broken is the baseline expectation. My comment is not about that. It’s about breaking changes, having to resolve them, facing incompatible versions (language, libs, tooling).

You telling me you broke my code in advance doesn’t make it OK.