WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 7 weeks ago

#33381 assigned enhancement

Strategize the updating of minimum PHP version.

Reported by: alexander.rohmann Owned by: jorbin
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: General Keywords: needs-codex dev-feedback 2nd-opinion
Focuses: Cc:

Description

I'd like to formally petition for the drafting of a strategy and timeline of when WordPress might be updated to a supported minimum PHP version.

This is something that's been discussed to death in the community, but little concrete information or answers seem to be available. I couldn't find a trac ticket, so my apologies if this is a duplicate.

It is my view that:

  1. PHP EOL should not be open to interpretation.
  2. While other parties may continue to provide LTS for EOL PHP versions, this does not make it the responsibility of WordPress. We depend on PHP itself, not a hybrid or undead version of it.
  3. WordPress should move towards an official statement that a supported version of PHP is a requirement. (As in it must be on this page: http://php.net/supported-versions.php)
  4. Failing to comply with PHP EOL is a disrespect to the fine folks making PHP who are working hard to release updates in a manner that is sustainable longterm for everyone.

Hopefully, we can all agree that this is just a matter of "when" and not "if". I'd really like to see that "when" put on the calendar. I'd imagine it would be years down the road, but at least we can have that to look forward to.

I know that we're still waiting for version numbers to decrease. By now I'd argue that no change will happen until WordPress necessitates it. Considering how far past EOL we've become, is that not reasonable?

Thanks.

Change History (136)

#1 @miqrogroove
2 years ago

PHP 5.3.19 minimum is on my wishlist. PHP upgrade does get a lot of community enthusiasm, but we are ultimately limited by the share of versions out in the wild, installed by hosting companies.

Last edited 2 years ago by miqrogroove (previous) (diff)

#2 @alexander.rohmann
2 years ago

Instead of picking an arbitrary version, I'm proposing that we simply set a date for committing to PHP supported versions only (http://php.net/supported-versions.php) from that day onwards.

#3 @chriscct7
2 years ago

A calendar deadline probably isn't reasonable. If an arbitrary date is picked, and the date comes and the % of users on each PHP version remains the same, then a new date would be set.

I know that we're still waiting for version numbers to decrease. Considering how far past EOL we've become, is that not reasonable?

Not at all unfortunately: from a % users perspective, if WordPress updated to a minimum requirement of 5.4 tomorrow, almost half of WordPress installs wouldn't be able to operate on it. To have a minimum requirement of EOL/supported versions, would mean that in 30 days, the minimum requirement would be 5.5, which would mean over half of WordPress installs (and 12.5% of the internet) would not be able to operate on it.

Last edited 2 years ago by chriscct7 (previous) (diff)

#4 @alexander.rohmann
2 years ago

The whole point of picking a date is to incentivize people to update. The outdated PHP installs would only break if people decided to update WordPress.

If not an exact date, it could be tied to a major release. This would easily be solved by:

  1. Announcing (tomorrow/soon) that WP 4.5 will only support active PHP.
  2. Diverting Automatic updates to the 4.4.X branch for security fixes only if EOL PHP is detected.

Then a hard date perhaps 2-3 years out could be set for the discontinuation of those security updates.


Last edited 2 years ago by alexander.rohmann (previous) (diff)

#5 @stracker.phil
2 years ago

Totally agree with alexander.rohmann!

Since people are using a seriously deprecated PHP version, which alone opens major security issues, I see it as a community responsibility that we have to push people to update to a newer version that is actively maintained.

So If people want to use an deprecated PHP version, they might as well stick with an deprecated version of WordPress, but not get any of the new features of newer releases.

We tell people to harden their website by upgrading WordPress here:
http://codex.wordpress.org/Hardening_WordPress
But when I take a look at known vulnerabilities in PHP I'm afraid that updating only WP is not enough. Updating PHP is also a requirement to keep a site secure:
http://www.cvedetails.com/vulnerability-list/vendor_id-74/product_id-128/PHP-PHP.html

#7 @jdgrimes
2 years ago

For posterity: This ticket was forked from #23880.

  • I tend to agree with @alexander.rohmann and @stracker.phil. I think we should work toward one day only supporting active PHP versions.
  • But we have to keep in mind that isn't as simple as telling a user "upgrade your PHP!". It's hosts we're dealing with, not WordPress site admins. Users don't know how to update their PHP, so it comes down to hosts forcing an update on them, which is a sticky situation.
  • I'd advocate that we aim to accomplish that by the EOL of PHP 5.6, which is 2 years away. That should give plenty of time for hosts to upgrade, or have some kind of plan in place if they don't.

#9 in reply to: ↑ 8 @jdgrimes
2 years ago

Replying to knutsp:

A debate on this from 2014: http://planetozh.com/blog/2014/01/why-wordpress-should-drop-php-5-2/

Quoting @nacin from there:

WordPress does work with hosts to get PHP updated. We keep a pretty close eye on defaults and offerings, and even see how much the numbers move when a big host makes a large shift. We casually survey them to see what their reasons are for updating. The difference is we're not going to put users in the middle of all of this political melee.

And for as long as PHP upstream shows a lack of respect for shared hosting situations, dropping security support for PHP 5.2 while it was still powering a vast majority of websites, dropping security support for PHP 5.3 while it (and 5.2) are a vast majority of websites, it's really not in our best interest to "play along" at the expense of our users. Tens of millions of users would be affected — and potentially stranded, or certainly wondering why WordPress is putting them in the middle of all of this — all because reasons. It's completely silly. [...]

I applaud the WordPress project leaders for not bringing the users into this. It could easily turn into an all-out food fight among the users, the WordPress community, the hosts, the PHP devs, etc. I agree that we should continue to protect our users from all of this. But at the same time, we're all impatient, and I guess we just wish that there was more that could be done to speed up the process. My biggest fear is that everyone is just kicking the can down the road, and that in ten years we'll be sitting here having the same discussion about PHP 5.6 (or 5.5, or 5.4, God forbid). I don't think we need to start playing a blame game, but I'd like to know what can be done, and what is actually being done, to make PHP version transitions easier in the future? At some point somebody has to say, "You know what, this is really broken and here's what we're going to do to fix it in the future." I realize that isn't something that falls on WordPress, but we feel more pain from it than anyone else (although the hosts' pangs are more severe ;-).

#10 follow-up: @alexander.rohmann
2 years ago

@jdgrimes, Agreed. For the most part I don't care how long the process takes, my fear is that there isn't a process at all.

If you consider the practice: "if it aint broke dont fix it"

For Hosts: I don't blame them. Nothing is broken, things are still working, so why change anything?

For WordPress: Developing on unsupported software? Now that is broken. Nobody is saying the fix has to be a sweeping breaking change, but why can't we come up with a creative solution?

WordPress changing it's requirements is the only thing that will necessitate the change needed for hosts. We can sympathize with hosts all day long, but we're really just coddling them, and enabling their lethargicness.

I understand our responsibility to users, but WordPress can not be held accountable for the shortcomings of hosts who refuse to update. There is every right, reason, and explanation to tell users that they can't update to the latest WordPress because in all honestly their hosting provider is years behind technological evolution. Wake up people.

Desiring to be all things to all people is the shortest road to stagnation.

#11 follow-up: @stracker.phil
2 years ago

@jdgrimes, actually I don't really agree with the statement that we need to deal with the site-hosts and not the site-admins here. If a site-admin knows that his WordPress updates will stop in 36 months from now he will have the means to (a) ensure that the PHP version gets updated in time or (b) just be cool about his site getting no more updates.

After all the site-admins are the people we can reach and talk to directly. We can make them understand the situation and guide them to contact their hosts.

I imagine this could be realized by adding a new message on the Updates page (and maybe also in the main Dashboard):
A) "Your website is ready for WordPress 5.0 (read more here)"
B) "Warning: Your website is not ready for WordPress 5.0! Please read the details here to make sure your automatic upgrades will work in the future"

And note that this change in requirements does NOT mean that we break peoples websites if they don't upgrade PHP in time. It just means that they will not get new upgrades via the built in update function while PHP version is too low.

#12 @alexander.rohmann
2 years ago

@stracker.phil exactly! And as I mentioned above, WordPress could still provide security updates to those users in an LTS fashion by providing minor releases on the last branch supporting PHP EOL.

#13 in reply to: ↑ 11 @jdgrimes
2 years ago

Replying to stracker.phil:

@jdgrimes, actually I don't really agree with the statement that we need to deal with the site-hosts and not the site-admins here. If a site-admin knows that his WordPress updates will stop in 36 months from now he will have the means to (a) ensure that the PHP version gets updated in time or (b) just be cool about his site getting no more updates.

I think the concern of the core leads is that most users have no idea what PHP is, much less how to get it updated.

After all the site-admins are the people we can reach and talk to directly. We can make them understand the situation and guide them to contact their hosts.

It's true that we naturally have a more direct line of communication with site admins. However, as you imply, they can't actually solve the situation. For the most part, our communication would be to tell them "ask your host to do this thing that you don't understand because reasons." We'd really just be co-opting them as middle men. And I think that's just going to make them frustrated with WordPress or their host, most probably both.

I imagine this could be realized by adding a new message on the Updates page (and maybe also in the main Dashboard):
A) "Your website is ready for WordPress 5.0 (read more here)"
B) "Warning: Your website is not ready for WordPress 5.0! Please read the details here to make sure your automatic upgrades will work in the future"

I agree that there will probably be a point where we'll do something like this. But I'm beginning to see the wisdom of the core leads in not wanting to do it yet. It's really a drastic measure, and one that will really shake people up (some of whom are antagonistic toward some decisions in the WordPress community anyway). Even just a few percent of sites is millions of site-admins. Nobody wants millions of site admins breathing down their backs. Even if every one of them is very understanding and kind, the support load would be enormous, both for the WordPress community and the hosts. Which is why I think it is unfair to both the hosts and the site admins not to seek to open lines of communication to the hosts instead.

And note that this change in requirements does NOT mean that we break peoples websites if they don't upgrade PHP in time. It just means that they will not get new upgrades via the built in update function while PHP version is too low.

Right, and we can be much more comfortable about doing this when the time comes now that we can continue to offer automatic security updates.


My Proposal:

  1. Identify the hosts that are running the sites on outdated versions of PHP.
  2. Open dialog about this with them.
  3. State explicitly what our strategy for supported PHP versions is.
  4. Let them help us choose a date as a goal for implementing that strategy.
  5. Work toward implementing that strategy, and hopefully meeting our goal. Yay!

I think no. 1 and no. 2 are already being done. The hangup seems to be on no. 3, because, as far as I know, there is no simple strategy laid out in plain terms. It's always, "when the number of sites is lower." And I understand why the core leads might like to remain non-committal, but the purpose of this ticket is to try and put something together that is a little bit more concrete.

#14 @alexander.rohmann
2 years ago

The hangup seems to be on no. 3, because, as far as I know, there is no simple strategy laid out in plain terms. It's always, "when the number of sites is lower." And I understand why the core leads might like to remain non-committal, but the purpose of this ticket is to try and put something together that is a little bit more concrete.

That'd be a great start and would help some of us feel at ease about it.

Not a fan of point 4. It's just too etherial. We could ask "How long do you need?" and use that to get an idea, but it's going to take someone to just make a decision and pick a date (or release cycle). Otherwise we'll be having the same conversations again year after year.

It sounds like we've been extending an offer to a seat at the decision making table to hosts for quite some time. That door needs to close at some point. Fish or cut bait.

Last edited 2 years ago by alexander.rohmann (previous) (diff)

#15 in reply to: ↑ 10 @jdgrimes
2 years ago

Replying to alexander.rohmann:

WordPress changing it's requirements is the only thing that will necessitate the change needed for hosts. We can sympathize with hosts all day long, but we're really just coddling them, and enabling their lethargicness.

I understand our responsibility to users, but WordPress can not be held accountable for the shortcomings of hosts who refuse to update. There is every right, reason, and explanation to tell users that they can't update to the latest WordPress because in all honestly their hosting provider is years behind technological evolution. Wake up people.

In fairness to the hosts, I think it should be noted that often the reason that they aren't updating is in the interests of the users, too. I think it should be clarified that the problem isn't that hosts aren't offering modern versions of PHP, it is that many sites are just still running on the older versions that the hosts are still maintaining. The hosts will actually have to force users to update the PHP versions they are running. That can be a real pain, and the problem is that often a user's site isn't just running WordPress, it is running some other obscure script that is not compatible with modern PHP. So it is a big load on support each time hosts have to do this. In other words, (and I think we agree on this) it takes time. I'm not saying the hosts shouldn't be more proactive, I just wanted all of that to be clear.

I agree with you that at some point we'll just have to leave some hosts (and users) behind. But in deference to our users, I think we should try a little harder to motivate the hosts ourselves without getting the site admins involved in this mess more than is necessary. I think that getting the hosts to work with the WordPress community in setting a goal that they can aim for will help to motivate them to do this more quickly. But we have to actually set a realistic goal and then stop coddling hosts that miss it. I completely agree there.

#16 @alexander.rohmann
2 years ago

Yes, so whatever strategy is decided upon could take years. At least we would know what's going on and have measurable forward progress instead of this "wait and see" business.

#17 follow-up: @stracker.phil
2 years ago

The hosts will actually have to force users to update the PHP versions they are running

Well, actually we clarified above that most users cannot update PHP because it's up to the host ;)

My host for example swiches my PHP version automatically once a year; I can downgrade to 1 previous version for a limited time. That's a good strategy in my eyes.

I don't like to ackowledge the point, that users do not know what PHP is and should not be confronted with it. If they run a website they should be literate enough to understand - or if they really don't know then they usually did not set up the site alone and have a web developer who maintains their website and knows about this stuff.
After all setting up a WordPress site is not like making a phone call; it's something that needs a little bit of expertise and commitment.

You need to take your car to maintenance once a year (I have no idea how my car works), we need to go to health-checks regulary (I have no idea how my bod/the medication works), when the fridge is broken you call a technican, and so on... you get my point, right? it's: When PHP is needs an update you email your host ;)

Besides that opinion I'll instantly sign your 5-step proposal!
For point 4: Let's suggest a date and see if they comply? "We want to get this done until Jan 2017. You will get a last reminder 6 months before we switch so you have plenty of time to react or get in touch with us in case this does not work for you"

#18 follow-up: @stracker.phil
2 years ago

Also, if you compare the numbers in the current stats here: https://wordpress.org/about/stats/

You might notice: 14% of sites use PHP 5.2 and at the same time around 16% use WP 3.7 or earlier (which was released 2013)
So my impression is, that people with PHP 5.2 are the people that do not even update WP to current version.
Just an impression by looking at those charts...

#19 in reply to: ↑ 18 ; follow-up: @jdgrimes
2 years ago

Replying to stracker.phil:

Also, if you compare the numbers in the current stats here: https://wordpress.org/about/stats/

You might notice: 14% of sites use PHP 5.2 and at the same time around 16% use WP 3.7 or earlier (which was released 2013)
So my impression is, that people with PHP 5.2 are the people that do not even update WP to current version.
Just an impression by looking at those charts...

Those who have access to the data have said before that the PHP usage for the latest version of WordPress isn't significantly different than the totals across all WordPress versions. But it is possible that this is changing, and it would be nice if we could see the stats (it's been requested many times).

#20 in reply to: ↑ 17 @jdgrimes
2 years ago

Replying to stracker.phil:

The hosts will actually have to force users to update the PHP versions they are running

Well, actually we clarified above that most users cannot update PHP because it's up to the host ;)

My host for example swiches my PHP version automatically once a year; I can downgrade to 1 previous version for a limited time. That's a good strategy in my eyes.

I don't like to ackowledge the point, that users do not know what PHP is and should not be confronted with it. If they run a website they should be literate enough to understand - or if they really don't know then they usually did not set up the site alone and have a web developer who maintains their website and knows about this stuff.
After all setting up a WordPress site is not like making a phone call; it's something that needs a little bit of expertise and commitment.

You need to take your car to maintenance once a year (I have no idea how my car works), we need to go to health-checks regulary (I have no idea how my bod/the medication works), when the fridge is broken you call a technican, and so on... you get my point, right? it's: When PHP is needs an update you email your host ;)

I think these are valid arguments. I think maybe it comes down to the difference between what a user probably should know, and what they actually do know. I really can't say that I have any experience there, so I'll let those who do respond. Maybe @ipstenu or others who are on the support forums a lot would have some idea of how an average user would respond to a notice about outdated PHP.

Besides that opinion I'll instantly sign your 5-step proposal!
For point 4: Let's suggest a date and see if they comply? "We want to get this done until Jan 2017. You will get a last reminder 6 months before we switch so you have plenty of time to react or get in touch with us in case this does not work for you"

Yeah, something like that would be good.

#21 in reply to: ↑ 19 @jdgrimes
2 years ago

Replying to jdgrimes:

Those who have access to the data have said before that the PHP usage for the latest version of WordPress isn't significantly different than the totals across all WordPress versions.

I've found a link to this: http://wordpress-hackers.1065353.n5.nabble.com/php-v-td42729.html#d1383867550000-120

It's part of a debate on this topic that took place on the wp-hackers mailing list in November 2013.

#22 follow-up: @markoheijnen
2 years ago

To me this is a users problem on the first place but that's to easy to say. If you say hosts should update then there is a problem since most hosts are already supporting 5.6 or 5.5. They simply can't just kill old versions as @jdgrimes said in one of his comments. Hosts also play the long game like WordPress does for the exact same reason: No breakage for their users.
So it's up to the user to update the PHP version of their account or sites (depending how the host work). The big problem then is to make them understand why and how they can do the update themselves. When then the percentage of for example PHP 5.2 drops then it's easier for hosts and WordPress to kill it.

What WordPress can and must do is to to scan the plugin/theme directories for plugins using things that will break when running PHP 5.5 and later. So they can show to the outside that nothing can break when moving to the latest PHP version. I already have seen enough breakage that this can become a serious issue.

Setting the date is something that needs to be done together with host. WordPress isn't really a big party in this. People can believe that WordPress can push them but they can't. They can use https://wordpress.org/hosting/ to push ("blackmail") hosts but that only work for a few of them. Weirdly to say but WordPress is to small for it. If there is a good way for hosts to tackle their increase in support (fixing sites) then making the push will become easier. Depending on the host this can be really tricky since you probably do need some development skills.

This all said, I'm more then happy to work with the hosts in Europe on this and other systems out there to see how we can all combine our power to make the push.

#23 @alexander.rohmann
2 years ago

What WordPress can and must do is to to scan the plugin/theme directories for plugins using things that will break when running PHP 5.5 and later. So they can show to the outside that nothing can break when moving to the latest PHP version. I already have seen enough breakage that this can become a serious issue.

Great point. I agree that would be an important step on the WordPress side.

Setting the date is something that needs to be done together with host. WordPress isn't really a big party in this. People can believe that WordPress can push them but they can't. They can use https://wordpress.org/hosting/ to push ("blackmail") hosts but that only work for a few of them. Weirdly to say but WordPress is to small for it. If there is a good way for hosts to tackle their increase in support (fixing sites) then making the push will become easier. Depending on the host this can be really tricky since you probably do need some development skills.

My fear is that there are so many parties involved with nothing to gain that no consensus will be made. I don't see how it's unfair or blackmail if: 1. They have irresponsibly allowed their systems to decay (in terms of staying on one version). 2. We're talking about an extended timeframe.

Last edited 2 years ago by alexander.rohmann (previous) (diff)

This ticket was mentioned in Slack in #core-passwords by peterwilsoncc. View the logs.


2 years ago

#25 @rmccue
2 years ago

  • Keywords close added

This has been discussed to death, and I don't think we're going to make any further movement on this. The core team's position is pretty clear, and hasn't changed.

Recommend close.

#26 @alexander.rohmann
2 years ago

It's definitely been discussed to death, but wouldn't say anything has been made clear.

#27 @juliobox
2 years ago

Discussed to death? Wars have claimed lives, yet there are still wars.
Let us talk about that, again
Thank you, Charlie.

#28 @Monarobase
2 years ago

Hello, we are a webhost and we defenetly would like old versions of PHP to be depreciated in WordPress.

The days when it was complicated to upgrade PHP are over (for most webhosts anyway). With new PHP versions comming out faster these last few years, webhosts have had to adapt and offer multiple versions of PHP to their customers.

The most used control panel (cPanel) will soon let all users choose their own PHP version. We already allow users to do this with CloudLinux PHPSelector.

All the tools are there for webhosts to allow users to choose their own PHP version.

Even webhosts who don't have the required PHP version on a client's webserver, should be able to move their customer to a more recent server on demand.

Most webhosts now want their users to have the most recent version possible, not only for security reasons but also because more recent versions of PHP use less CPU and memory.

It's difficult for a webhost to enforce a PHP version change, so we only advise users to do it. If WordPress also advised users to change their PHP version it would help encourage users to have a more up to date version of PHP.

#29 @juliobox
2 years ago

https://wordpress.slack.com/archives/core-passwords/p1439624644000007

georgestephanis said: Unit tests of this branch is failing since PHP 5.2 doesn't support namespace. Should I edit includes/Yubico/U2F.php? (Or say goodbye to PHP 5.2?:grin:)


This is why we need to talk about a PHP bump, because we/you are talking about adding 2 auth into the core.
Talking about adding security and ignoring the fact that 5.2 is not supported anymore even for security releases is kind of weird.

#30 follow-ups: @pento
2 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed
  • Version trunk deleted

I don't really want to have this argument again, but I just can't help myself. ¯\_(ツ)_/¯

So, here's the deal. WordPress is committed to backwards compatibility, because dealing with compatibility breaking changes is not something a user should ever have to do. This is a fundamental rule of the WordPress project. We tried setting a date years ago, back when we dropped PHP 4 support. All it resulted in was people's sites being broken, it didn't hurry the transition to PHP 5.

There's nothing in PHP 5.3 or later that's particularly useful in WordPress Core, so it's not like we need to force an upgrade for a language feature. Hosts that I've spoken to aren't using vanilla PHP 5.2 for their sites that are still on it, anyway - they have custom builds with security patches back ported. If you're a host using vanilla PHP 5.2 when security patches are so readily available, you probably want to give all of your customers their money back, along with a heartfelt apology, then close your doors forever.

This year, we've been speaking to several major hosts about updating their PHP versions - in the last three months alone, this has resulted in about a million sites being upgraded from PHP 5.2 and 5.3, to 5.5 and 5.6. Setting a hard deadline won't improve this rate, because it's not a thing that can be improved through threats.

If this upgrade rate keeps up, we might be able to drop PHP 5.2 by the end of the year. Or maybe not, because we're not in the business of breaking millions of sites on a whim.

tl;dr:

  • There is no deadline, there won't be a deadline.
  • We're not going to put users in the middle of this, so don't even ask.
  • Progress is being made. It will continue to be made, but throwing out arbitrary dates won't make it happen faster.

PS: I know status wars are exciting, but please don't re-open this. You can continue discussion, of course, but anyone re-opening it will have their comments deleted.

#31 @markoheijnen
2 years ago

First of all, this response surprise me. You are treating everyone in this thread to not reopen this ticket by deleting comments. This is really disrespectful to people who are helping this project.

I have worked at one of the bigger host and I have never seen WordPress contacting them to update their PHP version or the PHP version of all the sites running on it. Personally I was responsible for migrating 100k WordPress sites to PHP 5.5 and the team I was working with for the other projects the host is providing. That could have changed in the last couple of months but I guess not.

A deadline isn't a threat. Not setting a date and let's say during WordPress 4.4 we decided to bump the PHP version is.

WordPress should act like a market leader and make it more obvious what they are doing to decrease old PHP versions. To me the progress now is being made by the users and their hosts.

#32 @GregRoss
2 years ago

Perhaps a different approach would be to create an admin notice when an old PHP version is detected and then throw out a "We see your running a really old version of PHP, have you thought about upgrading? Your hosting provider can help with that!".

This would encourage end users to upgrade without breaking anything, which would help with the number of sites using old PHP versions. That would in turn speed up the process of being able to deprecate support for them in WordPress.

Not taking advantage of the power end users have to make changes at hosting providers seems like a wasted opportunity.

A while ago one of the libraries that a plugin I wrote bumped it's requirements to PHP 5.3 and so I had to do the same with the plug. Since then I have had a few tickets about the PHP version, but almost all of them were quickly resolved when the user simply selected the newer version of PHP from their hosting control panel.

#33 in reply to: ↑ 30 @jdgrimes
2 years ago

Replying to pento:

We tried setting a date years ago, back when we dropped PHP 4 support. All it resulted in was people's sites being broken, it didn't hurry the transition to PHP 5.

Thank you for this bit of history, I did not know that.

However, this ticket isn't really about picking a date. That's something we'd like to see, but at a higher level, we're wanting some kind, any kind, of concrete strategy for this.

This gets discussed over and over and over again. And the core leads usually jump in at some point and explain why the required version won't be updated yet. But the question is never really settled, because we're always left wondering, "So, when?"

I understand if you don't want to answer that with a hard date. But, to avoid endless wrangling about this in the future, could we please try to piece something together that is less fuzzy?

WordPress will always have a minimum required version of PHP. A comprehensive explanation of the philosophy behind that needs to be hashed out in put on a page in the handbook. Then you'd never have to have this argument again, over 5.2 or 5.3 or 9.7. You could direct folks who bring it up to that place where all of their questions and arguments would be answered, and where hopefully they'd also be given a pretty firm idea of when they can expect the next version requirement bump.

Again, I'm not saying this has to be a date. It could be a percentage of sites or number of sites instead. Or it could be something else. It could be exact or approximate. And it can have all of the caveats in the world (well, one or two anyway), as long as we're given the benefit of being allowed to understand what things will be taken into consideration and what weight they will be given when the decisions are made.

I can understand that folks are tired of talking about this. But it is not a problem that is going to go away any time soon. For the foreseeable future, we're going to have old versions of PHP to fight over. And so I really think putting together a more comprehensive resource on this issue is in everyone's best interest. And since it has been discussed to death already, I guess we have plenty of material to draw on. :-)

This year, we've been speaking to several major hosts about updating their PHP versions - in the last three months alone, this has resulted in about a million sites being upgraded from PHP 5.2 and 5.3, to 5.5 and 5.6. Setting a hard deadline won't improve this rate, because it's not a thing that can be improved through threats.

Thank you for your continuing work (and progress!) on this. It is deeply appreciated.

#34 @markoheijnen
2 years ago

Most hosts do support supported versions: see phpversions.info. Which is probably outdated but it's a nice overview.

#35 in reply to: ↑ 22 @jdgrimes
2 years ago

Replying to markoheijnen:

To me this is a users problem on the first place but that's to easy to say. If you say hosts should update then there is a problem since most hosts are already supporting 5.6 or 5.5. They simply can't just kill old versions as @jdgrimes said in one of his comments. Hosts also play the long game like WordPress does for the exact same reason: No breakage for their users.
So it's up to the user to update the PHP version of their account or sites (depending how the host work). The big problem then is to make them understand why and how they can do the update themselves. When then the percentage of for example PHP 5.2 drops then it's easier for hosts and WordPress to kill it.

I agree that at some point this might have to involve the user, but I still think that it is the host's place to get the user involved, not WordPress's. WordPress can't explain to the user how to update, because it can't be 100% sure that the user even can, or how they would do it. It varies from host to host. The host is in a much better place to encourage the user to upgrade, since they can actually explain how to do it, and will probably be the ones providing support if anything goes wrong. (Not to mention that the core team is adamant that they WordPress won't involve the user.)

What WordPress can and must do is to to scan the plugin/theme directories for plugins using things that will break when running PHP 5.5 and later. So they can show to the outside that nothing can break when moving to the latest PHP version. I already have seen enough breakage that this can become a serious issue.

I think this is a good point. The plugin repository is open source, of course, so anyone can create a scanner that will do this. Assuming that such a thing is possible, interested parties could build it themselves. :-)

#36 in reply to: ↑ 30 ; follow-up: @stracker.phil
2 years ago

Replying to pento:

We tried setting a date years ago, back when we dropped PHP 4 support. All it resulted in was people's sites being broken, it didn't hurry the transition to PHP 5.
... because we're not in the business of breaking millions of sites on a whim.

This is the reason why we suggest to discontinue automatic updates of unsupported versions.
So if someone has a php version that is not supported he will stick with an outdated version of WordPress, without a possibility to auto-update.

Hosts that I've spoken to aren't using vanilla PHP 5.2 for their sites that are still on it, anyway - they have custom builds with security patches back ported.

Do we officially support custom builds PHP now?

#37 in reply to: ↑ 36 @jdgrimes
2 years ago

Replying to stracker.phil:

Replying to pento:

We tried setting a date years ago, back when we dropped PHP 4 support. All it resulted in was people's sites being broken, it didn't hurry the transition to PHP 5.
... because we're not in the business of breaking millions of sites on a whim.

This is the reason why we suggest to discontinue automatic updates of unsupported versions.
So if someone has a php version that is not supported he will stick with an outdated version of WordPress, without a possibility to auto-update.

I think it is a good point that we're not actually asking for any sites to get broken. WordPress should just refuse to update if the PHP version isn't supported.

However, I'm all for continuing to supply automatic security updates for old versions of WordPress. The updates would be compatible with whatever versions of PHP were supported when that version of WordPress was released. If we stop supplying automatic updates we leave users in a much less secure position, instead of improving the security of their site.

#38 @jdgrimes
2 years ago

  • Keywords needs-codex dev-feedback added

I'm adding the needs-codex keyword, because I couldn't find anything at all about this in the core handbook. I'd like to get some feedback from the core team on my proposal that something be added there.

#39 follow-up: @alexander.rohmann
2 years ago

@pento

I don't really want to have this argument again, but I just can't help myself. ¯\_(ツ)_/¯

So you're guilty of taking it off-topic like the rest of us. The nature of your response makes me feel like you didn't read anything here. TL;DR; and you throw your opinion out and close it down.

The intention of this topic was to strategize how to go about upgrading. A timeline based seems to be a major opinion, but that doesn't mean it has to be the one.

There's nothing in PHP 5.3 or later that's particularly useful in WordPress Core, so it's not like we need to force an upgrade for a language feature.

That's because WordPress Core is a mature platform. You've already coded everything with antiquated patterns necessitated by the constructs of older PHP. Not upgrading leaves no room for modern development, and is a huge disservice to plugin and theme developers.

Your aversion to coming up with a creative solution is very disappointing. While those discussing here might not have all the information, there are some good ideas here. Maybe you could address those instead of leaving us in the dark again.

Last edited 2 years ago by alexander.rohmann (previous) (diff)

#40 in reply to: ↑ 39 @chriscct7
2 years ago

Replying to alexander.rohmann:

@pento

I don't really want to have this argument again, but I just can't help myself. ¯\_(ツ)_/¯

So you're guilty of taking it off-topic like the rest of us. The nature of your response makes me feel like you didn't read anything here. TL;DR; and you throw your opinion out and close it down.

The intention of this topic was to strategize how to go about upgrading. A timeline based seems to be a major opinion, but that doesn't mean it has to be the one.

There's nothing in PHP 5.3 or later that's particularly useful in WordPress Core, so it's not like we need to force an upgrade for a language feature.

That's because WordPress Core is a mature platform. You've already coded everything with antiquated patterns necessitated by the constructs of older PHP. Not upgrading leaves no room for modern development, and is a huge disservice to plugin and theme developers.

To be clear, even if and when WordPress's core PHP supported version gets bumped up, that code will almost certainly not change. See core philosophy of not refactoring code for the sake of refactoring code (and also the ones for backwards compatibility). Unless those specific patterns can be implemented in a way that's fully backwards compatible and proven to be superior for a reason other than being "not the latest and greatest pattern" (such as a significant performance increase), the code will remain the same. Also re:constructs, all of the PHP 4 style constructs are removed from core in 4.3.

There by the way is already a mechanism in WordPress and WordPress.org that is being used to not serve new major versions to unsupported PHP installs, so there's no need for a discussion on implementation of that; it already exists, and is already in use.

But as pento pointed out, WordPress core does not have a need for moving the minimum PHP version up. Core doesn't need anything provided in newer PHP versions (particularly not at the cost of breaking sites). There's no point in talking about when, an if, or a how until there's a why.

#41 @markoheijnen
2 years ago

On the moment there is a why then we are to late to act. WordPress need to act even if there is no reason yet. You need to care about the things you use specially if that is the programming language you use.

#42 @alexander.rohmann
2 years ago

@chriscct7

There's no point in talking about when, an if, or a how until there's a why.

How about these for why?

  1. Security. Updating could pre-empt a situation similar to the heartbleed exploit. PHP has no responsibility to keeping the current version secure. You're so concerned about users, but they're all screwed if this happens and that's a huge blemish on WordPress.
  2. Longevity. Generally speaking, the farther you lag behind the harder it is to catchup.
  3. Ostracizing developers, who are getting more and more frustrated. It's difficult for plugins to integrate with services these days. Vendor libraries for their APIs follow modern PHP development. This leaves us to develop our own library to interface with an API if we want to comply with 5.2.
  4. Improving development of new core features. Obviously there's no point to refactoring just for the sake of refactoring, but core is consistently developing features and refining old ones so there would be places to introduce refined development practices in core itself. Even new features have so many workarounds to simple problems that can be solved with newer PHP concepts. For example: "late static bindings" ( introduced in PHP 5.3 so it's hardly new) would could solve so many inheritance issues, that lead to repeating code.

There by the way is already a mechanism in WordPress and WordPress.org that is being used to not serve new major versions to unsupported PHP installs, so there's no need for a discussion on implementation of that; it already exists, and is already in use.

That's great. So in theory WordPress can already bump the restriction with a major release, and nothing breaks? How novel...

Last edited 2 years ago by alexander.rohmann (previous) (diff)

#43 @jdgrimes
2 years ago

  • Keywords 2nd-opinion added

Could one of the project leads please find the time over the next few days to read through all of this and give us a second opinion? We would really appreciate it! I realize that when this ticket was opened it was in the middle of trying to get 4.3 out the door. Now that things are slower again, please take an opportunity to address this before everything gets really busy with work on 4.4.

(I am very tempted to reopen, but I know that some folks read every comment on trac, so this will get seen, I think. :-)

#44 follow-up: @alexander.rohmann
2 years ago

A second opinion would be great. I have to say that as a plugin and theme developer, @pento's thin conclusion leaves me feeling like a 2nd class citizen. WordPress core is important, but so is the ecosystem surrounding it my friend.

To whoever may provide a 2nd opinion: My assumption is that the biggest concern (problem number 1) here is a potentially large fallout in sites breaking, and support needed to get them working again. Please correct me if there is anything else.

There are ways to solve this if we stop looking at it as an open-ended problem. First, I don't see how the ideas presented in previous posts wouldn't be sufficient to solve problem number 1. But if it's not enough, surely there are other ways...

This is a crazy idea, but I'm confident that we could raise enough awareness among WordPress developers that we could have people volunteer time over the next year to assist with any support fallout. For example, setting up some form of coalition where people having issues can open a request, and have a volunteer look into the issue on their site hands on.

I'm sure there are enough people on the side of moving forward willing sparing a few hours a month for a while. I'd be happy to organize something like this as well.

#45 in reply to: ↑ 30 @stracker.phil
2 years ago

Replying to pento:

I'd be also very interested if the reply by pento is an official statement that the core team decided after thorough discussion or if this is the personal opinion/decission of pento on how to handle this thread.

Any details?

If there was a discussion that led the core team to the conclusion to stick with php 5.2.14 then maybe we can share a link here, so we understand the reasoning.

Also, how many core team members/who do we need to convice to move forward for it to become an official request?
:-P

#46 in reply to: ↑ 44 @knutsp
2 years ago

Replying to alexander.rohmann:

To whoever may provide a 2nd opinion: My assumption is that the biggest concern (problem number 1) here is a potentially large fallout in sites breaking, and support needed to get them working again. Please correct me if there is anything else.

Not true, as far as I have understood the mechanisms already baked into WordPress. No sites will break because PHP or MySQL minimum requirement is raised. From that time sites that don't meet this will just not be able to upgrade to the next major release using one-click updates. They may only receive minor updates. If they force manual update (FTP etc) they will be met by some sort of error or sorry message.

The biggest concerns are then:
1) How to guide users to contact their hosting provider to get a upgrade to their PHP version
2) How to deal with the sad story of those who just doesn't understand what PHP is, how to contact their host and that there are a never major version WordPress that they aren't able to upgrade to

I like the idea of a joint effort by he whole community to guide and help users. We are thousands of developers who want to participate, and follow some guidelines on how to meet users facing this situation.

I also want to see just one figure: The number of users who will probably see this problem at release time after this change, taking to account that many users/site owners never update their WordPress anyway.

As a start, how many who updated to 4.4 runs PHP 5.2?

We demand a decision on future date or release that minimum PHP will be raised to at least 5.3 so we can start preparing, both ourselves, users and hosts to this day. That would be proper leadership.

#47 @alexander.rohmann
2 years ago

Last I heard, the correlation of these charts is pretty even (https://wordpress.org/about/stats/). WordPress does such a great job helping people get to the latest version that the ratio of people using the latest version of WordPress is about the same across all PHP versions. We could probably assume that roughly 12% of 4.3 users are on PHP 5.2

Starting with 5.3 would be nice. Although I'd love for a longterm contingency plan that involved bringing to things up to supported PHP and staying there.

#48 follow-up: @CyberCr33p
2 years ago

I believe that most people don't know what version of PHP does their webhost run as long as their website works. I recommend as the first step to show a warning everytime an admin logins that says that their webhost runs old version and they should contact them to upgrade.

#49 in reply to: ↑ 48 @alexander.rohmann
2 years ago

Replying to CyberCr33p:

I believe that most people don't know what version of PHP does their webhost run as long as their website works. I recommend as the first step to show a warning everytime an admin logins that says that their webhost runs old version and they should contact them to upgrade.

More great ideas! True, most people probably don't know. This could be implemented in any release without breaking anything. It could even link to a page on wordpress.org where a form letter could be provided and engagement could be tracked.

#50 follow-up: @CyberCr33p
2 years ago

I own one of the biggest webhosts in Greece and few days ago we upgrade from PHP 5.4 to 5.5. Only few sites broke mostly because of preg_match() but it was easy to fix. If a webhost currently runs 5.4 then upgrading to 5.5 is not a big deal.

Last edited 2 years ago by CyberCr33p (previous) (diff)

#51 in reply to: ↑ 50 ; follow-ups: @Ipstenu
2 years ago

No in hates 5.2 more than hosts.

Does WP have the right to enforce PHP 5.3+ when none of its code actually requires it?

Do you actually think that WP dropping php 5.2 support will have the power to speed up the existing process by hosts to drop it?

That just makes it a bully.

#52 in reply to: ↑ 51 @jdgrimes
2 years ago

Replying to Ipstenu:

Does WP have the right to enforce PHP 5.3+ when none of its code actually requires it?

Of course they do! However, we'd all much prefer to sacrifice a little on our end so that the process is much easier for everyone.

Do you actually think that WP dropping php 5.2 support will have the power to speed up the existing process by hosts to drop it?

That just makes it a bully.

I don't know, but honestly, that isn't really the point of this ticket. I know it has been discussed above, but partly it is just a distraction. What we're asking for is some insight into a clear and concise strategy for bumping the PHP version. I think that WordPress needs to put it's philosophy on this in writing, both so that the community knows what is going on, and so that next time we and our posterity will have that established philosophy to guide them.

[None of that is meant to be snarky. Please don't take it that way :-)]

#53 @TimothyBlynJacobs
2 years ago

Does WP have the right to enforce PHP 5.3+ when none of its code actually requires it?

Here is the thing. No one needs newer versions of PHP. You can code around most of the new features. However, the resulting code isn't very nice. It is hard to read and hard to maintain. For WordPress core this frankly isn't a huge issue, because there already is a massive amount of technical debt that core contributors graciously bear for end users.

However, plugin authors don't have that luxury. Many of us don't have massive teams of dedicated people who can support that technical debt. As such, the benefits of newer versions of PHP have much more value to us. So much so, that many plugins now require their users to have later versions of PHP. This means that instead of WordPress taking the lead on this issue, plugin developers are forced to educate their users on what PHP means, why the php version is important.

So while it is great that WordPress isn't being a bully, it is making plugin authors and WP trainers, and developers, etc... take on the responsibility of educating their customers. Or stick with supporting PHP 5.2, which can often lead to very difficult to manage codebases with a lot of technical debt. Simple things like late static binding has the ability to make lots of code in complex plugins more sane, and would also have benefits for core itself.

So while WordPress does not strictly need support for 5.3+, it and the community would benefit highly from it. Both concretely with day to day developing, but also WP's perception from the larger PHP development community.

Like jdgrimes, I'm not saying let's drop 5.2 tomorrow and leave thousands of site owners in the dust, but there needs to be a public facing strategy of some kind that has a reasonable timeline.

Last edited 2 years ago by TimothyBlynJacobs (previous) (diff)

#54 in reply to: ↑ 51 @alexander.rohmann
2 years ago

Replying to Ipstenu:

That just makes it a bully.

No, that just makes it the enabler of a PHP lethargical nightmare that starts with hosts.

How is WP a bully if...

  1. Time is taken to strategize how to implement this.
  2. We're talking about a longterm plan.
  3. Hosts aren't immediately affected because major version auto updates won't be served to PHP 5.2.
  4. Read all the other ideas posted above. (try reading objectively?)

I totally agree with everything @TimothyBlynJacobs has said above as well.

I'll even add that this limitation is crippling to developers. Remember this? http://stackoverflow.com/research/developer-survey-2015#tech-super Why do you think outside developers find WordPress the 3rd most dreaded technology?

We're working with an antiquated toolset. "Bully" isn't the right word to reciprocate, but I (and as is quite apparent many others) are feeling quite wronged by this. How does "neglected" fit?

After all this time, I don't think any more excuses can be made and I simply see this is negligence on the part of WordPress to the community. There needs to be a plan of action.

#55 follow-up: @Ipstenu
2 years ago

Here is the thing. No one needs newer versions of PHP.

Not true :) Some code bases simply do not work on older versions of PHP. Amazon's AWS SDK for example. So in that instance, it's needed.

We're working with an antiquated toolset. "Bully" isn't the right word to reciprocate, but I (and as is quite apparent many others) are feeling quite wronged by this. How does "neglected" fit?

Bully because WP would be saying "Hey, here's this thing we're not technically requiring for using yet, but we're going to leave all the users out in the cold for our new, cool, things, because we don't want to support it, even though there isn't (currently) a security related or feature related reason to do so."

I'm not talking about hosts (though as someone who works for one, I probably could). I'm talking about the end users who would be hurt by this and hosts could rightly say "Even though WP doesn't need to require PHP 5.3, they decided to do this."

That would hurt the relationship with the community far more than supporting PHP 5.2 as a minimum requirement.

#56 @TimothyBlynJacobs
2 years ago

Not true :) Some code bases simply do not work on older versions of PHP. Amazon's AWS SDK for example. So in that instance, it's needed.

Right, but that's because the SDK was coded to that version. You could write an SDK for it in version 5.2 if your crazy :)

#57 @knutsp
2 years ago

What about these two facts:

  1. To make a patch for core you have to "unlearn" some language constructs, functions and defaults introduced i PHP after 5.2
  1. To make a theme or plugin you either have to "unlearn" the same as above, or introduce really bad UX by bailing on activation when the potential users PHP is 5.2.

For each new version of PHP and (probably mostly young) people that learn PHP using a no yet EOL'ed PHP version, it gets worse and worse.

I make a lot of simple plugins and introduce a lot of presentation related functionality in local child themes, but almost all I do is for "private" (client use) only. I could have made a lot of this for the public domain (wp.org), but I find it cumbersome to revert to ancient constructs, and to install PHP 5.2 to test code. Also also think that automatically deactivating things when "special" requirements (PHP > 5.2) are not met is not they right thing to do towards users ("bullying" them with blah, wrong PHP version!).

I would hate not being able to use anonymous functions or traits, proper dereferencing, and namespacing, and I do love [] as array constructor, as a very few examples. I refuse to "unlearn" those things. I have instead chosen to argue here that WordPress must grow up, or at least have strategy to do so.

So when saying WordPress (Core?) doesn't "need" later PHP, please take a broader picture.

#58 in reply to: ↑ 55 @alexander.rohmann
2 years ago

Replying to Ipstenu:

Here is the thing. No one needs newer versions of PHP.

Not true :) Some code bases simply do not work on older versions of PHP. Amazon's AWS SDK for example. So in that instance, it's needed.

We're working with an antiquated toolset. "Bully" isn't the right word to reciprocate, but I (and as is quite apparent many others) are feeling quite wronged by this. How does "neglected" fit?

Bully because WP would be saying "Hey, here's this thing we're not technically requiring for using yet, but we're going to leave all the users out in the cold for our new, cool, things, because we don't want to support it, even though there isn't (currently) a security related or feature related reason to do so."

I'm not talking about hosts (though as someone who works for one, I probably could). I'm talking about the end users who would be hurt by this and hosts could rightly say "Even though WP doesn't need to require PHP 5.3, they decided to do this."

That would hurt the relationship with the community far more than supporting PHP 5.2 as a minimum requirement.

My closing statement there was insinuating that WP is neglecting, (but not bullying) developers. I addressed hosts in everything preceding that. Any thoughts on those points?

#59 follow-ups: @Ipstenu
2 years ago

My closing statement there was insinuating that WP is neglecting, (but not bullying) developers. I addressed hosts in everything preceding that. Any thoughts on those points?

I think there are more users than developers, and the developers are actually the least impacted by a technical change like this. The technical onus of upgrading PHP is not something most end-users are capable of addressing. I think WP has opted to prioritize their user base over their development base in this instance and, seeing as millions of people use WP but far less develop for it, it's a fair stance today.

The people who are capable of making the technical changes (hosts and devs) have more work on their shoulders than the people who are not (users).

Neglected is not the word I'd use. I think I'd say they're the minority, or perhaps not the first priority. But yes, it certainly would feel like you're being neglected for the sake of the non-technical users. So that's not a wrong feeling.

At this time, I feel any plan of action would be detrimental to the people least prepared and able to solve anything: the users.

Change that (or have a technical/security reason to burn 5.2 in a fire) and I'm all in.

#60 in reply to: ↑ 59 @alexander.rohmann
2 years ago

Ok, well at least that confirms what I mentioned earlier about plugin/theme developers being second class citizens. ;)

Replying to Ipstenu:

At this time, I feel any plan of action would be detrimental to the people least prepared and able to solve anything: the users.

Change that (or have a technical/security reason to burn 5.2 in a fire) and I'm all in.

We're talking about a plan that doesn't leave them in the cold. Actually, we're barely talking about a plan at all - which was the point of this ticket....

Your assumption that "any plan of action would be detrimental" is shortsighted and presumes that those involved in WordPress lack the creative thought and wisdom to find a way to solve this in a way that helps move forward without alienating the community. It's a tall order, but not impossible. Yes, there will be fallout, but it won't be unmanagable.

Can we please stop debating whether to change or not? It would be great if we could put some creative thought together and come up with a few more proposals on how to solve this longterm, instead of all this off topic debate.

On Topic: Summarized from above, here are some ideas and progress we have so far. These are in no particular order, and represent small potential parts of a larger more organized plan that we're hoping to see implemented by someone with the authority to do so.

  • Detect PHP 5.2 and prevent automatic updates to a major release. Users will still get security updates.
  • Show a notice to users on PHP 5.2 letting them know that they can't update to a major release, and have them request their host to update PHP, or move them to a server that is more capable.
  • We have interest and willingness by those above to work directly with hosts, and users.
  • Do this over a period of time long enough that hosts can upgrade PHP, or relocate users.

With these actions, "users" will be pretty much in the clear. Hosts will have it the hardest, but we can give them time (instead of letting them take it from us) by having some timeframes announced.

#61 @stracker.phil
2 years ago

That's all very valid points... Though I would not say that raising the requirements does "bully" the users. In my opinion it means that we're taking up responsibility for WordPress; as opposed by putting this decission into illiterate users hands. Oh no, actually we wait for the web-hosts to update php... Or wait.. actually nobody really knows what we are waiting for... So just stick with the version we have, making a plan could offend someone.

So far the only real argument against php 5.3 I can hear is:
"Most users don't know it, besides we don't really need it in core".

But honestly, who is developing WordPress? Who needs to ensure that in 5 years from now we still have the high-end developers we have today? Who is responsible to create all the amazing things that made WordPress so popular?
It's not the users who know nothing about PHP. It's not the users role to lead our technical requirements. Because as stated: They don't have a clue about it.

Honestly, the core system is great, but it alone does not ensure the future market-share - blogging has become a no-brainer today. According to a statistic I saw for every WP blog come 4 business/commercial WP sites. Now, this seems like WP core is not the actual thing that makes WordPress so popular, but the environment around it. As a result the core team might consider keeping the devs all around happy and fed.

I see this request for a higher minimum requirement as a strategic action to make millions of developers happy - and to attract new ones, as the first ones are already getting old :-P

And what other CMS/Blogging plattform out there has a comparable community and free support? Do you have no trust in the community, that people will help other people to get along with those changes?

My answer to the question "why does WP need php 5.3?" is actually: "Because it's the way to get to php 5.5"
I don't want php 5.3 - it's also way past the official end-of-life; but we need to get past php 5.2 at some point...

But maybe I'm wrong, and we should really stop talking about this; let's code in php 5.2 until nobody uses it anymore. Waiting for users to update something that they don't even know exists seems like the innovative and pro-active approach that is holding WordPress up against an ever rising number of competitors. And it seems in alignment with the idea behind WordPress:
"WordPress was born out of a desire for an elegant, well-architectured personal publishing system" (ok, this could also refer to the UI).
"...by focusing on user experience and web standards..." (ok, this could refer to ... correct HTML in the default theme?...)

#62 @joshuadnelson
2 years ago

Perhaps we need a roadmap for this that reflects supported PHP versions and correlating WP versions?

For example, we could say that as of WP 4.6 the minimum PHP is v5.5. We add a PHP version check on updates, if your WP version is older than 4.6 and your on PHP 5.2, it will update to the most stable WP 4.6.X but also throw up an admin notice "Please contact your host to update your PHP to at least v5.5..."

From that point forward security updates could be added to WP 4.6.X, but anyone trying to update to WP 4.7 or higher on an older version of PHP will get that notice and no update will be performed (or they will be updated to the most current 4.6.X version with the notice).

This maintains a pseudo backwards compatibility for older version of PHP (4.6.X will continue onward until the numbers are low enough to drop it entirely), while allowing newer versions of WP to be used with supported PHP versions and all those features. I think, if it's not completely unfeasible, this method would also push people to update without breaking their sites on an update.

I can see many reasons why this might not be practical, but thought I would throw it out there.

#63 in reply to: ↑ 59 @knutsp
2 years ago

Replying to Ipstenu:

I think there are more users than developers, and the developers are actually the least impacted by a technical change like this. The technical onus of upgrading PHP is not something most end-users are capable of addressing. I think WP has opted to prioritize their user base over their development base in this instance and, seeing as millions of people use WP but far less develop for it, it's a fair stance today.

I could not agree more. WordPress is made for the many users, not the (relatively few) developers. But without developers there would be no WordPress. Yopu have to take developers into account in some way. Without the ability to recruit excellent new developers WordPress (core, themes, plugins included) will be evolving more and more slowly.

And EOL'ed PHP versions may have much greater security risks than those still alive. This could harm users hard, some day. Why wait until the fire has caught?

If WordPress is too afraid to plan for taking just one small step (for mankind, or internet) in the foreseeable future, then WordPress will never move an inch.

And users will be able to contact their host, quoting a well crafted sentence about why WordPress need their host to upgrade or move their site to newer PHP.

My experience is that hosting providers are lazy, as we all, and want to keep staff as few as possible. They won't act until the demand through support requests are un-ignorable. They do absolutely not "hate" PHP 5.2, except some. They are mostly happy it works as it is, for a large amount of their customers.

When the queen of the CMS world speaks, they will start worrying, and planning upgrades. When the queen is silent, or just kindly approaches some of the biggest players, they just do business as usual. Upgrades may imply extra work and extra hardware. Companies spend money when not spending may become more expensive.

#64 @mbabker
2 years ago

So I'm going to "butt in" here with an outside perspective from a project that did a PHP bump on the same EOL PHP branch last year. In Joomla, we moved from 5.3.1 to 5.3.10 with a transition period giving security support for the old minimum. Yes, there were user groans about the change (I would suggest searching our forums if really interested), but surprising to me was that the most vocal groans came from those we would say are technically capable of managing their PHP installs. Those folks worked at companies with policies or made decisions that they were only using the *nix LTS versions (at that point most were on 5.3.3 and the new LTS releases were just getting tagged), and those folks made demands that a version minimum shouldn't be forced but rather feature detection mechanisms with fallbacks or using those tests to block running the app. From my experience in that and observing what WordPress has done with hosts, the right calls are being made for the end user at the expense of a lot of excess baggage in not forcing an update. Just some random food for thought.

#65 @alexander.rohmann
2 years ago

Those big company policies exist to control costs. Open source isn't free. We're looking at five years of technical debt that somebody is going to be paying one day.

What's been proposed above doesn't involve a forced update. Apparently, WordPress already has the mechanism to enforce a change with a major release, and continue providing security fixes to the previous major release. Nothing forced, no baggage.

Last edited 2 years ago by alexander.rohmann (previous) (diff)

#66 @jdgrimes
2 years ago

Ironically, usage of PHP 5.4 peaked at 41.5% 2 weeks ago—the same weak that PHP ceased security updates for it.

On the bright side, this means that the number of WordPress sites using PHP 5.4 is finally on the decline.


I think I've finally come to grips with the position that WordPress has taken on this. In short, their philosophy boils down to this:

  • Always put the interests of the users first.
  • Users shouldn't have to know about server configuration—WordPress should just work.
  • Hosts are responsible for providing a secure server environment—not WordPress.

As long as there are legitimate reasons that a responsible host would support PHP 5.2, and a significant number of users are using such hosts, WordPress won't change its requirements.

I can sympathize with that position (though some of us may disagree with some of its tenets). But I also think it is being taken to an extreme that is unhealthy for the project as a whole, and may end up actually hurting users in the end. It is alienating developers, and discouraging newbies, who may have learned newer versions of PHP only, from contributing to the project. It is "protecting" the user from these rouge developers, to the point where it may lead to community stagnation.

I think we all agree that there is a point where you have to please the developers to please the users. And yes, PHP 5.5 (or 5.4 or 5.3) might be mostly just 5.2 plus candy. But what developer doesn't like candy? Offering more candy would probably mean more developers would contribute to the community.

However, it is, admittedly, a matter of opinion as to when it becomes imperative to allow a little user suffering in deference to developers, for the greater long-term good of the community. Thankfully, WordPress is in a place where that user suffering won't be waking up to a dead site after a WordPress update. It will just mean not getting an update until your host has bumped your PHP version up to something sane.

The opinion of the project leads will ultimately prevail in deciding when (not if) that will happen. But please, I beg of you, please can we have the philosophy spelled out in the core handbook. I know that you believe you have made yourselves clear. But there must be some reason that you keep having to "make yourself clear" over and over and over again. It is because there is no official canonical resource where this philosophy is explained.

You have a right to run this project as you like, and I can understand if you don't want to pick a date because you've been burned by that in the past. What is beginning to frustrate me is the lack of empathy being displayed toward developers like myself who are invested in this, and are only seeking the best for the future of WordPress. We don't feel like we've really been heard, just responded to and then ignored.

I sense that you are tired of discussing this, and I understand that. But I don't think it will ever end until you add it to the handbook. Bumping to 5.3 (or 5.5) won't make it go away. In fact, I think bumping from 5.2 to 5.3 (if that is what happens in the near future) will only start all of the discussion off again. This ticket could have been taken as an opportunity to clarify the strategy and the philosophy behind it ahead of time. I can't understand why you keep kicking the can down the road here (and I'm not talking about the version bump, but clarifying the strategy for it).

I understand that it may be more a matter of time and other priorities, but if this is put to rest once and for all, then you'll never have to waste time on it again. :-)

#67 @pedroghandi
19 months ago

Hope you don't mind an opinion of a small plugin dev.

with every wp release i'm invested in keeping up with the codebase. i get email reminders to test and make it compatible with the latest wp.

but then I read these discutions, treating the end users as mindless ones. Users should be responsible for keeping their sites updated. Press "update" for wp, themes, plugins and hosting features. It isn't that hard to flick the switch. It's the least they can do.

I already refrain from using new syntax, new php features, new functions. I have to conditionally run some code for >5.4. Should the need arise, how many EOL versions we need support?

Today I got a user saying that she tested it in php7 and it threw the

"Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP".

It was on my to-do list, and this just makes me happy that there's feedback. I don't mind putting a extra effort into it.

If a user doesn't know that php5.4 is EOL, we should warn them. Make it obvious, explain why and what will be the benefits of it. Maybe detect who is the host and indicate the host guide to upgrade php versions. If its cpanel, it can't be easier.

If you won't, plugin devs probably will. I already show a warning to users that use wp<4.0, it isn't that hard to warn them about wrong php versions.

thanks,
p.

Last edited 19 months ago by pedroghandi (previous) (diff)

#68 @jorbin
17 months ago

  • Resolution maybelater deleted
  • Status changed from closed to reopened

#69 @jorbin
17 months ago

  • Owner set to jorbin
  • Status changed from reopened to assigned

#70 @jorbin
17 months ago

#36542 was marked as a duplicate.

#71 follow-up: @jorbin
17 months ago

I think that what we need to do here is not solve this for the short term, but come up with a long-term policy for versions of PHP that we support. This will help prevent this discussion from constantly coming up. While it is about php 5.2 right now, it was about php 4 before and one day it's going to be about the entire php 5 release branch. In a far off world, it's going to be about PHP 7. Let's fix it all now.

Two important things to keep in mind:

1) If we update too early, we leave users running both an insecure version of PHP and an insecure version of WordPress. That's a lot of surface area for attacks.

2) Most people who run a WordPress site don't know what PHP is, let alone what version they are running. Telling many of them they need to update PHP is roughly equivilant to telling a whale to walk on land.

#72 in reply to: ↑ 71 ; follow-up: @jdgrimes
17 months ago

Replying to jorbin:

I think that what we need to do here is not solve this for the short term, but come up with a long-term policy for versions of PHP that we support. This will help prevent this discussion from constantly coming up. While it is about php 5.2 right now, it was about php 4 before and one day it's going to be about the entire php 5 release branch. In a far off world, it's going to be about PHP 7. Let's fix it all now.

I absolutely agree. This is exactly what I (and others too) have been advocating above. Thank you for "owning" this discussion. :-)

1) If we update too early, we leave users running both an insecure version of PHP and an insecure version of WordPress. That's a lot of surface area for attacks.

This is true, however, as long as we continue to push out security updates for older versions of WordPress (back to 3.7), this is really not much of an issue. Just because they can't update WordPress doesn't mean that they won't receive automatic security updates. (Unless they are running a version before 3.7, in which case they are already insecure.)

2) Most people who run a WordPress site don't know what PHP is, let alone what version they are running. Telling many of them they need to update PHP is roughly equivilant to telling a whale to walk on land.

This is the part that some of us are having trouble comprehending. (We're developers, after all!) But I'm sure it is true for many users, and as far as I can see it is the biggest issue that we have: there is no easy way to do this without involving the user in something that they really don't understand (and shouldn't have to on the modern web, IMO). I guess maybe we really need some creative ideas here.

#73 in reply to: ↑ 72 ; follow-up: @jorbin
17 months ago

Replying to jdgrimes:\

This is true, however, as long as we continue to push out security updates for older versions of WordPress (back to 3.7), this is really not much of an issue. Just because they can't update WordPress doesn't mean that they won't receive automatic security updates. (Unless they are running a version before 3.7, in which case they are already insecure.)

That's a good point, but it also is part of the problem with updating the version at all. It makes backporting security fixes that much harder.

#74 @desmith
17 months ago

Copying from #36542, not necessarily as an opinion, just some handy facts for reference:

Here's a quick summary of the versions supported by Ubuntu LTS and Red Hat Enterprise Linux, probably the two most prominent Linux distributions for servers:

RHEL 5: Shipped with PHP 5.1.6, supported through March 2017
RHEL 6: Shipped with PHP 5.3.3, supported through November 2020
RHEL 7: Shipped with PHP 5.4.16, supported through June 2024
Ubuntu 12.04 LTS: Shipped with PHP 5.3.10, supported through April 2017
Ubuntu 14.04 LTS: Shipped with PHP 5.5.9, supported through April 2019
Ubuntu 16.04 LTS: Shipped with PHP 7.0.13, supported through April 2021 (at least, no official EOL announced yet)

RHEL 5 doesn't count, as its shipped version of PHP already is too old for WordPress. Otherwise, the largest enterprise-y Linux distributions all support 5.3 (or newer).

Last edited 6 months ago by desmith (previous) (diff)

#75 in reply to: ↑ 73 @seancjones
17 months ago

I would like to bring up a few things that are distilled from my dupe at #36542.

My belief is that it is important that WordPress core and the plugins that surround it are eventually able to start de-cluttering the global scope, using a feature that has been in PHP for over 5 years - namespaces. Currently, WordPress uses the old-style namespaces which are just convention-based. These have obvious drawbacks. The features that come in later versions of PHP are nice, and certainly PHP 7 comes with some major performance updates, but PHP 5.3 is an extremely modest update which the vast majority of people who care who are running 5.2 should be able to upgrade to with limited issue.

While many WordPress users may not know what PHP is, their hosts certainly do.

I support a cohesive updating strategy. I am not proposing an upgrade from 5.2.9 to 5.3 as a one-off. I am proposing it as part of a larger strategy. Yes, part of it is that we would be able to enjoy PHP as a truly object oriented language. However, another part of it is that it would be a good test-case as we try to determine our rollout strategy. I don't think 5.2.9 -> 5.3 is a very contentious upgrade by itself, but once you get to suggesting that we only support PHP 5.5 and later, that would immediately shut down this argument, leaving us with 5.2.9 for another year or more.

I would also point out that my ticket proposes a rollout strategy that calls for an updated minimum language with a delay in using any of those new features in core. That should have three clear benefits:

  1. You can backport security updates very easily for users who are currently running 5.2.9 for a while. I suggested 6 months to a year but maybe more realistically it should be a year or two.
  1. You can steadily raise the minimum supported PHP version so that people who are wondering why they cannot get the new releases reach out to WordPress support or their host and apply pressure in getting an updated version of PHP.
  1. Plugin and theme authors should be able to utilize newer versions of PHP simply by attaching to a newer version of WordPress. This would prevent a user running an old version of PHP from installing it/updating their version, but that would only reinforce the importance of getting their system upgraded.

Ultimately, upgrades will leave a very small percentage of users vulnerable, but if someone is running PHP 5.2.9 at this stage, having a secure WordPress is barely going to make a difference. It's like putting duct tape over a hole in the bottom of a boat: Sure, it'll slow the inevitable, but it's not a permanent solution. IMHO, with a relatively manageable group it's time we cautiously begin to address this issue and set ourselves up for long-term success.

Replying to jorbin:

Replying to jdgrimes:\

This is true, however, as long as we continue to push out security updates for older versions of WordPress (back to 3.7), this is really not much of an issue. Just because they can't update WordPress doesn't mean that they won't receive automatic security updates. (Unless they are running a version before 3.7, in which case they are already insecure.)

That's a good point, but it also is part of the problem with updating the version at all. It makes backporting security fixes that much harder.

Last edited 17 months ago by seancjones (previous) (diff)

#76 @SergeyBiryukov
17 months ago

  • Milestone set to Awaiting Review

#77 @chrishoward
17 months ago

I'm with @CyberCr33p who said 7 months ago to simply display a warning. I've started doing that with my own plugin, and when you're on one of its screens, it shows a message saying their PHP version is potentially insecure, and suggesting they ask their host to upgrade them to at least 5.4

Personally, I think WordPress' actual responsibility to those 8.3% on PHP 5.2 is to proactively make them aware of the issue and encourage them to upgrade.

Imagine if Ford found that its cars made 5 years ago had a potential safety issue, but decided not to issue a recall because they didn't want to inconvenience owners and dealers.

PHP 5.2 is a security issue. Surely site owners would be grateful to WP for pointing that out and encouraging them to upgrade.

+1 to a notification on the dashboard.

Last edited 17 months ago by chrishoward (previous) (diff)

#78 @Monarobase
17 months ago

I agree that we should find a solution in between forcing the user to upgrade PHP and leaving users with old PHP versions.

1) As WordPress has no idea if old PHP versions are patched, it should presume that they aren't, that they are the default PHP versions. I know of a lot of small hosts who provide old non-maintained versions that aren't patched.
2) In our experience most users don't know that their PHP version is old. We install new accounts with the latest stable version of PHP and then leave it to users to change their PHP version (simple drop-down list to select their version).

I fully understand this issue of not wanting to put users in a situation of not knowing what to do, and believe that depending on usage statistics isn't a bad method.

I, however, also believe that if we want to be able to get rid of very old versions of PHP (PHP 5.4 is insecure unless patched), WordPress needs to inform users about this issue.

I suggest adding to WordPress Core a Warning message for any PHP version that is no longer maintained. Something like :

Warning : You are using an old version of PHP that might not be secure. WordPress recommends using PHP 5.5, 5.6 or 7.0 for your site to be secure and load pages faster. Contact your web host to find out how to upgrade to a newer version of PHP.

As this message wouldn't harm how WordPress functions, it should be added automatically as soon as a version of PHP is no longer maintained by PHP.

I believe this message would reduce the number of WordPress sites that use old PHP versions.

The statistics used to determine when a PHP version support can be dropped should only be based on WordPress sites that are using a maintained version of WordPress as users who never update WordPress won't be concerned by PHP version updates.

I strongly believe that the WordPress community could benefit from developers who currently refuse to work with very old versions of PHP.

#79 @alexander.rohmann
17 months ago

Replying to jorbin:

I think that what we need to do here is not solve this for the short term, but come up with a long-term policy for versions of PHP that we support.

Getting to the point where no PHP EOL is unsupported instead of an open-ended question would solve this long term. Here's an iteration of the idea I've shared a few times before:

10,000 foot view:

  1. Announce that the next major WordPress release (let's say 4.6) will no longer support PHP 5.2
  2. For users on PHP 5.2, divert automatic updates to the 4.5.X branch for security fixes. This update mechanism is already in place, it just needs to be flagged by version number.
  3. Repeat for PHP 5.3, then 5.4 with major releases to follow.

Solving:

  • Nobody is forced to update
  • Knowing upfront, and without being on the clock, web hosts will have plenty of time to update PHP
  • It's not a huge shock, as we're starting with the oldest version, and spreading things out over long release cycles.

How does that sound? If a decision could be made on a high-level direction (like the above), I believe the communication and other concerns can be solved along the way as it gets fleshed out.

Last edited 17 months ago by alexander.rohmann (previous) (diff)

#80 follow-up: @Kenshino
17 months ago

Isn't Matt and team working towards getting hosts to upgrade their PHP versions?

I can't help but see that a lot of the discussions have been developer based and that really does not much for our largest audience - the normal users.

8.3% of our people ( https://wordpress.org/about/stats/ ) still use PHP 5.2 and that's hundreds of thousands of sites.

Realistically, you can't tell hundreds of thousands of webmasters that hey, now you can no longer update because your host's PHP version is out of date.

Whatever strategy we come up with here needs direct collaboration from the hosts -

Perhaps part of the strategy would be -

If you want in on this page - https://wordpress.org/hosting/ you have to keep your PHP versions upgrades to a certain schedule

#81 follow-ups: @dd32
17 months ago

Isn't Matt and team working towards getting hosts to upgrade their PHP versions?

FWIW This process has been extremely slow, and thanks to the longtail of hosts (thousands of them) it's almost impossible to contact every host. A lot of them just don't proactively switch users and require the user to contact them to initiate the process.

If you want in on this page - https://wordpress.org/hosting/ you have to keep your PHP versions upgrades to a certain schedule

That list will always be a small fraction of the hosts, but yes, part of being listed there is already bound to be that they run modern software (All the hosts I can think of that have been listed there in recent times have always had the latest versions of PHP available).


My experience of having a plugin require PHP 5.4 was a lot of people who just don't understand what is wrong when software says their version of PHP is outdated. They blame the plugin for being broken, even when told their PHP is many years out of date.
End-users are not developers, and they don't like to contact their host for help if it's not their host telling them about the problem.

I don't know the answer here, but every time this comes up I get one more step towards encouraging a banner of some form within WordPress. I used to be highly against it, but backed by a properly designed and informative page, might be the only option available to WordPress in the long-run.

#82 in reply to: ↑ 81 @DvanKooten
17 months ago

Replying to dd32:

FWIW This process has been extremely slow, and thanks to the longtail of hosts (thousands of them) it's almost impossible to contact every host. A lot of them just don't proactively switch users and require the user to contact them to initiate the process.

That's why a solution like the one @alexander.rohmann proposes would be great. It's simple, really, nothing new.

I think we're also hugely underestimating the level of understanding WordPress.org users have about their own self-hosted website(s). Surely they know it's running on a computer that sometimes needs software updates. Sell them on the performance benefit & security aspect and they'd be happy to bug their hosts about it .

WordPress could be the one to educate here. I'd say it definitely should be.

I've been following this topic for a few years now and it saddens me to see a discussion like this just repeating itself over and over, with the same statements coming up. It's obvious WordPress needs a proper PHP update strategy in order not to alienate itself from the rest of the PHP world (with ever decreasing developer happiness as just one of the results).

I'm glad @jorbin is giving this ticket some much needed attention, but frankly I'm afraid to get my hopes up right now.

#83 in reply to: ↑ 81 @nerrad
17 months ago

Replying to dd32:

My experience of having a plugin require PHP 5.4 was a lot of people who just don't understand what is wrong when software says their version of PHP is outdated. They blame the plugin for being broken, even when told their PHP is many years out of date.

I don't know the answer here, but every time this comes up I get one more step towards encouraging a banner of some form within WordPress. I used to be highly against it, but backed by a properly designed and informative page, might be the only option available to WordPress in the long-run.

With Event Espresso, we upped our minimum requirement to PHP5.3 back in August 2014, and we:

We made the switch when the number of users on php5.2 fell below 10%. Our experience was and is very positive. We have had very LITTLE pushback from our users after the switch and most feedback has been positive. Almost always, when users see the notice they end up either having their host help them switch their php versions or switch hosts if their host isn't responsive.

Here's the message we show:

We're sorry, but Event Espresso requires PHP version 5.3.0 or greater in order to operate. You are currently running version xxx. In order to update your version of PHP, you will need to contact your current hosting provider. For information on stable PHP versions, please go to http://php.net/downloads.php.

Whats interesting about our experience is that for the most part, our user install base consist of non-technical or non-developers.

Our experience seems to suggest:

  1. Users won't be as put off by having to bug their hosts about updating php version as we think they will be.
  2. Users understand the words/phrases security and end of life and that goes a long way towards explaining the switch.
  3. It goes well when the reasons are communicated well and in a way readily visible to users.
Last edited 17 months ago by nerrad (previous) (diff)

#84 in reply to: ↑ 80 @alexander.rohmann
17 months ago

Replying to Kenshino:

Realistically, you can't tell hundreds of thousands of webmasters that hey, now you can no longer update because your host's PHP version is out of date.

Why not?

They would still be able to access WordPress security updates. If they insist on locking in an archaic version of PHP, then they should be able to understand being locked into a specific branch of WordPress.

Replying to nerrad:
Thank you for sharing this. It's really nice to see a perspective from a real world example.

Last edited 17 months ago by alexander.rohmann (previous) (diff)

#85 @seancjones
17 months ago

I have a strong suspicion that there's a lot of overlay between the outdated versions of WordPress and outdated versions of PHP. We don't know how many of these websites are completely abandoned or at least neglected. The subsection that cares is important, but 7.5% of users still use IE6 and as far as I can tell (maybe I'm totally wrong) Wordpress.org doesn't even load on it.

I think to assuage (or perhaps reinforce) any fears we should take the opportunity to do more research and understand just how many people running PHP 5.2.9 are on the latest version of WordPress. Is this possible given the analytics you have access to?

#86 follow-up: @chris@…
17 months ago

@nacin had a post about a year ago (scroll down to the Updated March 2 headline) where he partially answered the old PHP/old WP percentage question.

Is there anyway we can see PHP/MySQL versions broken down by what WordPress version they are running on?
We’re still working on ensuring the numbers are stable. They’re pretty predictable: older WP versions have more people on older PHP and MySQL versions. Newer WP versions have less.
PHP 5.2 is at about 16% for all installs right now. It’s at about 10% for installs running WordPress 4.1, but because 4.1 is such a large part of the pie (36%), it’s the WP version with the most PHP 5.2 installs.

I'd be curious to know if there's been an update on this.

#87 @seancjones
17 months ago

If I may propose what I think is a fairly conservative solution to throw into the mix in case this conversation spins out again (which I certainly hope it doesn't)...

It's clear to me that developers can and will continue to update their minimum version of PHP. If the status quo continues, it is not impossible to imagine a universe where many plugins/themes are running PHP 5.5+ while WordPress itself does not acknowledge this change. This would leave users, who we are not expecting to know anything about WordPress and PHP, frustrated because many of the plugins they try to install do not work.

A helpful step in the right direction, certainly for me as a developer - would be some ability to specify minimum PHP version compatibility. Composer allows this, and it would allow developers to code for newer version of PHP and make it immediately obvious to users that the plugin or even theme is not for their version BEFORE they try to install it, reducing confusion and frustration. Each disabled plugin could have a help link, "Why can't I use this?" which is an opportunity to teach users about older versions of PHP being EOL and to contact their administrator to upgrade their version of PHP. There could even be a sample script for users who didn't know what to say.

This, coupled with a very clear warning on WordPress upgrade (that although WordPress is compatible with PHP 5.2.9 and later, users will not be able to access many plugins without updating to a current version of PHP), could help to increase PHP upgrades, without requiring it.

Ultimately, WordPress is a mature project, and can probably get by with PHP 5.2-compatibility for a while yet. That doesn't mean that newer plugins are going to follow suit, and making it easy for users running outdated versions of PHP to spot it could be a minor solution if the major one can't be solved right now (which, again, I hope it can).

Last edited 17 months ago by seancjones (previous) (diff)

#88 in reply to: ↑ 86 @dd32
17 months ago

Replying to chris@…:

@nacin had a post about a year ago (scroll down to the Updated March 2 headline) where he partially answered the old PHP/old WP percentage question.

Is there anyway we can see PHP/MySQL versions broken down by what WordPress version they are running on?
We’re still working on ensuring the numbers are stable. They’re pretty predictable: older WP versions have more people on older PHP and MySQL versions. Newer WP versions have less.
PHP 5.2 is at about 16% for all installs right now. It’s at about 10% for installs running WordPress 4.1, but because 4.1 is such a large part of the pie (36%), it’s the WP version with the most PHP 5.2 installs.

I'd be curious to know if there's been an update on this.

PHP 5.2 accounts for 8.3% of all sites; Of those

  • 38% of the PHP 5.2 installs we track are running WordPress 3.x. ( ~3.2% of overall )
  • 62% of the PHP 5.2 installs we track are running WordPress 4.x ( ~5.1% of overall )
  • 32% are using WordPress 4.4 (~25%) or 4.5 - It's worth noting that 4.4 has the highest number simply as it accounts for the majority of installs at present. therefor, WordPress 4.0~4.3 accounts for 30%.

With every release of WordPress, the number of older PHP installs that get left behind increases, and that's expected as newly provisioned WordPress sites should more often than not be being provisioned with a more recent version of PHP.

The above numbers reflect what we saw a year ago, that although abandoned sites are more likely to run out of date PHP, that it's mostly an even spread over all versions.
If you take a look at WordPress 3.0~3.3 you'll find that 33% of them run PHP 5.2, compared to ~4.75% of WordPress 4.4/4.5 sites.

As a sidenote, I think WordPress 4.4 is the first release where by the end of the release, the PHP 5.2 usage number was below that mystical 5% line in the sand. Every release prior to that has wound up at close to 7% PHP 5.2 usage.

#89 @Sobak
7 months ago

Is there a change for update on this? Global PHP 5.2 usage dropped from 8.3% to 5.5% over the past 10 months. I assume you sadly still consider it too much to take any actions but can we know PHP 5.2 usage by current WordPress versions?

Codex says that the only officially supported version is WordPress 4.7.1, but I assume it might give us biased view on that. So maybe from WordPress 4.5 onwards? @dd32: you shared some pretty interesting data. Any chance on getting those for March 2017?

#90 @alexander.rohmann
7 months ago

If version requirements were introduced in a major release it wouldn't even matter. Hosts on old versions of PHP could still get the WordPress minor release security updates. It would take two major cycles. One in preparation that adds messaging, and blocks incompatible servers from getting major releases, then another to actually implement it.

But... it would seem the powers that be would rather continue disenfranchising plugin and theme developers than take a few minutes to think it all through.

#91 @Sobak
7 months ago

We both seem to agree on that matter. The migration certainly is possible and such way has been proposed several times already. Nonetheless, all that core developers keep saying is that it's "too early".

Maybe there is a tiny chance to agree upon what PHP 5.2 usage is acceptable. It's clear that it decreases but publicly available stats might include many abandoned websites which are not updated anymore and thus will not be affected by any minimal requirements bump. That's why I'd like to know what's the PHP version share across more recent WP releases.

Meanwhile, number of potential improvements postponed due to the ancient (over six years since EOL!) gets bigger and bigger... I also really struggle to understand why there is no interest in engaging more PHP developers to contribute by getting closer to today's standards. As you said, it can be done without leaving milions of users on unsecure versions (contrary to letting them use PHP versions with so many known vulnerabilities).

#92 @seancjones
7 months ago

The most conservative approach to this appears to be a no-brainer - raising PHP versioning while keeping the same coding standards for core and banning PHP godsends like namespaces and anonymous functions for the indefinite future, would allow for security backports without maintaining two versions, would do a great job testing the water, and would encourage new plugins to finally begin coding with efficient constructs that WordPress documentation endorses (forget where but there are various coding examples with actions and anonymous function pairings... A beautiful thing).

It would do a fair bit to encourage better plugins in the repository and would allow a user to do so just by specifying a minimum WordPress version.

No change to core code = no duplication for security backports. Tests the water. Applies pressure to hosts without harming user experience. Please, please do this.

Last edited 7 months ago by seancjones (previous) (diff)

#93 follow-up: @dd32
7 months ago

you shared some pretty interesting data. Any chance on getting those for March 2017?

I actually tweeted that data recently - https://twitter.com/dd32/status/834613251178508289

WP4.7-only stats of [PHP] 5.6 @ 43%, 5.4 @ 20%, and 5.5 @ 14%, PHP 7.x is @ ~10% leaving only 12% for PHP 5.2+5.3

  • PHP 5.2: ~2.5%
  • PHP 5.3: 9%
  • PHP 5.4: 20%
  • PHP 5.5: 14%
  • PHP 5.6: 43%
  • PHP 7.0: 10%
  • PHP 7.1: ~1.5%

(Note, these numbers are rounded, yet shockingly add up to 100%)

While PHP 5.2 for WordPress 4.7 is at <3% now, which is much lower than the ~5.5% figure which represents all versions 3.0~4.7, what those figures don't tell you is just how many people would be affected by a forced change.

On average, at every WordPress event you go to, 3 out of every 100 people are probably running PHP 5.2 - and have no idea what PHP is, there are hundreds of thousands (or millions) of people who are in that group of people.
You could say that those 3 people probably don't go to WordPress events, but you'd be surprised, they're the new users on bad hosts, those who have had a WordPress site that had just worked for the last 5+ years, they're the ones who rely upon WordPress doing it's job and running their site, taking away all the technicalities of publishing on the web.

WordPress isn't going to blindly drop support for those users - and we're not going to bump the required version of PHP while not actually requiring it - that user experience comes first.
Moving to PHP 5.3 gains core nothing, Moving to PHP 5.4 gains core nothing either - if there were features in those versions which were needed by WordPress - we'd have moved already.
Supporting the older versions in core does not bring a significant barrier to contributors, many new functions that we've needed (JSON, Hashing, PHP7 random functions, Multibyte and autoload) have been shimmed with PHP variants which allow us to use the functionality in the older versions - sure, it might not be as performant, but it works just fine.
If PHP versions prevent you from contributing to WordPress, submit the patch anyway and note it requires PHP 8, someone else can alter it to work back to 5.2 - determining what the issue is and what code needs to fix it is 90% of the work.

Plugins and Themes can require a higher version of PHP than what WordPress does. You do not have to support an outdated version of PHP or outdated install of WordPress - I don't support anything older than PHP 5.4 and WordPress 4.4 at present, that's a choice I've made, and every time someone contacts me (at least once a week) asking why the plugin doesn't work for them, I explain that the detailed error message meant they need to contact their host, you can do that too.

#94 @alexander.rohmann
7 months ago

Nobody said blindly drop support. The point of this conversation is to find a path forward. I've still not gotten any direct feedback on my major version proposal. Thoughts on serving PHP 5.2 users security updates only? (explained in more detail above)

While WordPress is a big part of the web, you can not deny that this fractures the development community as a whole.

WordPress has become an ecosystem unto itself, which for the PHP developer means it's incredibly difficult to work on either side of the fence. Perpetuating adherence to unsupported technology is just an ever growing technical liability.

You keep coming back to "users first" - then find a solution that keeps them first, but also moves things forward.

#95 follow-up: @dd32
7 months ago

Thoughts on serving PHP 5.2 users security updates only? (explained in more detail above)

That punishes users for something they don't understand or control, so no, it's not something that aligns with the WordPress philosophies and as such isn't something we'd do.

WordPress has become an ecosystem unto itself, which for the PHP developer means it's incredibly difficult to work on either side of the fence. Perpetuating adherence to unsupported technology is just an ever growing technical liability.

And one which you're free to do what you want within - like I said, you don't have to support WordPress 3.7, although WordPress still supports it by shipping security releases for it - did you know we're up to 3.7.18?, likewise, you don't have to support PHP 5.x if you don't want to, you can make your plugin PHP 7.x only if you want, you'll just need to educate your users who can't use it about how to update their systems - if your plugin requires newer features you're in a far better place to educate the user as to why you need it than WordPress is.


Yes, I'd prefer WordPress dropped support for PHP 5.2, 5.3 and even 5.4 - there's 1/3 of the WordPress 4.7 user-base right there, but I don't think it's an effort which at this time can be pushed by WordPress itself, some plugins such as Yoast SEO are planning to throw notices to older PHP users in an attempt to get their user base to update so that they can bump their minimum PHP versions, I'm eagerly awaiting to see how that goes and to see if it can form the basis of a larger push from the WordPress community as a whole, rather than relying upon WordPress core itself to be the driving force.

#96 @alexander.rohmann
7 months ago

I can appreciate that. Although, at some point someone is left with the bill. Those users may not understand, but that doesn't make them any less responsible.

It's off-putting that you say something doesn't align with core philosophies, then in the next breath encourage plugin developers to take actions that violate those philosophies. Pardon me for saying it, but it kinda comes off as lack of leadership.


I never said do it tomorrow, but I'm very concerned there isn't a plan written up.

WordPress is build around a 10 year old PHP version, that has been unsupported the past 6 of those years. I can't get my head around why that doesn't scream liability to everyone.

How much time is wasted backporting what should be modern code to meet old constraints?

When does it become more costly to continue this, than to bother 2.5% of users? Users who could very easily be instructed and led through an update process, or presented with a choice of options.

#97 in reply to: ↑ 95 @fightthecurrent
7 months ago

Replying to dd32:

it's not something that aligns with the WordPress philosophies and as such isn't something we'd do.

Philosophies can be amended, much like the Constitution. It's okay to say "We got this wrong the first time, here's an adjusted version of the philosophy."

In any other field, if a professional is aware that a service they're providing has an inherent issue (in our case, no security updates for the last 6 years), they'd be liable for a a complaint being filed against them to an ethical board and potentially having their license censured or revoked, and potentially even legal action taken against them. WordPress is knowingly not encouraging users who aren't aware of security threats to continue to use a version of PHP that is not maintained or supported anymore which may lead to their site being compromised. WordPress is the "authority" or "expert" in this situation and isn't taking measures to educate those users who are unaware there's an issue in the first place.

This is not putting the users first.

#98 @fightthecurrent
7 months ago

And just so I'm not criticizing without action, my solution would be what @alexander.rohmann is suggesting: let's at least put a plan together. WordPress can't keep supporting 5.2 forever.

#99 @Sobak
7 months ago

Exactly. Given enormous popularity of WordPress and thus scale of such migration, probably everyone is fully aware that it won't be matter of one month - let it be even a year (or more if it's justified), but apparently it can't be stressed enough - let's come up with a plan. A scheudle. Declare PHP 5.2 version share which is acceptable for you, if you're uncomfortable with blindly sticking to a date. Anything what can actually be discussed and we could reasonably respond to.

Repeating that it's "too early" and refusing to make any decisions seems like pretending that there is not problem at all. It's far from being constructive, not so say it's immature.

Last edited 7 months ago by Sobak (previous) (diff)

#100 follow-up: @pcarvalho
7 months ago

Hi everyone!

One of the things i find weird is that some are suggesting that dropping support for dangerously old php versions is going against users.

What would happen to them? nothing. At worst, these sites using php 5.2/3/4 and old wordpress versions will stay the same. If using latest version, they either upgrade php and wordpress or do nothing. Its their decision.

Why is WordPress banking the debt for this? Are there any other open source projects that take this responsibility? All i see is: update or you're on your own.

And what is being suggested here is: for those wp sites that are updated but using old php version, create a plan/documentation/support for them to upgrade. Its for their own good.

#101 in reply to: ↑ 100 ; follow-ups: @johnbillion
7 months ago

Replying to pcarvalho:

What would happen to them? nothing.

The "nothing" here is significant. Increasing the minimum required version of PHP would potentially result in hundreds of thousands of sites being "orphaned" on old versions of WordPress, and the project would be left with a security fix back-compat nightmare which is worse than it is now (security fixes are currently backported to 3.7 when appropriate and it's becoming more difficult with every new release).

#102 in reply to: ↑ 101 ; follow-up: @fightthecurrent
7 months ago

Replying to johnbillion:

Increasing the minimum required version of PHP would potentially result in hundreds of thousands of sites being "orphaned" on old versions of WordPress

I'll use a sweeping generalization here: every other open source project does this. And it's ok. Declaring EOL is a natural, healthy part of releasing software.

and the project would be left with a security fix back-compat nightmare which is worse than it is now (security fixes are currently backported to 3.7 when appropriate and it's becoming more difficult with every new release).

Just like PHP has an EOL, WordPress can do the same. It's up to the user to keep their software up to date. Software is like food: if it sits for too long, it goes bad. The burden of responsibility lies on the user to clean out their fridge, not WordPress.

#103 in reply to: ↑ 93 ; follow-up: @seancjones
7 months ago

Replying to dd32:

Plugins and Themes can require a higher version of PHP than what WordPress does. You do not have to support an outdated version of PHP or outdated install of WordPress - I don't support anything older than PHP 5.4 and WordPress 4.4 at present, that's a choice I've made, and every time someone contacts me (at least once a week) asking why the plugin doesn't work for them, I explain that the detailed error message meant they need to contact their host, you can do that too.

There are a few different points of view here. Mine is that I 100% agree that users should come first - it's an awesome thing about WordPress. I love it, and it's what's made it so popular.

Where I disagree with you is that what you're describing is a good user experience.

Imagine for one second:

  • PHP 5.2.* user and 5.3.* user does not understand what PHP is, and just wants a website. Installs WordPress. Is very excited!
  • Wants Tumblr Importer. Is really excited to get images from Tumblr on their website.
  • Plugin doesn't work. They get a detailed message explaining why it doesn't work, which they may or may not read/understand.

Putting myself in this user's shoes, if this happened for multiple plugins or themes, I would get frustrated. To make matters worse, each plugin developer has a different approach to handling this as there is no core solution in WordPress for declaring a PHP minimum version. This results in a truly terrible and confusing WordPress experience for the least technical people.

I am not saying raising the PHP minimum version is the only answer. I am saying that it feels pretty obvious to me that we can do a lot better as a community to help users with outdated versions of PHP figure out why their WordPress install is running like a 1989 Chevy Nova without an oil change, and getting worse every day. This is one approach, #23880 is another.

The arguments against doing something are compelling, but they assume that the only steps that can be taken would hurt the user experience and not help improve a bad one. It would be really nice if we could change the dialog to: How can we make the user experience better, supporting WordPress' core mission, while also addressing this PHP version issue in a constructive, conservative, and incremental way?

And in a quick response to @johnbillion:

the project would be left with a security fix back-compat nightmare which is worse than it is now (security fixes are currently backported to 3.7 when appropriate and it's becoming more difficult with every new release).

If it's already more difficult with every new release, is there a way to review this separate concern and apply those systems and structures to any upgrade decision? If you're already telling me that back-compat is tough, the status quo is going to become untenable in the future. Saying that is the reason not to upgrade PHP doesn't feel quite right to me.

Last edited 7 months ago by seancjones (previous) (diff)

#104 in reply to: ↑ 103 @fightthecurrent
7 months ago

Replying to seancjones:

It would be really nice if we could change the dialog to: How can we make the user experience better, supporting WordPress' core mission, while also addressing this PHP version issue in a constructive, conservative, and incremental way?

Well said, @seancjones!

#105 in reply to: ↑ 101 ; follow-up: @pcarvalho
7 months ago

Replying to johnbillion:

Replying to pcarvalho:

What would happen to them? nothing.

The "nothing" here is significant. Increasing the minimum required version of PHP would potentially result in hundreds of thousands of sites being "orphaned" on old versions of WordPress,

sorry to say this, but that's the actual reality. not sure about the numbers, but there's a good bunch of wordpress sites lost in the wild with no updates. Pandering to these sleeping beauties makes no sense to me. Its to the "updated wordpress+old php" that need attention.

and the project would be left with a security fix back-compat nightmare which is worse than it is now (security fixes are currently backported to 3.7 when appropriate and it's becoming more difficult with every new release).

how is dropping support a nightmare compared doing the backports to this 6/3/2 year old dead version of php? dropping support is to stop doing the fixes beyond 3.7 and version X for php.

@fightthecurrent said it nicely: EOL is A-OK.

#106 in reply to: ↑ 105 @seancjones
7 months ago

Replying to pcarvalho:

how is dropping support a nightmare compared doing the backports to this 6/3/2 year old dead version of php? dropping support is to stop doing the fixes beyond 3.7 and version X for php.

@fightthecurrent said it nicely: EOL is A-OK.

We don't even need to drop back compatibility for fixes, necessarily. It's more a matter of how this gets implemented and the policies surrounding it. If there is a larger issue about back compatibility becoming difficult, that's a separate can of worms, and, IMO, is not directly related to this. That process can either be revised or improved, and will be an issue if kept as-is, regardless or this decision. Likewise, it might be able to be made easier to backport to 3.7 and that could be the case regardless of a change in PHP version. I do not think the two issues should be conflated based on comments here.

#107 follow-ups: @jdgrimes
7 months ago

Speaking of WordPress philosophies, I've had a thought on this that I've declined to voice up until now, but here it goes. One of WordPress's development philosophies is the 80% rule. Any feature that doesn't benefit 80% of users doesn't belong in core. While that is about user-facing features, can't we at least agree that the same type of logic really has to be applied here at some point? Right now we are holding the entirety of WordPress core hostage to 5% of users. Putting in so much effort to please a small number of users is silly, which is why the 80% rule exists. I think that if the average user knew that WordPress was putting a large amount of effort into not breaking 3% of user's sites, rather than building new features or fixing real bugs, they would be disgusted. Sure, everyone is pleased that we want the best for users, but building WordPress 20.5 to run on a PHP version that 5 sites are still hanging onto is ridiculous. Obviously, that isn't something that anybody is suggesting should happen here. The question this ticket is trying to resolve though, is what exactly is going to happen? And until there is an actual discussion where the core devs are helping develop a strategy instead of saying "not yet", many developers are going to remain frustrated. As pointed out above, if WordPress doesn't lead on this, forcing plugin authors to take the initiative, the developer community is going to fragment, and as a result UX is going to be degraded.

So OK, maybe we're not going to come up with a 95% rule for PHP versions. Maybe we want to be more pragmatic here (and that's probably good). But it is very frustrating when there is no end in sight, when there doesn't even appear to be any desire to even begin the process of preparing to prepare core for this. For all we know, WordPress 20.5 will still support PHP 5.2, because there seem to be no plans whatsoever to strategize actually updating the PHP version someday. It is almost as if we are hoping to ignore the problem and then it will go away. We know that isn't the intention, and that the goal is doing what is best for users. But we'd like some of the core devs to reconsider whether this is still the best thing for users at this point, or at what point continuing to support outdated PHP versions is no longer going to be the best thing for users. At some point it isn't anymore. I think everyone agrees on that. Somehow though, we're able to disagree about whether we should talk about when that point is, and how to prepare for it.

Huh, when put that way, it is actually kind of humorous. :-)

Actually though, after considering the recent replies to this ticket, a sort of strategy has been outlined, though it needs some polish:

  • Wait.
  • Let plugins do the legwork.
  • At some point, as yet undetermined, up core's requirement.

Others have already objected to different parts of this strategy, so I won't bother with that. I will say though, that if this is the way that we are going to go, then WordPress should encourage it by reducing pain for users as plugins start becoming incompatible. Otherwise this is pretty certainly not the best experience for users. #23880 would seem to be a must.

Also, even given that, it still doesn't invalidate the point of this ticket. WordPress core will still need to prepare to update, and still need to come up with some idea of when it will do that (IMO).

Finally, I'd like to echo @fightthecurrent's reply to @johnbillion: we should also be strategizing when and how to EOL WordPress 3.7. The 80%-rule type logic applies there too. Backporting indefinitely risks bringing the development of new features to a complete halt. Not in the best interest of users. At some point we have to stop rewarding irresponsible users at the expense of responsible ones. It is just wrong. OK, they are really just ignorant. Then educate them. If they don't take action, then they are definitely irresponsible. Being irresponsible means that bad things happen sometimes. Like your site getting hacked. As others have said, it is called life. This isn't being callous, it is seeing a problem that will eventually place a drag on the entire project, and taking the initiative to inform the affected users so they can fix it.

#108 in reply to: ↑ 107 @fightthecurrent
7 months ago

Replying to jdgrimes:
👏 👏 👏 💯 🔥 🔥 🔥

#109 in reply to: ↑ 107 ; follow-up: @chris@…
7 months ago

Replying to jdgrimes:

One of WordPress's development philosophies is the 80% rule. Any feature that doesn't benefit 80% of users doesn't belong in core. While that is about user-facing features, can't we at least agree that the same type of logic really has to be applied here at some point?

Unfortunately the corollary to that is that the 20% should be able to be made up by plugin developers and themers.

Right now we are holding the entirety of WordPress core hostage to 5% of users.

I assume that the 5% means the 5.2 people, right? So were basically talking about using namespaces and anonymous functions in core files? That's really the two big changes between 5.2 and 5.3 (unless you count goto) and doesn't really seem to be a deal breaker to me.

All of my code targets PHP 7 unless I have a specific client request or I'm making an public plugin, so I personally want to up these numbers, too. But core's perspective is that those percentages, even if they seem small to us, actually turn into a lot of customers and those customers, in various manners, turn into dollars.

Putting a PHP version check in a plugin in activation/load (since PHP versions can change on the fly) is probably the safest and easiest thing to do.

#110 in reply to: ↑ 109 @alexander.rohmann
7 months ago

It's really nice to see some revived interest here. Thanks to everyone for chiming in.

@seancjones Some great points about user experience. This also echoes some of @jdgrimes comment. If I was part of that 2.5%, I'd would gratefully welcome someone telling me that I'm paying a web host for 10yr old defunct technology. But it would seem we're more afraid of "punishing" them. Feels like an irresponsible enablement of ignorance at the expense of progress.

How far would one friendly dashboard notice go?

"Hey guy, you're on a really old PHP version. You should consider asking your host to upgrade. Read this article for more info"

That's a pretty simple place to start without punishing the users, while lighting a fire under negligent hosts.

Last edited 7 months ago by alexander.rohmann (previous) (diff)

#111 in reply to: ↑ 102 ; follow-ups: @jorbin
7 months ago

I'm really not sure what many of the comments here are about, but they don't seem to be about coming up with a strategy for upgrading the minimum version of PHP. They aren't suggesting concrete plans for when the minimum version increases process should be triggered( Is it when we hit 1% of all sites? 0.5% of the last two major versions? something else?) or what that process should look like ( Is it a 2-year process, a 4 major release process, or something different? What are the steps of the process?). "Just do it" isn't a process and that level of hostility towards millions of users isn't something I'm comfortable with.

One thing that I think predates implementing any sort of process is coming up with some user level educational materials about 1) What PHP (and for that matter, MySQL and other server technologies) are 2) Why new versions are important and 3) How to go about upgrading. I would love to see someone step up and own the creation of that matterial.

#112 follow-up: @alexander.rohmann
7 months ago

@jorbin Looks like we posted at around the same time. Thoughts on my previous comment? We seem to be trending on an idea. User education would be super valuable. It does risks putting outdated hosts in a bad spot because the curtain gets pulled back, but that might not be such a bad thing after all this time.

#113 in reply to: ↑ 112 @jorbin
7 months ago

Replying to alexander.rohmann:

@jorbin Looks like we posted at around the same time. Thoughts on my previous comment? We seem to be trending on an idea. User education would be super valuable. It does risks putting outdated hosts in a bad spot because the curtain gets pulled back, but that might not be such a bad thing after all this time.

A dashboard notice was considered in #9751 and while I was originally in favor, without a large amount of educational information (much more than could or should reasonably fit in a notice), it doesn't solve anything. It just becomes either a notice for users to ignore or if not worded really well, argumentum in terrorem.

#114 in reply to: ↑ 111 @jdgrimes
7 months ago

Replying to jorbin:

I'm really not sure what many of the comments here are about, but they don't seem to be about coming up with a strategy for upgrading the minimum version of PHP. They aren't suggesting concrete plans for when the minimum version increases process should be triggered( Is it when we hit 1% of all sites? 0.5% of the last two major versions? something else?) or what that process should look like ( Is it a 2-year process, a 4 major release process, or something different? What are the steps of the process?).

Well, just about everything possible has probably already been proposed in very general terms. The reason why it keeps going in circles is that nothing that is suggested seems to gain any traction with core devs.

"Just do it" isn't a process and that level of hostility towards millions of users isn't something I'm comfortable with.

I'm not sure anyone has really suggested that, and I think everybody applauds the fact that WordPress is putting users first. If it comes across otherwise, apologies.

One thing that I think predates implementing any sort of process is coming up with some user level educational materials about 1) What PHP (and for that matter, MySQL and other server technologies) are 2) Why new versions are important and 3) How to go about upgrading. I would love to see someone step up and own the creation of that matterial.

I 100% agree. I would point out though that this is a 180° turn-around from the previous stance, which seemed to be that users should never have to know anything about this technology. So I absolutely agree that we should revisit the admin notice idea with good docs for all of this in place. Here are some user docs regarding PHP that I recently wrote up for a plugin, in preparation for potentially upping the PHP version in the future. It is partly based on BuddyPress's docs.

#115 in reply to: ↑ 111 @fightthecurrent
7 months ago

Replying to jorbin:

I'm really not sure what many of the comments here are about, but they don't seem to be about coming up with a strategy for upgrading the minimum version of PHP.

My proposal: no later than whenever a version of PHP gets EOL'd, regardless of user share. WordPress can potentially still run on older versions of PHP, but they wouldn't be officially supported.

#116 @CyberCr33p
7 months ago

In my country we say: You can't make an omelette without breaking eggs. But you don't need to break many eggs in this case.

Most servers running old PHP versions use old and outdated OS version. I am sure that the wordpress versions running in these machines are old too. Most users with old wordpress versions don't know or don't care for security and they will stay in the same old wordpress version for ever (or until someone hacks them).

To show a message in dashboard to notify for upgrading php will not help these users either, because to see the message they need to have a newer wordpress version that supports auto-updates.

In fewer words, if you change the minimum php version it will not case any trouble to most people with old wordpress versions.

Also someone that doesn't upgrade wordpress and plugins (and any other CMS) is a security threat for all the internet users (spam, phishing, ddos, etc).

#117 in reply to: ↑ 111 @Sobak
7 months ago

Replying to jorbin:

I'm really not sure what many of the comments here are about, but they don't seem to be about coming up with a strategy for upgrading the minimum version of PHP.

I hope @jdgrimes explained reason for such impression. To me, it looks like people were waiting to see actual arguments and feedback from the core developers and it's great it happened!

One thing that I think predates implementing any sort of process is coming up with some user level educational materials about 1) What PHP (and for that matter, MySQL and other server technologies) are 2) Why new versions are important and 3) How to go about upgrading. I would love to see someone step up and own the creation of that matterial.

Absolutely fair point. I propose to make it open and collaborative effort, perhaps using GitHub.

If you are asking for suggested strategies and concrete ideas, here are mine.

  1. Start joint effort on educational materials which would be linked from the dashboard.
  2. Revive #23880 to improve UX. Personally, I think it would be good to contact guys working on Yoast whip package to make use of their ideas and also make sure the work isn't duplicated without a need.
  3. When looking at PHP 5.2 (or any other PHP version) usage metrics, focus on last two major releases of WordPress. People running older versions probably just abandoned their installs.
  4. I wasn't able to find out much about WordPress release process so I don't know if there is any strict scheudle for releasing new major versions and how often it happen. For now, let me suggest three major releases cycle (so it results in about the one year if I'm not mistaken). First release to just inform people that WordPress is looking for new possibilities and improvements and thus they should know what the hell that PHP is and why running old version is bad for them. Second release to inform that it's last branch (in terms of software management) compatible with their current environment (provided with educational materials, of course) and third release to actually bump the requirements.
  5. Bump to PHP 5.3. When it comes to further updates strategy, I think 5% of versions share (across two most recent WP releases) is safe time to start that three-releases cycle I talked about. Probably it's still more tolerant than what most software does so hopefully it would fit WordPress philosophy of putting user first (which I absolutely agree with, to be clear)

Looking forward to hear your (and others) opinion on that! Thank you for your efforts of finding a consensus.

#118 @jdgrimes
7 months ago

I two more thoughts on this last night:

  1. Building docs and possibly adding a notice eventually is something that is going to need input from the UX team or whoever can help us do usertests. Sometimes it is hard for us to really know how a user is going to respond to something like that in real life. Non-devs will need to be heavily involved.
  2. As far as time based vs percentage based in terms of deciding when to update, I don't support an entirely percentage-based approach. Of course, the percentage does need to be taken into account, but I think that a time factor has to be there as well, and here is why. If we just say, for the sake of example, that we're going to drop support once a version reaches 5% usage, then we are basically always going to be leaving approximately the last 5% of users on an unsupported version. Even if everybody is more proactive about staying up to date, that just means that we get to 5% quicker. Some people will still come in last, even if they aren't taking years to update. That's why there needs to be a deadline component. If we set a date 6 months or a year ahead of time, that gives everybody enough time that potentially when the deadline comes there is nobody still running that version. I realize that won't actually happen, but you get the general idea. A large number of that 5% is given a better chance of getting updated in time, probably by their hosts, and never even having to deal with this.

So basically, I'd recommend something similar to @Sobak: once we approach 5% (or whatever number), we should set a date 3 releases into the future. Maybe during that first release cycle, we are basically just giving hosts a chance to get their users updated so that the users themselves never have to deal with it. When the second release comes around, we will have it begin warning users about the impending requirement update. (Actually, depending on how the infrastructure is built, this wouldn't necessarily have to coincide with a release, I guess. But it does make sense to tell users, "get ready for the next version of WordPress.") Then in the third release, the requirement would officially be upped, and new features could be introduced in that release that required newer PHP features.

If we started work on this now, we could try to up the requirement in WordPress 5.0, which has a nice ring to it even if WordPress doesn't follow semantic versioning.

However, what percentage to actually use is the question. Given about 60 million WordPress installs (the number quoted on the homepage), 5% = 3 million people. However, based on the numbers that @dd32 shared above, we know that the latest 4 versions of WordPress (4.4-4.7), likely represent about half of that right now. These are the people who are the most likely to actually update WordPress in the next year or so, and they are a full 3/4 of all WordPress users. Of that majority of users who mostly haven't abandoned their sites then, that 5% actually becomes just 1.5 million people. But wait, the percentage for those newer versions isn't 5%. 4.4 was the first version that came in under that, about 4.75%. 4.7 is at ~2.5%. So we are talking about something like 3.5-4% of these users here. Which comes out to closer to just 1 million installs. Yes, that is still a lot, but remember that it is actually less than 1.75% of all WordPress installs. That is the percentage of WordPress users who are likely going to actually want to update in the near future and not be able to due to their PHP version, assuming that we dropped PHP 5.2 today. But say that it takes us about a year? The total number of installs on PHP 5.2 will only be about 3.3% then. (Yes, I keep track of all this with equations and graphs. :-) That's about 2 million total installs, which would come out to something like 500k installs in the latest 4 versions at that time, the ones where most users are going to update from. Which will be something like 0.8% of WordPress's total userbase.

500k is a big number. But I don't think it is unreasonable. In fact, I'd say that if we set a date now (like WP 5.0), and communicate that to hosts, it might end up being significantly lower by the time we feel like we need to begin actively trying to educate the affected users about the situation.

As others have mentioned, I think that ideally the ultimate goal would be to get to a place where we only support non-EOL PHP versions. That isn't going to happen overnight, obviously, and for the next few years, maybe even 5, we'll have to just drop EOL versions one by one. But eventually though, we should get to the place where there are few enough users using EOL versions that we are comfortable switching to a PHP version support routine that is based on PHP's schedule. The PHP release schedule seems generous enough on its own that at that point it should give users and hosts sufficient time to update as each version approaches EOL.

#119 follow-ups: @seancjones
7 months ago

@jdgrimes Great document! I modified it, hope you don't mind. It's in a Gist. Feel free to fork and make any changes. If you recommend a better location I'll put it there.

https://gist.github.com/smcjones/6a46957b6a89568243350ac0f395db85

Note:

I reference colors in the gift. This is related to the thought I have below. It seems to make sense to put this in the dashboard and provide the UX folks with information like recommended PHP version. Because a picture is worth a thousand words, I believe color coding would be very helpful. Just to throw out some - maybe bad ideas as I know there is color blindness out there:

Green - Good - display positive message, you are up-to-date (WordPress recommended minimum version)
Yellow - OK - display cautious message: could be better, but not the end of the world (PHP supported version)
Red - Danger! - display urgent message: Upgrade version ASAP.

Last edited 7 months ago by seancjones (previous) (diff)

#120 in reply to: ↑ 119 @Sobak
7 months ago

Replying to seancjones:

@jdgrimes Great document! I modified it, hope you don't mind. It's in a Gist. Feel free to fork and make any changes. If you recommend a better location I'll put it there.

https://gist.github.com/smcjones/6a46957b6a89568243350ac0f395db85

Hi!

Thank you, it's definitely something to begin with. I would suggest to make it a repository, though. Gists are nice for fast prototyping of documents but they lack pull requests support. Sure, what's happening it's totally unofficiall but I still believe this work could be used somehow later on.

#121 in reply to: ↑ 119 @jdgrimes
7 months ago

Replying to seancjones:

@jdgrimes Great document! I modified it, hope you don't mind. It's in a Gist. Feel free to fork and make any changes. If you recommend a better location I'll put it there.

https://gist.github.com/smcjones/6a46957b6a89568243350ac0f395db85

Cool. I agree with @Sobak that we're probably going to want a full repo for this though. Not only does it support PRs, but it also allows us to break out discussion of each point into separate issues, instead of continuing to grow this already huge ticket. Eventually that should probably be under the WordPress organization on GitHub, but I guess there is nothing stopping us from going ahead and creating a repo, that can be transferred to there later.

I reference colors in the gist.

I think this is an interesting idea. I think we're still a way from the point where we could do the yellow vs green though. Eventually it might be nice, but it requires user education, and we still need to test the waters regarding how easy/beneficial it is going to be to educate users about this. Even if the core devs admit that some education effort here might be necessary, I think that they'll probably want to keep that to a minimum.

So I think we should focus on starting small, just educating those users who are using the oldest version of PHP, and see how that goes. Then we could think about green and yellow users.


For those who didn't see, @jorbin brought this up in the last core dev chat in Slack, suggesting that version support procedures for all of the different technologies used by WordPress should be discussed at the upcoming community summit. High-five to him for his continued willingness to wrestle with this stuff.

#122 follow-up: @seancjones
7 months ago

I'll hold off until I get word from @jorbin. This is now in Markdown anyway.

Not sure what you mean about "still a way from the point where we could do the yellow vs green though". Colors/graphs of any kind are a very, very good teaching tool. I understand not wanting to make someone feel panicked if they're "Yellow" and maybe just have "green" and "red", or something equivalent UX people like.

But people do NOT read, they DO look at graphs.

#123 @alexander.rohmann
7 months ago

@seancjones That's great stuff!

Anyone remember this? http://browsehappy.com/

I think something more designed, and engaging as an informational site could be cool. It would be pretty easy to get up on GitHub pages. I bought http://codehappy.org/ a while back in anticipation of something like this and would be happy to point it to a site made for this cause.

#124 in reply to: ↑ 122 ; follow-up: @jdgrimes
7 months ago

Replying to seancjones:

Not sure what you mean about "still a way from the point where we could do the yellow vs green though". Colors/graphs of any kind are a very, very good teaching tool. I understand not wanting to make someone feel panicked if they're "Yellow" and maybe just have "green" and "red", or something equivalent UX people like.

But people do NOT read, they DO look at graphs.

I agree that when we present this information to users, that this is a good way to do it. I'm just cautioning that if we are talking about presenting this to everybody within the admin panel, the core devs are going to be very hesitant to do that. Trust me, I've memorized all of the talking points. :-) I think that if they will agree to pursue educating users about this at all, they'll want to test the waters first. (And really, it would be easy to get this wrong and end up scaring people, so that's a good thing.) I like @alexander.rohmann's idea of eventually doing something similar to browsehappy as well. I just think that if we try to jump in with both feet, the core devs will just try to shut down the whole education idea.

As far as the parallel between this and browsehappy goes, note that folks will be quick to point out that one difference is that many users actually know what their browser is, what it does, and most of them can update it (actually, not all though). But in this case, many users know nothing about PHP, what it does, and they don't have any control over what version they are running. I think though that as far as that last point, users are probably gaining more control over what PHP version they are running. Possibly most of the remaining users are on crummy hosts and don't have any control though.

This isn't to argue against the idea, just to prepare you for what has been said about the idea before. I think that before the core team and the support team are ready to OK something like this, they're going to want some proof that it is feasible and worth the effort. Which is why at this point we'll probably have to thing minimalistically in regard to scope (how many users are exposed to whatever we come up with), though I guess really that doesn't have to necessarily cramp the method that is used—something like brosehappy is one good idea, but probably only shown to the users running the very oldest PHP version (5.2).

#125 in reply to: ↑ 124 ; follow-up: @seancjones
7 months ago

Replying to jdgrimes:

I agree that when we present this information to users, that this is a good way to do it. I'm just cautioning that if we are talking about presenting this to everybody within the admin panel, the core devs are going to be very hesitant to do that.

Excellent points. Thanks for voicing the head devs. It's easy to forget the incredible responsibility of running the largest CMS in the world. I am always trying to push things forward, but I also work in IT. Don't want to be the next AWS!

Clearly I didn't fully consider the mass hysteria that could result. What you' said got me thinking in a different direction entirely. Mainly, what is the absolute smallest educational step that can be made that still goes a long way to moving a plan forward?

We talk about tech a first as devs but one of the best places to start testing out the message and it's efficiency is at WordCamps and meetups. A lot of users go and they're already highly engaged. I know the medium is different than web, but it has a lot of appeal, not least of which is that it engages the community directly. Perhaps it could be an early foray into a broader strategy where user input is directly requested/received.

A talk like "How to not get hacked" with a few topics, especially upgrading PHP, and time for discussion, could help shed light on the greater strategy. Even if it takes a while to finalize a plan that takes still longer, I think a lot of us would be happy to finally see some headway.

#126 in reply to: ↑ 125 @jdgrimes
7 months ago

Replying to seancjones:

I think exploring some of this with users at WordCamps is a great idea. Finding out how users actually feel about having this information shared with them is really going to be imperative. And it could potentially re-frame the entire conversation here, because the goal is to put users first. If it was demonstrated, for example, that most affected users actually want to know this information, it would contradict the general consensus, which is that they really don't want to know or care about this. I can imagine that for a portion of them though, they'll feel that knowledge is power. We really won't know for sure until we do some research. So far we've just been more or less making assumptions based on the best knowledge that we have—the experience of those that regularly interact with average users on the forums, etc. (Which actually, I expect won't prove too far off, but you never know what you don't know.)

Of course, the average WordCamp attendee likely isn't a complete analog for the average WordPress user. But it would probably still be a good place to begin.


I was thinking last night that really one thing we should be doing here is researching what strategies other large CMSs have employed regarding PHP version upgrades. Certainly WordPress is in a class all its own in terms of the size of its user base, but there is still probably a lot that we can learn from the experiences of similar, if slightly smaller, projects:

  • What is their policy regarding PHP version support?
  • When they drop a PHP version, how do they communicate that to users?
  • How do they communicate that to hosts?
  • When they have dropped versions in the past, what has the fallout been?
    • How many people were upset?
    • How many people just quietly updated?
    • How many people didn't update and were just left behind on the old version of the software?
    • How many people needed help from support?
    • How did web hosts respond? (Did they get most users updated ahead of time, etc.)

I think that one practical number to consider when coming up with a percentage/number of users at which to drop a PHP version, is the support burden that will be generated, and what the forum volunteers can handle. If 10% of users require some kind of support in order to update their PHP version, out of 500k users that's 50k users who will be seeking support in addition to the normal burden. That wouldn't happen all in one day, of course, (and these numbers are completely made up so they may be unrealistic), and I don't know what the average support load is right now, but that sounds like it would probably be overwhelming. Which is why the Half-elf Support Rogue has always been against trying to tell users anything about PHP.

(Yes, a lot of that support should really be directed at hosts, but some people, especially frustrated ones, are going to come to WordPress for help, to vent, etc.)

#127 @jdgrimes
7 months ago

I think it might be useful if I explain why I, as a responsible plugin developer, felt compelled to prepare to possibly update the PHP requirements of my plugin. While of course there are some nice "candy" features that newer PHP versions have (and some that are more substantial), that actually hasn't really informed my decision. Nor has it been just an aversion to encouraging the use of outdated PHP. It is much more practical considerations, specifically relating to user experience, that have lead me here. I am sure that to some degree these same things inform other developers' decisions about this, so I think it is worth explaining in depth.

In a word, it is the maintenance burden, but I realize that doesn't tell the whole story. After all, it is often pointed out that WordPress has been able to remain compatible with older PHP versions without too much of an undue burden. But the burden is significantly greater for plugin developers, and so let me explain why, and why I believe that WordPress needs to take this into account.

To ensure continued compatibility with each supported PHP version, WordPress runs its test against each on Travis CI. I do the same thing with my plugin, but there is an added catch: I also need to ensure compatibility with each version of WordPress that my plugin supports. WordPress only needs to run against 7 different build environments (PHP 5.2-7.1), with PHP nightly also added to keep an eye on compatibility with the next version of PHP. But my plugin needs to run against each of those versions of PHP in combination with each supported version of WordPress. Even when I limit support to the last two versions of WordPress, that comes out to 21 different build environments: 7 PHP versions x 3 WordPress versions (4.6, 4.7, and trunk).

This isn't unbearable, and if that was the extent of the issues, then I would happily continue to support as many PHP versions as WordPress does. But that isn't where it ends. Because in addition we have to consider plugins that integrate with other plugins. When we throw this into the mix, even when only the latest version of the other plugin is supported, the number of builds is multiplied by 2: 21 x (stable + development versions of the other plugin) = 42.

Even that isn't too unbearable, but here is where the real kicker comes in. My model is developing extensions for my plugin that integrate it with other plugins. So now we are talking about testing the extension against each version of the plugin that it supports, each version of the other plugin that it supports, on each version of WordPress that it supports, on each version of PHP that it supports. Once again, even if we limit the extension to only supporting the latest version of the plugin that we extend, our builds multiple by 2: 7 PHP x 3 WordPress x 2 other plugin x (stable + development of extended plugin) = 84. That is approaching the unreasonable and the unmaintainable, and adding one more PHP version to the mix adds 12 more build environments to test against.

Ignoring for a moment the ability of Travis to handle this number (which it can, but it starts to feel like abuse to me at a certain point), the fact is that maintaining compatibility also requires actual fixing issues brought up by build failures that relate to specific combinations. At a certain point it just becomes too much of a burden for a plugin developer to try to handle.

Which is the reason that I decided I had to prepare to start dropping PHP versions if WordPress itself doesn't soon (which would seem almost miraculous).

Not every plugin developer is in this exact situation of course, but the general fact of maintenance burden, as well as other reasons that are often brought up, mean that more and more plugin developers feel compelled to diverge from the PHP requirements of WordPress.

As a result, more and more users are going to have to encounter the PHP version issue anyway, regardless of what core does. But unless we take the initiative, it is not going to be a positive, educational experience that we have carefully tailored for them to make the whole thing as smooth as possible. Instead it is going to be a hodgepodge of different experiences involving different plugins. Some of those experiences may be pretty good (though if I do say, I think we can do better if we try), and some of them... won't be. Like:

  • The plugin developer doesn't respond to the users' support request.
  • The plugin developer hasn't communicated this very well to start with, so most users are just confused, and FUD sets in.
  • The plugin developer decides to up the requirement for an existing plugin, and when users update it breaks their site.
  • Or, even if it doesn't break their site, the plugin just stops working. (Instead the update should be prevented, as BuddyPress did, and I've done in my plugin. As a side note I hope that helps set the record straight about whether I care about the users. :-)

At the very least, even if the approach recommended by @dd32 is followed and we continue to promote the plugins-first approach here, we should try to unify the experience of users so that this experience gives them as little frustration as possible. The only way to really do that in an ideal fashion though, IMO, is if core actually steps out and takes the lead here, so that plugin developers don't have to. But maybe there is room for discussion there.

The main point is, that users are going to encounter the PHP version issue through WordPress, and it is up to core/the core community to ensure that encounter is positive and educational.


One other thought that I just had (and yes I know, I talk too much sometimes :-):

There is going to come a day when WordPress is going to have no choice but to drop older versions, if it wants to continue supporting the latest versions. It may be far into the future, but at some point PHP 8 is going to come out, for example, and code compatible with PHP 8 is not going to be compatible with PHP 5. (I don't recall the specific example that brought this to mind, but it has to do with things deprecated in PHP 7, IIRC, possibly other issues too.) So, if for no other reason, WordPress is going to have to come up with a strategy here that will bring up the minimum version to 7.0 by the time PHP 8 comes out. (Could be decades, could not be, I don't really know if there is any way to know at this point.) Currently, most people who are updating appear to be updating to PHP 5.6, so it is possible in theory that this will be an issue. Let's go ahead and begin testing out strategies now, before it ever gets to the place where it becomes a necessity. (Possibly even something presently unforeseen could cause it to become a necessity, so it is best to be prepared.) Hopefully though, by that time hosts will have their act together on this. But yeah, I'm not going to hold my breath.

#128 follow-up: @aristath
7 months ago

In 2010 WordPress dropped support for PHP4 so this is not unheard of: https://wordpress.org/news/2010/07/eol-for-php4-and-mysql4/
I'm sure was a process for this... Why don't we just follow a similar process now?

#129 in reply to: ↑ 128 @jdgrimes
7 months ago

Replying to aristath:

In 2010 WordPress dropped support for PHP4 so this is not unheard of: https://wordpress.org/news/2010/07/eol-for-php4-and-mysql4/
I'm sure was a process for this... Why don't we just follow a similar process now?

Yes, I actually intended to mention that before. I was not around yet back then, but I've heard some of the core devs talk about it before, and apparently it didn't go too well. I'm kind of shady on the details though.

I think that it would still be helpful to take a look at the process used, even though we probably don't want to follow it now, just to understand what went wrong so we can avoid repeating the same mistake. (Which is why the devs are so hesitant here: they are afraid that many of the proposals would just end up repeating the same mistake.)

#131 @jdgrimes
5 months ago

For those that have not heard about it, the Yoast SEO plugin is currently doing an experiment with asking their users to upgrade to a newer version of PHP.

https://wptavern.com/yoast-seos-php-upgrade-nag-is-producing-a-significant-increase-in-sites-upgrading-to-php-7

This is a useful experiment because the plugin has a large user base, and it should test the theory of how well an update nag relating to PHP would be received. So far, it appears that most users are responding positively, and are thankful that their sites are now faster and more secure after updating.

At some point, I expect that Yoast and the plugin directory team will do a postmortem to see how well things worked out, and we'll be able to use that knowledge to inform a decision about whether a notice might work in core.

My own off-hand observation is that circumstances favor a notice today more than they did in the past. I think more users are probably more technically savvy and lest tentative about this, even if they don't know what PHP is. Most importantly, most users also now have some control over what PHP version their site is running on, many of them just don't know it. And finally, the benefits of updating can sometimes be immediately obvious (a site can decrease load time by half in some cases, while at other times of course there may be little difference if caching is used). So I know that the powers that be are taking note, and perhaps will reconsider the PHP-update-notice moratorium.

This ticket was mentioned in Slack in #core-php by swissspidy. View the logs.


3 months ago

#133 @jdgrimes
2 months ago

For those who haven't heard: two new tickets relating to this have been opened (#41191 and #40934), and it was also discussed at the inaugural meeting in the #core-php channel in Slack. I think it will be talked about more at the next meeting as well (meetings are on Mondays at 18:00 UTC). I'd encourage everyone to join in on that discussion to help move this forward.

The general takeaway from the last meeting is that we want to explore ways to encourage users to use newer versions of PHP, including admin notices in core, raising awareness in various ways, upping the minimum requirements of major plugins, etc.

#134 @jdgrimes
2 months ago

Meeting notes were just published: https://make.wordpress.org/core/2017/07/12/php-meeting-recap-july-10th/

(Sorry for spamming, I should have waited just a little bit longer before posting my last comment!)

This ticket was mentioned in Slack in #core-php by jdgrimes. View the logs.


2 months ago

This ticket was mentioned in Slack in #core-php by jdgrimes. View the logs.


7 weeks ago

Note: See TracTickets for help on using tickets.