4 ms·

> Historically, backwards compatibility has been excellent and allows older apps to upgrade PHP versions and take advantage of performance improvements without

by dgb23 5y ago

> Historically, backwards compatibility has been excellent and allows older apps to upgrade PHP versions and take advantage of performance improvements without a rewrite. This has not been my experience at all. Updating PHP versions _and_ some even fundamental libraries has been very painful and anxiety inducing, you had to be very careful and patient. It's similar to JS in that regard and in some cases worse.

mjrpes 5y ago
Are you tracking warnings/deprecations in logs? Usually PHP gives ample warning time (at least one major version) before producing errors.
- ceejayoz 5y ago
  A good test suite does wonders, too.
  - dgb23 5y ago
    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.
    - pc86 5y ago
      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.
      - dgb23 5y ago
        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.
- dgb23 5y ago
  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.
sdoering 5y ago
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.
- yurishimo 5y ago
  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.
  - francislavoie 5y ago
    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.

by dgb23 5y ago

mjrpes 5y ago

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

ceejayoz 5y ago
A good test suite does wonders, too.
- dgb23 5y ago
  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.
  - pc86 5y ago
    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.
    - dgb23 5y ago
      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.
dgb23 5y ago
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.

sdoering 5y ago

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.

yurishimo 5y ago
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.
- francislavoie 5y ago
  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.