18 Comments

  1. Gary Taylor
    · Reply

    My question here would be: “Are we trying to build the best WordPress we can, or are we more concerned with powering 38% of the web?”

    Not all hosts provide updates to php (or MySQL – mine doesn’t, I’ll be leaving them at the end of the year) but I don’t think WordPress should be in the business of supporting hosts who haven’t updated for the last seven years because they don’t care. I guess I agree with Folmer; we should be driving on.

    Report

  2. Marcus Tibesar
    · Reply

    Kicking the can down the road folks…

    Report

  3. Bridget M Willard
    · Reply

    It is 100% the right call. There’s enough going on in the world right now not to mention the breaking changes in PHP8.

    Even Windows won’t be supporting PHP 8. I’m not sure how that affects WordPress — how many are on Windows Servers, but it’s an issue for sure.

    “We are not, however, going to be supporting PHP for Windows in any capacity for version 8.0 and beyond.” Dale Hirt, Service Engineer Microsoft

    https://externals.io/message/110907

    Report

  4. Stef
    · Reply

    I don’t get it. The 15% have had plenty of time to move up. Why are we focusing on waiting for them? Too bad.

    I’ve been upgrading over 300 client sites for awhile now. Totally disagree with this decision to put this on hold.

    Report

  5. mark k.
    · Reply

    Bridget, it is not about this call, it is about the trend. Each call by itself might be justified, the trend in which users are encouraged to use unsecure platfoms for years after the publically became unsecure is a different thing.

    As for PHP on windows, good job of getting things out of context. I am sure you didn’t intend too but that exactly what you have done. microsoft will not be releasing PHP for windows which is the same as linux not releasing PHP for linux, a fact that never prevented anyone to run wordpress on linux.

    Report

  6. Cavalary
    · Reply

    Those first two lines, the first one in particular, sure spell out a major part with what’s wrong with software development in recent years…
    Admittedly, as long as security updates continue to be provided for old versions, I do agree that it’s not really a problem, and those who specifically want the newest features should probably be expected to also stay reasonably up to date in other aspects as well. But that’d also require WP not pushing for major version updates in the manner it does either, so less savvy users won’t find themselves updating (or even automatically updated) to the newest WP without really meaning to.

    Report

  7. Sander van Dragt
    · Reply

    The core issue for me is not whatever PHP version WP supports. What has changed since the release plans? Where is the Make Core blog about this change? If nothing changed, why was there no action taken on this before the release plans were published?

    It’s a lack of comms / transparency, I think.

    Report

  8. Andreas Nurbo
    · Reply

    I don’t think WordPress should have a minimum PHP version that has reached end of life 2 years ago. WordPress says users should always update to latest version for security and so forth then WP it self should also update versions.
    We saw what not updating dependencies regarding jQuery led to.
    If people know that WP will always have a minimum PHP version support that is say 3 releases behind PHP latest then everyone knows what to expect and can plan for it. The current method is to random from the outside looking in.

    Report

  9. Rami
    · Reply

    When you look at the history, PHP 5.2 was the minimum requirement for 20 WordPress versions (3.2-5.1). PHP 5.6 is the minimum requirement only since WordPress 5.2 and it will stay for a while.

    http://displaywp.com/wordpress-minimum-php-version/

    Report

  10. Marcus Downing
    · Reply

    Why is the decision made on the fly each time?

    It seems the main argument for not upgrading is that hosts that haven’t upgraded yet – for whatever reason – will suffer, and so will their customers. This is only a real argument because the decision gets made so close to the release, so it would come suddenly.

    The way to do this is to publish a plan well in advance – say, six months – that says, “In WordPress 5.x, we will be dropping support for PHP 5.” Make sure everybody knows it’s coming and has time to move. You put this information in the Dashboard of successive WordPress versions, so everybody knows it. Then when you reach the day, you follow the plan as promised.

    Each time WP makes the decision not to do it right now, without instead saying when that day will be, it reinforces the idea that hosts don’t need to upgrade yet.

    Report

  11. Steven Gliebe
    · Reply

    Even PHP 7.1 has reached EOL. Last year! I think it’s time to “force” people to take a little more responsibility with their websites and hosting customers.

    Report

  12. Tim - Timdehoog.nl
    · Reply

    If WordPress, themes and plugins would only support the latest versions of PHP, let’s say the 7 serie. Then less rows of code are needed because all deprecated code can be removed. The codebase would decrease and code will be more stable and easier to maintain.

    Or am I seeing this wrong?

    Report

  13. Juliette Reinders Folmer
    · Reply

    The story continues. I’ve just published the next chapter: A proposal for WordPress to drop support for old PHP versions via a fixed, rolling schedule.

    Please leave comments on the proposal preferably on the proposal post, so nothing gets missed when this is next discussed.

    https://make.wordpress.org/core/2020/08/24/proposal-dropping-support-for-old-php-versions-via-a-fixed-schedule/

    Report

  14. KoolPal
    · Reply

    Sorry guys! As a Woocommerce Store owner, I find this entire exercise ridiculous.

    Site Health keeps displaying an annoying recommendation to upgrade to PHP 7.4. There are no controls in place to check if all plugins in WordPress repository are fixed to work with PHP 7.4

    Please understand that as Store Owners we would rather focus on our business than keep tinkering under the hood to just keep things working!

    And please do not be patronizing and tell us to hire a developer / some agency to do this for us.

    Thanks

    Report

    • wLc
      · Reply

      This wouldn’t be a problem if you had some type of load balanced setup. If you’re a serious e-store owner load balancing is a must.

      Report

  15. Damien
    · Reply

    Hey WP folks, I think there are a lot of important circumstances overlooked here when it comes to the talk of the wb hosts. I work at a small managed web host, catering to hundreds of non-profits and charities. I find the part at the end about forcing the web hosts to comply to be quite alarming! … as it’s not actually their fault or something they can fix most of the time!

    On the host side of the euqation, we have all moved on to PHP 7 long ago (2 Debian versions ago for us). Yet the majority of our older WP customers are stuck on PHP 5.6 because they haven’t the budget or the slightest understanding of what’s involved for a successful upgrade.

    The PHP upgrade notice dialog is totally unhelpful as it mischaracterizes the problem as a security issue (unless someone is compiling old PHP from upstream source, it’s not, PHP is running with backported fixes from a distro security team and is arguably more secure than when it ships from php.net in the first place).

    Anyway, about 90% of the time when a customer contacts us about the message and we go through the correct safe proces to update (see below) we discover that their site would have been broken if we had just changed the PHP version!

    So here’s the actual problem, what commonly breaks when you upgrade PHP 5.6 to PHP 7.1+ on a wordpress site is all the expensive stuff:

    Premium plugins that were purchased years ago and never updated regularly, these do not support PHP 7 coding standards and break horribly. This is hugely common.
    Solution: is to pay for each of these again and upgrade them ($ for plugins and $ for developer time to do the work, plus some kind of dev/stage environment if the developer can’t provide that themeslves)
    Problem: info on the correct solution, the cost, and competant dev help are a barrier to entry
    Custom code in theme or chld theme. Those snippets that finally worked that the old developer copied into functions.php from some stackoverflow answer 5 years ago? The code the part time student thrashed together that one summer for cheap? That code the marketing person made work that the support people gave them? These are the types of things that will be broken in PHP 7. They may spew warnings, or worst case cause fatal errors and dead pages, or prevent the site loading altogether.

    Solution: Debug the problem starting at the error_log entries and working back.

    Problem: barrier to entry finding developer: debugging old code is harder than writing new code, the work is beyond horrible and no one who isn’t desperate will touch it with a 99 foot pole, due to its complexity the work needs a more senior developer willing to do that awful work, these people are hard to find and expensive.

    Custom plugins. This indicates more serious development skills when first built, but when it comes to debugging problems that’s usually a curse and not a blessing. Now the problem of the above point is abstracted and confusing to reverse engineer, plus it likely relies on ancient / obselete / insecure frameworks or libraries that also need to be upgraded to modern versions in order to fix them (which then triggers a chain reaction of destruction throghout the rest of the dependencies). It can be cheaper to rewrite than to fix these, at the cost of a bunch of functionality. A painful sacrifice for the customer to make. Again, that is if someone is supporting them hand holds them through all this… otherwise they just ask their host to update PHP and often that’s a one way change they can’t undo and their site is wrecked, game over.

    Depending on the size of the site, and taking into account the work involved to successfully test and fix in an offline instance of the site, an organization can often be looking at thousands of dollars even if things go well.

    So! Let’s please not all get our burning torches and march down to the web hosts front door just yet… this isn’t their falut and it’s not their problem. Most of them could activate PHP 7 everywhere at the flip of a switch. They are more aware than most people about internet security and so they would love to be able to do so if it didn’t almost always completely destroy their customers sites (and thereby livelyhoods). So ironically except for bad ones (below) it’s the ones that give a crap about their customers who aren’t doing so automatically in a lot of cases. Forcing it on the users is the easy solution for the hosts but the results for users would be disastrous!

    And yes it’s true there is a lot of bad infra out there that is dangerously out of date and EOL, where it is the host that is the blocker! But often the host is not selling upgrades or support in those cases and it’s $5 hosting… Even more common than that is where someone back in the day had the bright idea to admin their own VPS without being a provessional (I wonder if they fix their own car and do their own plumbing and electrical too? things that make you go hmmmm!!??). This can be fixed or migrated away from but is more specialty help, then all the above points still apply.

    Anyway, what the wordpress developer community should be doing IMO is addressing this issue by educating users and connecting them up with developers (who must help with their part of the problem by fixing other random developres stinky obselete code). The end result of which, for our selfless heroes, will be a new ongoing wordpress maintenance & dev client….. because you are going to explain about maintenance and security updates to them and not let them get co-opted into a giant botnet right? :-)

    sincerely,
    a caring webhost who wants to get rid of PHP 5.6 even more than you!

    Report

Leave a Reply to Rarst Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: