The WordPress ecosystem is the one place we need this the most. Adding a plug-in to your wp instance is always a gamble because you know it's gonna break something else.
Kudos to the author for helping solve a real problem.
It depends on the plugin. Some of these methods are just helper functions for template rendering. Loose coupling isn't going to contribute a ton there, but not polluting the global namespace is important regardless of coupling.
There's more than one big problem with WordPress, and namespacing is one of them. It's way too common, even in some of the most popular plugins, to just toss plugins into the global namespace and prefix them with $your_plugin_abbrev_. I've had textbook cases of namespace collision take down sites on routine plugin updates before.
The core design of WordPress relies on global state, e.g. the $post global. I agree that that's a huge issue. Unfortunately, that will never be fixed, because it's so central to the design that "refactoring" the WP core not to use global state would break almost every plugin and every theme, and would be a fundamentally different system.
The fact that WordPress and other large projects still support PHP 5.* is one of the major things holding PHP back. Supporting PHP 5.* in 2018 is like supporting IE8 in 2018.
It's a classic chicken-and-egg problem. WordPress supports ancient versions of PHP because they want to be deployable on as many web hosts as possible, including ones that only provide ancient versions of PHP. And web hosts provide ancient versions of PHP because their customers (lots of which are WordPress users) don't demand they provide more recent ones.
It would be a huge help to the overall PHP ecosystem if WordPress started required PHP 7, as this would cut the knot and give those slow-moving Web hosts a reason to upgrade. But requiring PHP 7 would be a much smaller help to WordPress itself, as there's nothing in PHP 7 that WP really needs to do what it does, and dropping PHP 5 support would mean creating a non-trivial number of people for whom WordPress no longer "just works." (As the article notes, PHP 5.2 users only account for around 4% of the overall PHP audience, but the overall PHP audience is huge and 4% of "huge" still equals "a lot.")
So to a degree, asking WordPress to drop support for PHP 5 is asking them to take one for the team. It would be nice if they would, but I can understand why they wouldn't want to.
Moving to php7 would allow those web hosts to host more customers on the same machine, as php7 is faster with a lower memory footprint. Everyone would be better off, even the cheap web hosts.
I don't disagree that PHP 7 is much better in this regard than 5 is, and most clueful hosts have picked up on this and made the move.
The problem is that there are a lot of less-than-clueful web hosts out there. And if you're less than clueful, the economic rationale for the upgrade probably looks less compelling to you than the "if it ain't broke, don't fix it" rationale for staying with 5 does. (Not to mention that staying with 5 means you don't have to do anything, and less-than-cluefulness and laziness often hang out together.)
> "It's a classic chicken-and-egg problem. WordPress supports ancient versions of PHP because they want to be deployable on as many web hosts as possible, including ones that only provide ancient versions of PHP."
Is the extra 2% of market share worth it? Anyone reasonable would say "nope." Especially when it's handcuffs speed as well as sec.
So then - perhaps - it's about ego and other nonsense?
Put another way, WP has the power and position to lead, yet it chooses to __not__ act in the best interests of its users, hosting companies, and internet users in general. For what, 2% market share points?
WordPress and other large, popular projects got where they were by meeting their users where the users already are.
If I have to convince my webhost to install PHP 7 or I can't run your software, I'm not going to run your software. If I have to convince my webhost to install PHP 7 or I can't upgrade your software, I'm going to run the shitty old version until it gets hacked into a distribution site and the bandwidth use gets high enough for me to notice and turn the whole site off.
I'm not familiar enough with PHP these days to know, but if upgrading to PHP 7 is going to break the shitty old version, that's a problem too. (I think PHP has tended to be pretty good about not breaking things on upgrades though)
If I have to convince my webhost to install PHP 7...
It's a very long time since I used any sort of shared hosting, but do companies that use a single instance of PHP for multiple accounts still exist? I though they'd all moved to virtual servers with separate configs per account. Upgrading is a matter of changing a variable in cpanel somewhere.
Technology moves forward and there isn't a suggestion that older versions of wordpress stop existing, just that a new version should be cut on PHP7 so that sanity can creep in.
There were some BC breaks in PHP7 but most of them will only hit you if you're a terrible person, the easiest to demonstrate is that
> if upgrading to PHP 7 is going to break the shitty old version, that's a problem too
The problem is that PHP 7 finally removed some legacy APIs that had already been deprecated for an eternity. The removal wasn't a bad decision in and of itself, but there's a non-trivial amount of code in the wild that still uses those ancient APIs, either because it was written more than a decade ago before they were deprecated, or because it was written by people who either didn't understand what "deprecated" means or didn't care. So when that code moves from 5 to 7, it breaks.
WordPress core is developed by smart people who stay on top of changes in the language they work in, so moving to 7 wasn't a problem for WP itself. It was a problem for lots of WP themes and plugins, however, since there's lots of those that were written and then abandoned before 7 was a thing, and even some that were written by people who knew 7 was coming and just didn't understand why they should care.
If I were going to suggest one thing WordPress itself could do/have done to make the transition less rocky, it would be to require PHP 7 compatibility for plugins and themes distributed through the official repositories at wordpress.org. Currently that's not a requirement -- there's not even a way to filter out PHP 7 compatible plugins and themes from the ones that are stuck on 5. So unsophisticated users are still getting recommended software by those repositories that will break if you run it in a modern PHP environment.
(You can avoid this problem somewhat by looking for other heuristics that correlate well with PHP 7 compatibility -- actively updated plugins will tend to be compatible, well-reviewed plugins will tend to be compatible, etc. But you can't just ask directly for plugins that will work with PHP 7, which is a shame.)
I see it differently...If nearly 30% of the internet is running Product X and Host Y doesn't think it's a good idea to enter the 20th century, then Host Y should not be rewarded.
For all intents and purposes WP is rewarding bad behavior to the detriment of the rest of the internet (read: anyone who visits a WP-based site).
I'm genuinely happy for you that your work doesn't labor under the constraints that many, many (many) environments in the real world require.
But that doesn't mean those places/organizations/projects don't exist, even if you're unaware of them or don't think they're worthy of WordPress developers' efforts.
Using any version of PHP before PHP 5.6 is reckless from a security standpoint, let alone a language feature and performance standpoint. If you are on a version of PHP that old, you should make upgrading a very high priority.
You should inform the maintainers of CentOS, to take one example.
CentOS 6.9 (supported until November 2020) runs 5.3 with backported security and maintenance updates. Newer versions are not available from them for 6.9.
The issue is not that upgrading cannot or should not be done outside of their repos, but that many, many developers and site admins for various strong reasons are not in a position to do so. There may be other dependencies on either CentOS 6.9 or earlier-than-latest PHPs, or they may not have the freedom to switch distros or PHPs for any number of reasons.
Please consider the possibility that you do not understand the real world in which many, many developers work.
You're using a version of the php software that is not receiving security updates.
While CentOS might be supporting 6.9 until 2020, that doesn't mean Redhat is going to be performing security updates on PHP. Ubuntu obviously is updated a bit faster than CentOS, however you still need to use PPAs to receive the latest versions of PHP.
> many, many developers and site admins for various strong reasons are not in a position to do so.
I'm not convinced that this is a valid argument. If these versions of PHP were still supported, sure, but they are not and that is the real risk.
> Please consider the possibility that you do not understand the real world in which many, many developers work.
To be more specific, Red Hat is is backporting these security fixes into Red Hat Enterprise Linux (RHEL), and that's why (one reason why) RHEL costs money. People pay for RHEL when they want someone else to manage a distro for security and stability; this is one example of how Red Hat does that.
CentOS then gains the benefit of this work when Red Hat passes their changes downstream to CentOS.
The point is that many WordPress users don't know what PHP is, they got some cheap web space, put WordPress up and run it for their website/blog. The hosted doesn't really care either, they want to be cheap. Sure, old PHP is out of support upstream, but RHEL and others still backport patches and there are only very few remotely exploitable bugs in the recent past of PHP, thus risk of a breach due to PHP (contrary to a non-updated WordPress/Drupal/...) is relatively small.
The old PHP costs money. I know a company that realized that they could cut their operational costs significantly by upgrading PHP code from 2005 or so just because newer PHP is faster and they can get better utilization via microservices.
That is true if you control the software running in top of it. For a cheap hoster upgrading PHP means they can put more customers on a single server, but causes support cost by customers who's apps don't work anymore and where no developer is there to fix it.
You can be dominate and still hold the community back. Look at Internet Explorer. IE11 is the reason most people can't use ES2015+ features natively until the end of 2025.
31 comments
[ 2.9 ms ] story [ 52.5 ms ] threadKudos to the author for helping solve a real problem.
The problem is tight-coupling. Until that is addressed, plugins will always be little fail-bombs.
An actor model approach where one failure doesn't compromise the entire chain would help, but that is hard.
The core design of WordPress relies on global state, e.g. the $post global. I agree that that's a huge issue. Unfortunately, that will never be fixed, because it's so central to the design that "refactoring" the WP core not to use global state would break almost every plugin and every theme, and would be a fundamentally different system.
It would be a huge help to the overall PHP ecosystem if WordPress started required PHP 7, as this would cut the knot and give those slow-moving Web hosts a reason to upgrade. But requiring PHP 7 would be a much smaller help to WordPress itself, as there's nothing in PHP 7 that WP really needs to do what it does, and dropping PHP 5 support would mean creating a non-trivial number of people for whom WordPress no longer "just works." (As the article notes, PHP 5.2 users only account for around 4% of the overall PHP audience, but the overall PHP audience is huge and 4% of "huge" still equals "a lot.")
So to a degree, asking WordPress to drop support for PHP 5 is asking them to take one for the team. It would be nice if they would, but I can understand why they wouldn't want to.
The problem is that there are a lot of less-than-clueful web hosts out there. And if you're less than clueful, the economic rationale for the upgrade probably looks less compelling to you than the "if it ain't broke, don't fix it" rationale for staying with 5 does. (Not to mention that staying with 5 means you don't have to do anything, and less-than-cluefulness and laziness often hang out together.)
Is the extra 2% of market share worth it? Anyone reasonable would say "nope." Especially when it's handcuffs speed as well as sec.
So then - perhaps - it's about ego and other nonsense?
Put another way, WP has the power and position to lead, yet it chooses to __not__ act in the best interests of its users, hosting companies, and internet users in general. For what, 2% market share points?
If I have to convince my webhost to install PHP 7 or I can't run your software, I'm not going to run your software. If I have to convince my webhost to install PHP 7 or I can't upgrade your software, I'm going to run the shitty old version until it gets hacked into a distribution site and the bandwidth use gets high enough for me to notice and turn the whole site off.
I'm not familiar enough with PHP these days to know, but if upgrading to PHP 7 is going to break the shitty old version, that's a problem too. (I think PHP has tended to be pretty good about not breaking things on upgrades though)
It's a very long time since I used any sort of shared hosting, but do companies that use a single instance of PHP for multiple accounts still exist? I though they'd all moved to virtual servers with separate configs per account. Upgrading is a matter of changing a variable in cpanel somewhere.
There were some BC breaks in PHP7 but most of them will only hit you if you're a terrible person, the easiest to demonstrate is that
list($a[], $a[]) = [2, 3];
Went from $a being [3, 2] to [2, 3] in PHP7.
The problem is that PHP 7 finally removed some legacy APIs that had already been deprecated for an eternity. The removal wasn't a bad decision in and of itself, but there's a non-trivial amount of code in the wild that still uses those ancient APIs, either because it was written more than a decade ago before they were deprecated, or because it was written by people who either didn't understand what "deprecated" means or didn't care. So when that code moves from 5 to 7, it breaks.
WordPress core is developed by smart people who stay on top of changes in the language they work in, so moving to 7 wasn't a problem for WP itself. It was a problem for lots of WP themes and plugins, however, since there's lots of those that were written and then abandoned before 7 was a thing, and even some that were written by people who knew 7 was coming and just didn't understand why they should care.
If I were going to suggest one thing WordPress itself could do/have done to make the transition less rocky, it would be to require PHP 7 compatibility for plugins and themes distributed through the official repositories at wordpress.org. Currently that's not a requirement -- there's not even a way to filter out PHP 7 compatible plugins and themes from the ones that are stuck on 5. So unsophisticated users are still getting recommended software by those repositories that will break if you run it in a modern PHP environment.
(You can avoid this problem somewhat by looking for other heuristics that correlate well with PHP 7 compatibility -- actively updated plugins will tend to be compatible, well-reviewed plugins will tend to be compatible, etc. But you can't just ask directly for plugins that will work with PHP 7, which is a shame.)
For all intents and purposes WP is rewarding bad behavior to the detriment of the rest of the internet (read: anyone who visits a WP-based site).
But that doesn't mean those places/organizations/projects don't exist, even if you're unaware of them or don't think they're worthy of WordPress developers' efforts.
Edit - downmodders, please see: http://php.net/supported-versions.php
CentOS 6.9 (supported until November 2020) runs 5.3 with backported security and maintenance updates. Newer versions are not available from them for 6.9.
The issue is not that upgrading cannot or should not be done outside of their repos, but that many, many developers and site admins for various strong reasons are not in a position to do so. There may be other dependencies on either CentOS 6.9 or earlier-than-latest PHPs, or they may not have the freedom to switch distros or PHPs for any number of reasons.
Please consider the possibility that you do not understand the real world in which many, many developers work.
While CentOS might be supporting 6.9 until 2020, that doesn't mean Redhat is going to be performing security updates on PHP. Ubuntu obviously is updated a bit faster than CentOS, however you still need to use PPAs to receive the latest versions of PHP.
> many, many developers and site admins for various strong reasons are not in a position to do so.
I'm not convinced that this is a valid argument. If these versions of PHP were still supported, sure, but they are not and that is the real risk.
> Please consider the possibility that you do not understand the real world in which many, many developers work.
This is stand-offish and rude.
That is actually exactly what it means. RedHat backports security fixes to 5.3 in order to support it, even though 5.3 is not fixed upstream in PHP
https://access.redhat.com/security/updates/backporting
CentOS then gains the benefit of this work when Red Hat passes their changes downstream to CentOS.
Your example is a tool holding making the community. However, the original statement was about how a tool was holding back another tool.