Proposal: Dropping support for old PHP versions via a fixed schedule – Make WordPress Core

Proposal: Dropping support for old PHP versions via a fixed schedule – Make WordPress Core
Skip to content
Make WordPress Core
Welcome!
The WordPress
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a
bug
bug
A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.
Create a ticket
in the bug tracker.
Want to contribute?
Get started quickly with tickets marked as
good first bugs
for new contributors or join a
bug scrub
. There’s more on the
reports page
, like
patches needing testing
, and on
feature projects page
Other questions?
Here is a detailed
handbook for contributors
, complete with tutorials.
Communication
Core uses
Slack
for real-time communication. Contributors live all over the world, so there are discussions happening at all hours of the day.
Core development meetings are every Wednesday at
15:00 UTC
in the
#core
channel on
Slack
. Anyone can join and participate or listen in!
While most people here will probably mostly know me as a (
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
) developer, I actually have a background in business studies, so when Matt Mullenweg reached out to me to continue the conversation about WordPress dropping support for older PHP versions in an in-person call, I decided to put my business acumen to use and see if I could come up with a proposal which would make sense from a business point of view for all parties involved, be it the amazing contributors to the WordPress project, the web hosts, the
plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
and theme builders, the web agencies and the users who often run their business via their WordPress website.
In short, I’m proposing a fixed schedule in which every PHP version is supported for five years. Additionally each WordPress release will receive security updates for four years. In effect, this means that users, at a stretch, would be able to run on one specific PHP version for nine years.
A fixed schedule will make this whole process transparent and will allow all parties to plan for the version drops accordingly.
With Matt’s blessing, I’m posting this proposal here on Make to gauge the reactions of the wider community to my idea.
Please feel very invited to leave a comment whether you agree with the proposal or not.
Mentioning what your involvement is with WordPress and how this proposal will impact you in a positive or negative way, would be very valuable input for further discussions on this.
Chicken vs egg
The situation we are currently in, is basically one of “Which came first, the chicken or the egg ?”.
WordPress doesn’t drop support for older PHP versions until enough users have moved over to newer PHP versions and a significant enough share of the WP users don’t upgrade their PHP version until they
really have to
because WordPress drops support for the version.
This is circular logic, which as most developers know, never ends well as you end up in an infinite
loop
Loop
The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post.
where, in the end, neither moves forward.
So who are these users who don’t upgrade ?
Well, while we can’t know for sure, if we look at the figures, we can see some patterns:
Take note of the fact that the percentage of users on WP 5.1 who didn’t upgrade yet is relatively small and only part of that can be attributed to the PHP < 5.6 version drop in WP 5.2.
So let’s look at some likely personas for users who don’t upgrade:
We have the
“zombie”
persona, sites which are still online, but are not actively updated anymore.
These can be, for instance, sites which were linked to a specific event or other date-related topic which are still online for historical reasons, aggregate sites which automatically re-post from other sites without
admin
admin
(and super admin)
involvement, or spam sites etc.
We have the
“overwhelmed”
persona, who blatantly ignores all admin notices. We all know why and how this happens. The multitude of notices in the admin area once a site has a few plugins and a theme installed
trained
this user to ignore them.
Then there is the
“laid-back”
persona, who has seen the notices, but doesn’t feel any urgency until they can’t update their site anymore.
And lastly, the
“business”
persona, often with a custom theme and a number of custom build plugins who’d rather move the costs of upgrading those to the next accounting year.
As for the user who feels out of their depth – amazing work has been done by the
#site-health
team to help those out.
For those users, I like to use the car analogy:
A website is something users will generally use regularly and expect to “just work”. So let’s make the comparison with something else a lot of people use regularly and expect to “just work”.
Say a car. Similar to WP, when one gets themselves a car, you need to familiarize yourself a little with how it works (interface/admin), but then it just runs. You put in petrol regularly (WP updates) to keep it running. Then once in a while, it needs a proper service. Now you have a choice: either you learn how to service a car yourself (read the site health materials and follow them up) or you go to a garage (hire a specialist) to do it for you.
And if you really don’t want to be bothered with all that, you lease a car instead (managed WP hosting solution).
Along the same lines: if you ignore the warning lights in a car (site health admin notices), you can’t pretend to be surprised that at some point it will break down (gets
hacked
hacked
/can’t upgrade anymore). If was your responsibility as a user to act on them after all.
But Juliette, get to the point: how do you think we can get out of this situation ?
Ok, so here goes: I propose a fixed (rolling) schedule for dropping support for older PHP versions.
A fixed schedule means that such version bumps become
predictable
and with them becoming predictable, they become manageable and plannable.
These last two qualities are extremely important as all parties involved will know well in advance what they need to do and when it should be ready.
The current uncertainty over what WordPress will do leads to inaction, as we saw with two of the example personas, and we can counter that with becoming predictable and reliable with regards to the PHP version bumps.
So I propose that, as of now, we start dropping support for the PHP minor which is more than five years old each December, or if there is no release in December, in the WordPress release which is being worked on at that time.
That would currently look something like this, with the numbers at the top being the version of the WordPress release that December and the numbers at the bottom being the new minimum supported PHP version.
Keep in mind that, per the currently proposed schedule, the new minimum supported PHP version would always already be a version which is no longer actively supported by the PHP project, nor does it have security support anymore at the time it becomes the new minimum supported version for WordPress.
For example, PHP 7.1 was released in December 2016. Active support for PHP 7.1 stopped beginning of December 2018 and security support stopped on December 1, 2019. And based on the current proposal WordPress would still support it until December 2021.
But all those users on old WordPress versions…
Well, WordPress has always had a very liberal policy for backporting security fixes, so as part of this proposal, I’d like to suggest that the WordPress project makes a
hard commitment
to continuing to
backport
backport
A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch.
security fixes for WordPress versions up to four years back.
What that would come down to in practice, is that if a user would always want to use the latest and greatest version of WordPress with the minimum of effort, they would need to ensure their PHP version is updated
once every five years
And if they don’t mind lagging behind a little in their WordPress version, they could even get away with only updating their PHP version
once every nine years
and still have their website running on a secure version of WordPress.
Now how does that sound ? Is that a liberal enough policy ?
Note: security fixes are currently back-ported as far back as WordPress 3.7. With this proposal, the minimum version of WordPress still receiving security fixes would not longer be a fixed version, but would change to a rolling number.
But what about the users
currently
on old WordPress versions ?
To solidify the commitment to making this as transparent as possible for the users, I propose we backport the PHP admin notice from the site-health project to the older, still currently security supported, WordPress versions, so that those users will be informed when they log in to their website.
Alongside of that we could ramp up the site-health notices based on this fixed schedule of version drops and committed security fix support.
So… what do you think ? I eagerly await the reactions of you all!
Props to
sergeybiryukov
joostdevalk
and
matt
for looking this article over before publication.
core
core-php
php
request-for-comment
Share this:
Share on Threads (Opens in new window)
Threads
Share on Mastodon (Opens in new window)
Mastodon
Share on Bluesky (Opens in new window)
Bluesky
Share on X (Opens in new window)
Share on Facebook (Opens in new window)
Share on LinkedIn (Opens in new window)
To all team leads: if you feel this proposal would be relevant to your team, please cross-post it. Thanks!
Juliet we are going to post this on our main domain, this is good content and I do hope that WP adopts this concept. As
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
and WordPress Developers, we track our PHP Version and what WP requires on a constant. Cheers 🙂
devworksosi
Please add proper attribution to your publication.
Love it
Nice!
Great proposal for
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
support! It will be awesome to have a schedule like this going forward, there are no surprises for anyone. 😀
Keep in mind that, per the currently proposed schedule, the new minimum supported
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
version would always already be a version which is no longer actively supported by the PHP project, nor does it have security support anymore at the time it becomes the new minimum supported version for WordPress.
I often hear the whole “Security support” phrase thrown around in the PHP discussions, but I think it’s worth mentioning that even the hosts still running PHP 5.2 today aren’t necessarily insecure – they’re just severely outdated. The same goes for PHP 5.6 and 7.0.
It generally seems far more likely that hosts are going to be running an insecure version of a supported
release
branch
branch
A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch".
of PHP, than to be running an outdated PHP version that is known to have a security vulnerability. (ie. not running the latest in the branch – Of the PHP 7.3 installs, only 33% are on 7.3.21 (A security release) and a further 21% on 7.3.20 (a bugfix release) – Similar story for the rest of the 7.x releases, 5.x is closer to 75-85% on latest just due to the length of time they’ve been around)
For all the failings of PHP, severe security issues hasn’t been a plague it’s had to deal with, and often, they don’t affect WordPress (partially due to having not used the newer feature admittedly).
Further to that, PHP 5.6, 7.0, and 7.1 are all supported by 3rd party vendors for security purposes – two obvious vendors that come to mind include
Debian
supporting PHP 7.0 until June 30, 2022, and
Zend supporting PHP 5.6/7.1
until Jan 2023. Just because the one vendor stops supporting something, it doesn’t mean you can’t get them through another.
This isn’t to say I don’t support a scheduled deprecation, only that I disagree with some of the messaging that gets used in these discussions.
We have to be realistic with the reasoning as to why we’re dropping support, and “It’s not security supported” is often missing the point entirely – developers want to use newer functionality, it’s faster for the end-user, and it makes WordPress look better amongst the tech community (Not that the proposed support schedule will make much of a difference to them).
There’s also a significant difference between
technically
supporting something and saying we don’t support it.
For example, we can say that WordPress only support PHP 7.0 and higher, pushing that line in messaging (“Your web host is running PHP 5.6 which is now unsupported by WordPress, upgrade before your website stops working!”) while under the hood technically supporting it for a while longer, which will give an incentive to plugins/themes to cease supporting it earlier too.
edit: I guess this part is actually covered by the extra few years of security releases for the old branch, where that old php version would be supported but ‘unsupported’ by WordPress
It generally seems far more likely that hosts are going to be running an insecure version of a supported release
branch
branch
A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch".
of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
, than to be running an outdated PHP version that is known to have a security vulnerability.
Do you have data for this? I don’t work in hosting, and I did not do research, but what I know is that “official” PHP releases that are EOL have security issues that will not be fixed by PHP developers. That is a fact.
Moreover, vendors that
backport
backport
A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch.
security issues for older versions do it within a timeframe since the fix for officially supported versions are released and the issue is made public. That make them
less
secure anyway.
Saying that hostings that use old versions of PHP are not insecure is a quite bold statement that I would like to see supported by data, and before seeing that data, assuming old versions are insecure it
is
IMO the safest and correct thing to do and say.
And personally, I’ve heard a lot of times people working in hosting that says that old versions of PHP are insecure. To quote very recent words form a person that
works in hosting
(I’m not saying the name because I don’t know they would like to be named)
“Backporting is if a
bug
bug
A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.
is found in a newer version then if it affects the older version a
patch
patch
A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a
diff
. A patch can be
applied
to a codebase for testing.
might be added. Thats a lot of might and as the codebase drift further apart this becomes harder to do and doesn’t include security issues not in later versions but in older ones”
and
“Web hosts, have to create special instances, maintain old infrastructure and have piles of headaches to support these people. Most hosts choose not to.”
——
There’s also a significant difference between technically supporting something and saying we don’t support it.
You are looking at it with the eyes of the
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
developer, but even if I never worked for core I work in application and
plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
development for 15 years and my opinion is the difference is pointless from users’ point of view.
Officially saying “
the min PHP version is X
” means that plugin developers will be very free to use functionalities of PHP version
. And they will. The fact that core might
technically
work with the version
is not relevant for them.
If WP 5.6 will officially require PHP 7.1, plugins that target WP 5.6+ (most of them as soon as WP 5.9 is out in 2021) will start to use scalar type declarations, nullable types, null coalescing, short array destructuring, and many more things.
(Personal bet: among the very first plugin in adding 7.1+ functions there will be WooCommerce).
Sure, the “
Requires PHP
” plugin
header
Header
The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.
can mitigate that. But it assumes that plugin developers add that header, and as a plugin developer if I say “
Requires at least: 5.6
” and WP 5.6 and has PHP 7.1 as min version, why should I do that? It is an additional thing to maintain in my eyes, for no reason.
Besides that, the overwhelming majority of plugin developers do not backport security issues. That means that preventing people to update a plugin because PHP version, even if that version is officially the WordPress’ min PHP version, means to expose users to security risks.
In short, as soon WP officially says min PHP ver is 7.1 users
will need
to upgrade to at least that version, no matter what core “technically supports”, and to avoid breakage they need to do it before the last supported day.
And that will be more true with a predictable support life cycle because plugin developers can plan their versions in advance. Assuming this proposal is accepted, as I hope, I can today plan the version
of my plugin that supports WP 5.6+ and PHP 7.1+ and wait for WP 5.9 to be released to ship it. I’ll literally wait the day after WP 5.9 is released to ship it.
That means the “significant difference” you mention is only there if you look only at core development, at the moment you consider that WordPress is not only core, you’ll probably realize not only that the difference is not that “significant” but that pragmatically from users’ point of view is almost meaningless.
What worries me is the risk that because core says WP can technically work with a lower version, there will be less commitment in being clear and vocal about the urgency to upgrade for users still using old versions.
dd32
put simply, no, that is not true. Lets keep to the proposal at hand
For example, there’s an entire class of security issues for which libsodium was introduced to address in a newer version of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
, such as cryptographic features, and exploits centred around timing.
You could argue that hosts “
patch
patch
A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a
diff
. A patch can be
applied
to a codebase for testing.
” PHP, but at that point they’re running custom forks of PHP and we’d be discussing something else entirely.
We’re focusing on two different insecurities then, there’s two different ways to define insecure
* Insecure due to known vulnerabilities in the platform being run
* Insecure due to lack of security conscious coding in the application
Sodium has some timing attack prevention methods available to it, but that’s not it’s intention, it’s intention is to offer cryptographically secure hashing and signing methods to code, just it’s presence does not improve the security of the application, one has to use it.
Those security “benefits” are not relevant to WordPress, since a) It already used a timing attack preventing compatible function and b) It includes the compatibility class for sodium functions (Not that they’re useful as-is to WordPress).
To say a version of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
is insecure due to it’s lack of a library which offers advanced crypto to the applications is missing the point entirely.
> developers want to use newer functionality, it’s faster for the end-user, and it makes WordPress look better amongst the tech community
This is an important reason to keep moving forward and increasing the minimum version of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
If innovation is to thrive, then developers need to be able to use new features and be enthusiastic about using the platform for projects. I believe this is one of the reasons why PHP developers find Laravel development a refreshing change.
I welcome having a support schedule like this, but worry that the 5 + 4 years will not help move things forward fast enough to shake the, often unfair, perceptions of the quality of the WordPress codebase.
The idea
leoloso
suggests of progressively syncing up with PHP releases sounds good to me. Eventually WordPress would always have a minimum requirement of a recent PHP version. This would help to ensure that a good proportion of the web is running up to date software.
There was one reason left out why people don’t update – hosting companies like Godaddy who refuse to update their servers, forcing you to cancel your account and of course get a more expensive one.
think this is also a chicken-egg argument: WP powers such a large part of the web, this would force hosting companies to keep their stack (somewhat more) up-to-date instead of pushing upsells.
Specifically regarding godaddy – they’re not as bad at this as others (from 2017, iirc unprompted:
Regarding GoDaddy, what Nick mentioned is true. To upgrade to
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
7+, you must cancel your old hosting with them and move to a different option. I have an account with this issue. So, I can verify it for at least one of their hosting packages.
I’ve also been told they were going to automatically transfer those on the old package to a somewhat comparable new one within two months that has a more updated PHP version. That was a year ago.
I have the skillset to take care of all this on my own (I’m just lazy), but I cannot imagine the trouble this causes with non-technical users.
GoDaddy is such a horrible web host that WordPress should actively promote their competitors to anyone using a GoDaddy account with WordPress.
Hear hear!
Just wondering: is there a specific reasoning to the 5 + 4 years?
9 years is eons in internet time, and while WP’s commitment to backcompat is probably why it makes up so much of the internet, it still means carrying lots of unnecessary dev baggage.
If there’s no reason for those specific numbers, than perhaps consider 4 + 3 years?
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
supports each version for 3 years (2 active, 1 security), and we throw in an extra year of padding to provide time for site owners to migrate to a supported version. Plus 3 years of backporting in the spirit of backcompat, and that means a website can still theoretically live untouched for 7 years (!!!).
Of course, this is only acceptable imo because of the predictability the fixed schedule you propose – new site owners will know in advance how many years they’re getting out of their current set up. However, for the current ‘zombie’ sites, maybe we make it 4+4 for all versions up through 7.4 (or even the original 5+4), and implement a 4+3 schedule for 8.0 and beyond?
is there a specific reasoning to the 5 + 4 years?
The proposed support timeline is a compromise between the current reality and an “ideal” reality.
I imagine that if this proposal would be accepted, it can be revisited three or four years from now, when the effects should be clearly visible, to see if the timelines could be tightened further, but one step at a time.
What about making a progressive timeline already? Instead of having it fixed to 5 + 4 for every release (and then review it in 3 or 4 years), it could be tightened by, say, 12 months on each new release:
5+4
4 years 6 months + 3 years 6 months
4 years + 3 years
and so on…
Or if that’s too harsh, tighten by 6 months on each new release.
Then, it will get progressively a bit closer to the
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
release cycle
The clarity of documented and predictable cycle would be an incredible improvement over current situation.
One note about specifics of proposal — 5+4 looks like an long time to me on
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
side, considering PHP releases are currently on a three year cycle. 3+4 would sync PHP part to PHP and 7 years are about as much of internet eternity as 9 are. Yeah, some hosts
patch
patch
A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a
diff
. A patch can be
applied
to a codebase for testing.
end of life PHP versions, well, some don’t. Why cling to hypothetical security support instead of following the cycle with hard commitment to it.
Another general note — I have been arguing for many years to have data on intersection of PHP and WP versions added to public stats. This data is available, this data is compiled and used internally, and yet it is denied to development community. As the version situation gets even more complicated, I think it is essential that this data is available to be used both in
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
and extensions development.
+1 This is everything I was about to say myself.
+1
This entire discussion could be much more informed with the data on intersection of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
and WP versions… I cannot comprehend why this data are not publicly available.
This is a insightful follow through on the original problem and will put the discussion to bed.
I think the security policy can do with an example.
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
7.4 would be supported until Dec 2024 which someone could have used to install WP 5.3 with in Dec 2019 without updating. So 4 years security updates makes that Dec 2023?
That’s not 9 years but I’m not sure where I’m going wrong.
The example would be:
User switched to
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
7.4 when it came out in December 2019 and diligently updates their WP install to always be on the latest version.
Per the above graphs, WordPress would drop support for PHP 7.4 in December 2024 in WP 6.8, making WP 6.7 the last release supporting PHP 7.4 = 5 years of active support.
User now doesn’t upgrade to the next WP major anymore, but stays on the WP 6.7.x
branch
branch
A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch".
Between December 2024 and December 2028, WP 6.7 would still receive security updates = 4 years of security support
Does that help ?
Thanks that clear! And thanks to the
admin
admin
(and super admin)
fixing my typos.
This is an exceptionally thoughtful proposal and presentation. Seems spot on.
Love the explanation and the proposal. As a web developer who manages multiple websites, I have one main concern. There are plugins out there (paid/premium plugins) that do not work on
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
7.1 and up. Often you don’t find this out until you upgrade the site and experience bugs.
I don’t have the solution for this, as I think it’s every plugins’ duty (especially if this is a paid
plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
) that they should be updated.
In case of a free plugin that is in the WordPress repo, can we as users (or as WP community) get more information in the PHP Versioning? Currently it only says: ‘PHP Version [version] and up.’ Unfortunately, there are plugins that cannot run under the latest PHP versions. For whichever reason that is.
Furthermore, there are plugins that do not have the supported PHP versions mentioned. Is it an idea that this will become mandatory for each and every plugin?
Currently we can only list the
minimum
version, I also can’t find a
ticket
ticket
Created for both bug reports and feature development on the bug tracker.
on
trac
Trac
An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.
(might be a lack of my search skills)
This could be useful to list.
But if a
plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
know this it can always build an check in itself and not execute itself when it detects a higher php version, and give a warning.
I believe the reason for this is many years of having to support
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
5.2. This potentially caused some
plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
authors to simply avoid progress and keeping focus on PHP 5.2. This habit then perpetuates to always focus on the least whilst not considering deprecations. Obviously we have much more sane minimum versions now, but the problem remains.
A proposal like this will hopefully ensure plugin authors keep their eyes on both sides of the coin.
There is a
trac
Trac
An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.
ticket
ticket
Created for both bug reports and feature development on the bug tracker.
opened just a couple of days ago about adding the ability for plugins to specify the highest version of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
they’ve been tested with:
As an ultimate incentive, would WP versions that have passed the 5-year expiry actively stop working? I’d expect all of these to fall into the zombie group anyway, so it seems like an effective way of both disabling old versions that are likely insecure at the same time as flushing out those zombies that are ready to come back to life.
What
rarst
said. Also:
1. Make the min
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
version synchronized with PHP’s release cycle.
As written in the original article,
per the currently proposed schedule, the new minimum supported PHP version would always already be a version which is no longer actively supported by the PHP project, nor does it have security support anymore at the time it becomes the new minimum supported version for WordPress.
So, the reasonable question would be: why only change the min PHP version when that version is already unsupported by PHP?
2. Release data of WP vs PHP versions to the public. Besides the fact that it would be extremely helpful to everyone involved, it also looks extremely shady that this data is not available although it does exist. I always assumed that WP doesn’t want us to know this data, because then we could start making informed decisions. Why doesn’t WP want us to make informed decisions? I don’t know.
Also, I would like Make to stop parsing text for keywords (like “make” or “release”). It’s stupid when you just want to say “I am going to make a release”, and Make links “make” to Make.
1. Make the min
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
version synchronized with PHP’s release cycle.
Just noting that I would personally also like to see this as an eventual end goal at some point in the future, so that we’re more or less in line with the versions the PHP project officially supports.
One step at a time though. A predictable schedule like the one proposed would already be a huge step forward 🙂
Totally agreed! This predictability is infinitely better than no predictability. But as
rarst
wrote, 5 years is very long, compared to
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
’s 3. But sure, if 5+4 is what is going to happen for now, I’ll take it! 😀
Other participants are also pointing this out,
sergeybiryukov
. Cool!
Nine years it’s a really very long time, with a 3 realease per year security updte have to be made for tons of versions, unless with first update we inject a clear warning in old release to upgrade to a new php version i think that offering just updates make ppl and providers as lazy as they are now waiting 2 3 years b4 taking any actions
I may be wrong but what I understood from the auto-updates project is that WordPress officially supports only one major version and the goal of the auto-updates project is to help maintainers avoid backports to very old versions iteratively. It seems there’s a contradiction between this proposal and the goal of the auto-updates project.
There is no contradiction. This proposal is based on the current reality. Once the auto-updates project (for major WP versions) has been rolled out and the effects can be seen, we may well be able to revisit this proposal – or policy if this proposal would be accepted – to lower the number of years WP offers security updates, but that is something for the future.
I like the idea of having a fixed schedule, predictability is wonderful, I am curious how this would be rolled out, and how it would change some aspects though.
At the moment, the statement used by WordPress on supported versions is that only the latest
major release
major release
A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.
is supported, this would then move that to be, if working off 3 releases per year, that “The last 12 major versions are officially supported” … that’s a LOT of versions to support, both for volunteers, webhosts, and theme and
plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
authors, that sets a precedence that they’re expected to support all of those as well, because WordPress does. I know it says here that it is for security releases, but it gives the impression that each release is in essence an LTS (Long-Term Support, which I know is something many have been favorable towards, but it doing it for every release defeats that purpose).
The backporting of security updates to WordPress users as far back as 3.7 is a courtesy, because it’s possible, but from discussions the past year, it’s obvious that the added burden here on the security team is rather high now. The various proposals from them have never been 12 versions long, how does this align with their ability to keep up?
Just as an aside to
dd32
and his comment about security patching of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
, this discussion came up when WordPress moved to 5.6 as a default as well, because RHEL (Red Hat) only shipped PHP 5.2 and did their own internal security patches, they did not offer anything newer at the time. I do think it’s a valid remark, but one that should be seen in context of when it was officially given the EOL status by the PHP project I think, just so that we don’t feel 5.6 is fine for a decade like 5.2, although I believe we’re not where we want with regards to moving off it just yet.
The update system is already built for, and does right now, providing users with the latest version of WordPress that their host can support, users on PHP 5.2 won’t see an update for WordPress 5.5, they will see 5.1 (the last one to support that version of PHP as it’s minimum requirement), with a notice that there’s a newer version, but their host does not support it at this time.
That was a lot about security, let’s jump into the PHP version stuff!
really
like the idea of a yearly upgrade path here! The initial thoughts that were thrown out whe nthe 5.2 drop was being discussed was to jump a version or two every time, so that the project would eventually reach parity with the mainstream PHP versions out there, now that the PHP project has picked up steam. This is a matter of not becoming “stuck” again, if WP moves slow, hosts know they can hold back. What if WordPress instead jumped from 5.6 to 7.1 (or 7.2, based on many hosts default minimum these days), instead of 5.6 to 7.0, it would add a bit of traction, what would the above charts feel like if the jump was as such, two instead of one, is this something we could entertain, if only as a thought experiment at first?
I’m presuming the first increment of this would then happen December 2021 (so that it’s announced well ahead of time), what would the first bump be like, it looks to be a pretty hefty one, would it make sense to have a rollout plan leading up to the first one, to gradually announce the removal of older WP versions form the
backport
backport
A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch.
rotation as well? If I did my math right, come December 2021 versions as far up as 4.7 would be dropped in one swoop, although likely not actively maintained, that’s still ~10% of installs, many of which are unlikely to ever hear of this. The post mentioned backporting the ServeHappy notice all the way to 3.7, but would it make sense to expand on that? I know it was thrown around the possibility of e-mailing users, would it make sense to make ServeHappy send a one-off e-mail to users when a new PHP version drop is announced, to the site
admin
admin
(and super admin)
email (it’s not guaranteed to be correct, or that email services work, but it’s better than nothing, and would hopefully catch the attention of zombie sites)? I’m generally not a big fan of automated emails like this, but if it’s just that single one, it would be classified much like the automatic update ones I think, and serves a greater purpose.
I love the predictability (finally) and the sole fact of having a plan is a huge step forward. In my perfect world the life cycle of supported
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
version would be narrower, and closer to the PHP release cycle, but I’m adult enough to know my perfect world does not exist.
I want to really echo what Marius said but also to emphasis:
Right now “we” support the latest
major release
major release
A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.
, this proposal puts a lot more in scope.
In addition, security fixes are Back Ported, this is very different from actively maintaining. A
security issue
security issue
A security issue is a type of bug that can affect the security of WordPress installations. Specifically, it is a report of a bug that you have found in the WordPress core code, and that you have determined can be used to gain some level of access to a site running WordPress that you should not have.
in version WP3.7 that does not affect later versions currently has no expectations that it be patched and fixed.
I’m not keen on coupling
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions to WordPress security cycles, these are two very different things that have little in common. While both come under the banner security.
That said I am keen on PHP versions being updated, and there being a finite limit on the how far back things are patched.
Also 9 years is a long time, OVER HALF the entire WordPress projects current life time.
To put this in perspective, implemented today and we would be supporting WP3.1 when it introduced the
admin
admin
(and super admin)
bar and Post Formats…
I support this:
– I like backporting site health
– I like time based expected schedules that can be planned around
– I like that there’s plenty of warning, and that it’s predictable
– I like that future changes will not be arbitrary, there’s a reason for the dates and changes according to a policy
– I like the escalation of notices for WP versions that aren’t recieving new updates
I do question if 9 years is too long though, 5 years seems a more reasonable timeframe.
I also echo the sentiment Tim raised on security vs
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
support cycles.
Agreed, 5 years is a more reasonable timeframe 👍
This is a very bad idea. The success of the
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
CMS-s is in that we can rely on specific long term support. I totally understand, that older PHP versions holding back the rollout of new features and optimizations. The only real advantage of WordPress is that every developer from 5-10 years ago, still can use the same logic. We do not want to become the next angular,
react
React
React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces.
or any other npm package, where you will never know what version compatible with which system. Keep WordPress conservative on the very long term support, as this is maintainable, contrary to the too quickly changing codebase.
This is already an ultra conservative proposal, 9 years is enough to conceive a child and raise it until almost secondary school. Nor were any WordPress
API
API
An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.
changes suggested.
For comparison, Ubuntu LTS Longterm support releases last 5 years,
React
React
React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces.
didn’t exist 7 years ago.
So effectively this means that we cannot use
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
8 syntax in themes/plugins if we want to support all WordPress versions until December 2023,
3 years
after it has been released. This is very disappointing.
Why not turn the tables around? Don’t support old PHP versions that don’t receive updates anymore. Since WP powers so much of the internet, this could drive hosters to update their PHP faster.
A potential workaround is to use the latest version of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
for development, and then use Rector to convert the code to a lower version of PHP and generate the theme/
plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
for production (it could be possible to
downgrade all the way from PHP 7.4 to 5.6
).
For instance, we can use property types from PHP 7.4, and with
this rule
have them removed.
I’ll do some experiments using this strategy to see if it works well.
I support this. New versions of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
allow developers to take advantage of new features, which means we build better software.
Having a clear schedule is always a good idea.
9 years sounds like an eternity in internet years (like others also said)
Another point. Will this end date be listed in the
site-health
I’m in support of this proposal. I used to run a hosting company and in my experience “hoping” people will upgrade doesn’t happen. What we did was to set a deadline and send out reminders beforehand. A significant amount of site owners upgraded their sites just before the deadline, a small number had to fix it after the deadline but at last no-one could not argue they hadn’t been given enough prep time.
So many comments already mentioned the important things.
I want to add just one thing: Hoster seem to need time to test and implement
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
For example: PHP 7.4 is planned for December 2020 on a big hoster here in Germany (which is run by a big US hosting company). One year after it is released. (!)
Yes, I agree. Hosting companies, especially those attracting WP sites by offering “managed hosting” need to get their act together.
I manage quite a few sites for clients who end up asking me why there is a Site Health notice to upgrade
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
and I haven’t done so. I have to tell them their host does not offer the latest version yet!
If hosting companies kept up to date with the PHP latest version and also reminded their clients, even if only at renewal, to do so it might mean that the long out of date versions disappeared naturally. Sure there will always be “zombie” sites renewed on auto and never updated with WP or plugins or PHP but those can die without causing anyone a problem.
While I understand your sentiment, and in some cases your comments are dead on, I feel a need to interject just a little bit here. As someone that owns a managed WordPress hosting company and has more than 10 years in the industry, I can tell you it is not usually that cut and dried.
As hosts, we have to consider every user on a server before making such updates as they can often break websites. For example, if you took a WordPress 4.x.x site today with plugins that have not been updated in a few years, and upgrade that to the latest
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
, I can almost guarantee you it will break.
In an ideal world, all customers would keep their sites fully up to date at all times, thus nearly eliminating such risks. But it is not an ideal world. I have seen customers with sites so old that most of the plugins they are using have not even been developed for multiple years.
Now, most good hosts will make latest version of all software, PHP included available so the customer can upgrade if and when it is safe for them to do so. But we hosts may also hold back an update intentionally, especially with things like PHP,
MySQL
MySQL
MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored.
, etc. to give time to ensure the newer versions are secure, stable, and will not hurt performance of our servers.
Now in the case of hosts that give dedicated resources such as a VPS, dedicated servers, etc, these concerns are usually a bit lessened as worst case scenario it breaks sites belonging to a single customer, and not hundreds. While we obviously do not want any downtime for any customer, it is much easier to fix things for one customer at a time, than several hundred.
One of the problems with
plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
updates is that an abandoned plugin looks the same as every other. The user thinks it’s up to date.
I’d suggest working with the biggest enterprise Linux vendors (Red Hat and Canonical at least) to make sure your
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
support schedules line up with theirs. I still have a small number of sites running PHP 5.3, specifically because that’s the version of PHP supported by Red Hat for RHEL 6 (at least through November 2020, and possibly later if we choose to pay for extended support). Red Hat backports
bug
bug
A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.
and security fixes, so while PHP 5.3 is no longer supported by the PHP devs, it’s not entirely accurate to say it’s unsupported, period. Such is the beauty of
open source
Open Source
Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL.
. I’m not familiar with the version support for Ubuntu’s LTS releases but I assume they do something similar.
I’m well aware that it would be easy to point these servers at, say, remirepo and install pretty much any newer version of PHP. But we can’t exactly put Remi on speed-dial and call him if/when his PHP builds cause a problem. Enterprises like the warm fuzzy feeling of knowing that, if there’s a serious bug in something, they can call someone and remind them about all the money they’ve been given and get that something fixed.
For Red Hat, it’s an open question how far into their maintenance phases you’d want to go, but I would say, at a minimum, to the end of ‘Maintenance Support 2’. Anything past that requires additional payment to RH above and beyond the standard support agreement, plus the end of MS2 generally lines up with 10 years from the initial release of the OS, which is fairly close to the 5+4 this proposal is currently targeting.
The last thing any of us wants is for large enterprises to be told they can’t use WordPress because .org wants to deprecate support for something that’s still supported by $BIG_VENDOR. If my upper management had to choose between a supported OS and a supported version of PHP, the OS would win every time, and if that meant we couldn’t use WordPress, my team and I would start reading up on SharePoint. Please don’t make me learn SharePoint.
I just want to add my voice that 9 years being a long time is
a good thing
. WordPress’s backward compatibility (BC) philosophy is very good for users. Most commenters here are developers, who naturally want to use the latest tools, so obviously they would prefer a shorter BC burden. I think WordPress should attempt to maintain as long a support cycle as possible.
I love the idea of a fixed schedule. It’s open and fair. Great proposal.
I love the proposal, especially around backporting Site Health. Bonus if we’re able to trigger an email to the site
admin
admin
(and super admin)
as part of it (e.g. “Hey, it looks like you’re still on an ancient version of WordPress, but here’s what’s coming…”).
Like many others in this thread, I’d prefer to see an even tighter timeline, but I also understand that perfect is the enemy of good, and having a longer-but-fixed timeline is better than being left with vague “sometime in the future” goalposts. I’d love to see a commitment from project leads to revisit the timelines after a year or two, especially once
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
5.x has been officially dropped.
It’s also worth mentioning that getting over that 5.6 => 7.x transition seems to be the hardest for non-technical site owners, as
PHP 7.0 removed a number of deprecated functions
(notably, the long-deprecated
mysql_*()
series of functions). Once a site is running PHP 7.x, moving to a newer release (assuming the host offers it) is rarely problematic.
YES!
I think this is a good starting point as other said, and if I see right the WP5.6 will support PHP8, this is also good.
Only last thought, I would start to support
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
7.2 on WP 5.6 and not 7.1 at this point, and the next year with WP 5.9 bump to 7.4 instead of 7.2.
nice but what about removing any reference to PHP4 in WP ?
wp-
admin
admin
(and super admin)
\includes\class-ftp.php
281: // Validate the IPAddress PHP4 returns -1 for
invalid
invalid
A resolution on the bug tracker (and generally common in software development, sometimes also
notabug
) that indicates the ticket is not a bug, is a support request, or is generally invalid.
, PHP5 false
wp-admin\includes\deprecated.php
505: * PHP4 Constructor – Sets up the object properties.
wp-admin\includes\file.php
207: ‘php4’,
266: ‘php4’,
wp-content\themes\twentyeleven\inc\widgets.php
38: * PHP4 constructor.
wp-includes\IXR\class-IXR-base64.php
22: * PHP4 constructor.
wp-includes\IXR\class-IXR-client.php
55: * PHP4 constructor.
wp-includes\IXR\class-IXR-clientmulticall.php
22: * PHP4 constructor.
wp-includes\IXR\class-IXR-date.php
32: * PHP4 constructor.
wp-includes\IXR\class-IXR-error.php
24: * PHP4 constructor.
wp-includes\IXR\class-IXR-introspectionserver.php
52: * PHP4 constructor.
wp-includes\IXR\class-IXR-message.php
39: * PHP4 constructor.
wp-includes\IXR\class-IXR-request.php
39: * PHP4 constructor.
wp-includes\IXR\class-IXR-server.php
32: * PHP4 constructor.
wp-includes\IXR\class-IXR-value.php
36: * PHP4 constructor.
wp-includes\PHPMailer\PHPMailer.php
4184: ‘php4’ => ‘application/x-httpd-php’,
wp-includes\pomo\entry.php
67: * PHP4 constructor.
wp-includes\pomo\streams.php
26: * PHP4 constructor.
157: * PHP4 constructor.
241: * PHP4 constructor.
312: * PHP4 constructor.
338: * PHP4 constructor.
wp-includes\Text\Diff\Renderer.php
47: * PHP4 constructor.
wp-includes\Text\Diff.php
59: * PHP4 constructor.
339: * PHP4 constructor.
398: * PHP4 constructor.
430: * PHP4 constructor.
462: * PHP4 constructor.
494: * PHP4 constructor.
wp-includes\atomlib.php
102: * PHP4 constructor.
wp-includes\class-json.php
158: * PHP4 constructor.
990: * PHP4 constructor.
1022: * PHP4 constructor.
wp-includes\class-phpass.php
59: * PHP4 constructor.
wp-includes\class-pop3.php
68: * PHP4 constructor.
655: // For php4 compatibility
wp-includes\class-wp-widget.php
177: * PHP4 constructor.
wp-includes\class-wp-
widget
Widget
A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user.
-factory.php
36: * PHP4 constructor.
wp-includes\functions.php
4817: * remove PHP4 style constructors.
4821: * This function is to be used in every PHP4 style constructor method that is deprecated.
wp-includes\general-template.php
3800: case ‘php4’:
wp-includes\plugin.php
474: // Backward compatibility for PHP4-style passing of `array( &$this )` as action `$arg`.
wp-includes\rss.php
103: * PHP4 constructor.
732: * PHP4 constructor.
Hello, Javier from
hosting
team (in this case, with my personal opinion, I hope that in a few days the team will give a joint opinion)
This discussion about which versions of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
to support, from a hosting (and in my case, also as a developer) point of view, has been held on many occasions, and for us it is a recurring talk. I add that not only of PHP, but of SQL servers, caching servers and, in general, anything related to WordPress at the system level.
It should be noted that PHP 5.6 has been around for a long time, much longer than the current PHP release cycles, which are annual and usually come out at the end of organic years (at least these last 5 versions are being so). Also, the cycle is in supporting 2 versions + 1 with security updates, which means that PHP is supporting 3 years of its own development… why should we support more?
Maintaining older versions of PHP, in my experience with non-WordPress projects, is usually “because we haven’t had time to move to PHP 7 yet”. This phrase is a classic of these last two years in my daily life. And it is true that the change from PHP 5 to 7 is very big but… what’s the problem with WordPress? The WordPress
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
is already being prepared for PHP 8.0, just so that on the day of its release it will be supported, and in general, those who keep their plugins and themes up to date, also tend to do so with the corresponding WordPress versions. In addition, both teams have already implemented the “we support these versions of PHP” labels.
From this context, and about the chicken and the egg, I have it very clear: in the WordPress world, what make the rules is WordPress and it is the hosts who must keep up to date to support the software. In the hosting team, every time a new version of PHP is near (as I was saying, at the end of the year) it involves a conversation, more or less at this time of the year, which is just now, “when does the first
beta
Beta
A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.
come out?” Because serious hosting companies test with time, and use the PHP-test-runner tools offered by the hosting team to validate that WordPress works properly.
On the other hand, the latest “version upgrades” in the WordPress recommendations are along the lines of “supporting stable versions of anything that uses WordPress”. I think that jQuery, component maintenance, and generally all of WordPress, goes in the line of keeping only the stable versions of everything. In this line, WordPress should now support PHP 7.2 – 7.4, preparing everything to support PHP 8.0. Earlier versions of WordPress support those earlier versions of PHP. If your host does not allow a higher version of PHP, your WordPress software will be limited to the maximum version that supports that version of PHP, and to its security updates.
There are two reasons for this. The first is that WordPress can provide backward compatibility, yes, but to a certain extent. We can’t have code that, depending on one version of PHP or another, does one thing or the other. Well, yes, we can have 3 or 4 versions, but not 7 or 8, because it’s simply untenable. And the same reason is for hostings… maintaining more than 4 versions of PHP is crazy… on the one hand because of the security problems it can bring, on the other hand because of the resources and management it entails.
There are hosting companies that have made a decision (right or wrong) that is “everyone gets the minimum version of PHP” (usually 18 months after its release, in the current cicles), and you have the possibility to “keep your old current PHP version”, but in that case we will have to move your site to a special infrastructure (and in some cases paying for that old version and special support) and that is that maintaining that old infrastructure has a cost (like the cost of maintaining old versions of WordPress, and here, surely many of the Core team can explain what it means to support versions as old as WP 4.x).
Currently every 3 versions of WordPress comes with 1 version of PHP (more or less). If you haven’t updated 9 WordPress versions and you fall behind with a PHP version, it’s simply that “you don’t care about your WordPress installation”.
WordPress 5.6 = PHP 8.0 (dec 2020)
WordPress 5.3 = PHP 7.4 (dec 2019)
WordPress 5.0 = PHP 7.3 (dec 2018)
WordPress 4.9 = PHP 7.2 (dec 2017)
WordPress 4.7 = PHP 7.1 (dec 2016)
Following this table (very approximate of versions in dates) are you telling me that someone who is with a WordPress 4.7 has not had the opportunity to switch to PHP 7 yet? No, it’s just a lack of knowledge of site managers, who are sure that an agency has hired them for hosting.
So, in short, no. Every major version of WordPress should support only the latest (security + active + development -> right now: 7.2 + 7.3 – 7.4 + 8.0) versions of PHP.
I agree with this. Articulated beautifully.
Well said, sir.
+make.wordpress.org/plugins/
My view is that backwards compatibility in every way is vital to the success of WP and the ecosystem as it has always been.
A small flower shop owner somewhere in Idaho or a part time anime reviewer in Tokyo doesnt have the time and resources to be juggling compatibility, security and update concerns – their time is committed elsewhere. Which is one of the reasons WP has been so successful – you just click ‘update’ and thats it.
Which is a blessing and a curse at the same time since it creates the user segments who behave in the way depicted in the infographics that were shared in the post.
This situation must be accepted as a fundamental aspect of the success of the ecosystem since it is a result of making WP easy to get in and stay. Compared to early days of the web when someone needed to be somewhat sufficiently technical to do it by himself or still somewhat technical to be able to go get contract help or help from a friend to create and maintain a decent level of web presence, this is a godsend for majority of the Internet which doesnt have the technical expertise or funds to maintain web presence the old way.
Therefore, in my view, backwards compatibility should be protected as long as possible. While 9 years is a decent time period, it would be better if it was longer. The longer the platform remains hassle-free to get into and stay, to maximum extent possible, the bigger and stronger it will get.
And no, users dont care about the technical reasons that are shown as important factors for dropping support for older
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions – while they are valid reasons, they are not important to the users as they are important to developer and maintainer segments:
Bother the florist in Idaho with such backward compatibility issues a few times, and he will just go sign up in a proprietary platform which doesnt give him any of those headaches.
Yeah, security is important. Features? Yeah, they are likely somewhat important – despite few of the changes in the underlying PHP language ever affect his actual WP usage.
But what’s
more
important is his daily schedule, That’s why he is on WP platform, one that is perceived as easiest to get into and maintain on Internet.
What’s very important for a programmer, a sysadmin or a maintainer is rarely important at all for the user. Even if it is actually important. For the user can get on an easier to use proprietary platform at any point in time. It is the platform’s job to make things easier for the user and keep those security issues and compatibility issues sorted in a way that is transparent to the user.
That is why backwards compatibility is critically important for WP and its ecosystem and it must be maintained as long as humanely possible.
Bother the florist in Idaho with such backward compatibility issues a few times, and he will just go sign up in a proprietary platform which doesnt give him any of those headaches.
You seem to be forgetting that that same florist could have chosen and can still chose to use a managed hosted WordPress solution, which would effectively come down to the same.
Unfortunately that cannot be counted upon. For many people, even the ‘hosting’ concept is a technical and c omplicated concept. They get a ‘website’ somewhere, and thats it. Even more so in this particular case, communicating to the user that the compatibility issues (errors from his perspective) which he or his friends/colleagues are getting in their ‘Wordpress website’ – the self-hosted WP site which they dont know they are self hosting – will not be a problem if they ‘get their website’ from
WordPress.com
WordPress.com
An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before.
or another hosted place.
All they know is that they got a ‘Wordpress site’ made (by someone they contracted or a friend), and it has ‘issues’. Getting them to distinguish in between self hosted WP and WP.com and hosted versions is a complication in itself. For even today, you can see a large amount of users saying ‘I have a WordPress site’ if they are hosted at WordPress.com and
‘I have a
WordPress.org
WordPress.org
The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization.
site”
if they are hosted elsewhere.. The latter self host their site and they are a segment which is able to know how to get hosting and get WP set up there, but they dont know that they are self-hosting the software themselves and they have no relation to ‘Wordpress.org’. This segment is more technical than the segment in question here, and even for that segment the difference is hard to set up and maintain. If WordPress gets a reputation for creating such ‘problems’, it will affect the entire ecosystem.
Further problem would be the Business plans and above at WP.com. Even if someone is hosted at WP.com with a business plan and up, if s/he is troubled by compatibility issues in a manner which s/he will notice – everyone’s perception of ‘too many’ would be different – then that amounts to the same situation – ‘This is too much trouble, i will ‘just’ get this other website service instead’.
I’m not fond of the idea of officially supporting
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions longer than the PHP team support them. Nor am I fond of officially supporting versions of WP from 5 years ago. I know that in practice, we’re already doing both of those, but I’d rather not make it “official”.
That said, I do think that having a schedule like this would be a massive improvement over having none at all. However, I think we should try to align our support schedule of PHP versions with their official support as soon as possible.
Backporting a site health notice to old WP versions stretches the meaning of “security update” slightly, but it seems very reasonable to me… far more reasonable than the past proposal to enable automatic updates to major versions on those old versions.
In general, I’d tighten the support schedule, but I definitely prefer the current proposal over the current total uncertainty.
Noting up front that I am in favor of predictability and not particularly opinionated about the exact lengths of time (would be nice to get the security backports down to single digit number of releases eventually, since once you get past WP 5.0 we’re back to 4 month cycles) – would it make sense to frame the
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
side of thing as the amount of time since the last security release? A 5 year cycle means 2 years since EOL, assuming PHP sticks to their development cycle as well, and I think that’s probably the more meaningful way to look at it given that the
absolute easiest information to find for EOL branches is that final patch release date
, not the initial release date for that
branch
branch
A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch".
. Either way it’s kind of a magic number I guess but I think that reframing would help with broader understanding of the choice since I very much doubt the majority of developers are aware of the length of PHP cycles 🙂 If there’s something I’ve missed about a different rhythm one year or something, let me know, I just found that to be a commonality in the comments and my own observations and that was my initial thought.
+1 to basing it off the EOL date. Particularly if there is a difference in rhythm one year. I think the 5.6 supported date was longer as the last in the 5.x series, do we know if 7.4 will be treated the same? I suppose a decision could be made for WordPress to maintain 7.x support longer if
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
does too, but it might be “cleaner” if the timelines were synced up because they used the EOL date.
helen
Good point about taking the final (security) EOL date as a guideline. I agree that would be a good base.
In practice, though, it will make little difference to the above proposal.
Per the current
published planning from the PHP project
, the
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
7.4 release will not be getting an extended (security) support period.
This is in line with the published & vote accepted
release process
timothyblynjacobs
separate one-off vote
was taken for PHP 5.6 to extend the support period at that time.
Why waste time on old
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions even when PHP itself ended support? PHP 7.1 is dead, 7.2 dies at the end of the year. There is no point in supporting those versions. Why would you support 7.2 for two years after it’s dead. It should be max 1 year, maybe 0. The PHP team has their schedule. If those people can’t follow it, what makes you believe that they will follow yours? My hosting provider can’t upgrade my server fast enough because of morons who are upgrading to Centos 7 now. Yet Centos 6 is long dead and Centos 8 is out for more than a year. THERE IS NO POINT IN PROVIDING SUPPORT FOR A SOFWATE THAT RECIEVES NO SECURTY UPDATE. The idea is nice but remove 2 years from all versions. Thanks.
Thanks for this post Juliette, and thanks Matt for discussing the issue with her. I am very much in favour of a predictable schedule, the specific durations of which can and should be refined over time.
For those who are arguing against supporting
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
branches for longer than the PHP project does, please have the courtesy of reading this post in full. Juliette explains very clearly why this is not currently realistic.
If WordPress will support old
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions so long, in the near future it may cause BC between current PHP version and version supported by WordPress team (e.g. attributes in PHP 8 or exceptions instead warnings/notices). And there will be choice between deprecation old PHP version in
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
and rejecting supporting of new PHP release. As regular WordPress
plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
dev, I think WordPress need to synchronize minimum supported PHP version with PHP Team timeline +1 year.
+make.wordpress.org/themes/
I am for syncing the WordPress supported minimum
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
version to the EOL of PHP or adding a maximum of 1 Year of PHP’s EOL if you really want to procrastinate.
+1 from me and the Jetpack release management team. I’m not particularly opinionated on the timeframe—nine years is beyond generous and I’d be okay with it tightened—the major advantage is predictability on when we can expect to drop support for older versions.
If that timeline is shortened in the future (from nine to the five years other have suggested), that’s fine and good. The gamechanger is knowing that we can expect 7.1 as a minimum for Jetpack when WP 5.7 ships (as we support WP-1) versus currently having no idea.
In terms of the broader
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
community, even if we’re having to support versions a tad older, it would be helpful when onboarding new developers to 1. assure them of when we’d expect to support which version and 2. limit the number of outdated versions we need them to be versed in.
This proposal is from a
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
perspective, and as such, it sounds reasonable. But I think it misses the point, which is “What does
support
mean?”
As Marius says, “We only support the latest WP version.” And yet, we don’t. We answer questions for any version, in the forums. We
backport
backport
A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch.
security fixes for many old releases.
Each WP version only runs on certain
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions. And those versions are actual test setups that the CI runs through. It is a fixed set. Each WP release could show a range of PHP versions that are valid.
But plugins and themes do not have this luxury. They need to show a range of WP versions
and
PHP versions.
When I update my browser to a new version, it runs through the extensions that I have added and disables the ones that are no longer compatible. I don’t think that this is a good idea for WP and its plugins/themes because the goal is different.
Yet there should be some pre-update messaging concerning the effects of the update, especially if the update contains a change to the PHP minimum. Knowing in advance that some of my plugins won’t work with the new PHP would be great, but not really possible, because we use PHP min, and that only gives half the story.
There are actual code changes in WP for the newer PHP versions, as PHP changes and deprecates things. So each WP version has a definite range of PHP versions that it will run on. Changing the minimum PHP version for a WP version doesn’t affect those old WP versions. That is mixing apples and oranges. It
does
affect the plugins and themes, however, since they are independently updated. The plugins and themes may need those same types of code changes that WP needed for the new PHP version. But there is no big team working on all those plugins and themes, so the site owner is left in a quandary of how to update their site.
This is the real problem, and I don’t see how this proposal helps with that.
Perhaps it would be a good idea to add a “tested up to
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
version X” field for plugins/themes, as well as an accompanying notice on the updates page to inform the
admin
admin
(and super admin)
that some of their plugins have not been tested with the latest WP and/or PHP versions.
So…
#51139
But there is no big team working on all those plugins and themes, so the site owner is left in a quandary of how to update their site.
This is the real problem, and I don’t see how this proposal helps with that.
I would hope that the predictable release schedule would help with this. Not for abandoned plugins, but small development teams would know years in advance when their code won’t work anymore, and be able to plan accordingly.
Using a fixed, predictable schedule for dropping support of old
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions is absolutely the best way to handle it for all parties involved. However, I do not think its necessary nor sensable for WordPress to support versions of PHP that are no longer supported by the PHP devs. While there’s always a chance some security updates might still be made available for some time by individual Linux distributions but there is no guarantee. I think supporting a version for an additional year after PHP Devs drop support makes the most sense.
While I would love 3+4 instead of 5+4, I think the article and proposal are well articulated and the entire notion of a published and transparent schedule would be welcomed by many, including hosting companies. Great work by all!
Cutting old WP sites off from updates doesn’t break sites, in fact it’s probably safer for those sites to keep running WP 4.9 on
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
5.2 then to upgrade anything on those sites.
Very happy this discussion is continuing, and there is hope of defining a predictable path.
On that front, I too would certainly favor 3+4. 5 years for PHP seems needlessly long. As many have said, 9 years is an extraordinarily long time on the web. 7 years is extraordinarily long too.
Regardless, I’d specifically echo what
dd32
proposed above such that if a site is running on a version of PHP outside the official 3 year PHP support window we actively tell folks they’re running on a no longer supported version of PHP and _should_ upgrade.
I’d also echo was
helen
said about basing things on actual EOL dates. The message presented to users could them be “PHP 7.0 stopped being supported XXX days ago, while WordPress will continue to be supported on this version until XX/XX/XX, you should upgrade your PHP as soon as possible. You can run a test here to check if you have any themes or plugins that are likely to be affected by this upgrade”.
Well, WordPress has always had a very liberal policy for backporting security fixes, so as part of this proposal, I’d like to suggest that the WordPress project makes a hard commitment to continuing to
backport
backport
A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch.
security fixes for WordPress versions up to four years back.
This is great. Would love to expand on this.
I really like predictability (especially this year, wow 2020)! And I can see that a predictable schedule for version support appeals to many who have commented here. That said, this proposal seems to advocate a significant change to the approach WordPress
Core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
has followed for a long time.
In my observation, Core leadership makes important decisions based on whether an approach will negatively affect a significant numbers of WordPress users, not really based on calendar/EOL dates. For example, my understanding is that Matt asked that we drop support
only once the number of older versions falls below 10%, ideally under 5%
I guess I’m curious about how this time-based approach would benefit that fairly significant number of end users whose sites are using older versions of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
? From my read, the proposal seems to primarily benefit developers — but I might be missing something, so I thought I’d ask!
Hi
andreamiddleton
Thanks for asking.
My primary concern in this whole discussion has not been the devs, but the users.
With this proposal I’m trying to find an acceptable balance between supporting the users who
don’t
upgrade (approx 25% on
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
5.6 and 7.0) and those who
do
upgrade (approx 35% on PHP 7.3 and 7.4).
PHP 8.0 is around the corner and the intention is to support PHP 8 in WP 5.6 and as things stand, I highly doubt that is a realistic proposition.
PHP 8.0 contains a number of changes which will require a significant time investment to a) find the issues and b) fix/work-around them. This is made substantially more difficult and will take more time if WP also still has to support PHP 5.6/7.0 and will stretch the relatively small percentage of the WP contributors who are devs and capable of making the changes to the very limit and beyond.
The PHP changes I’m talking about are the type of changes which will cause site-outages/white screens of death for the users who are early adopters and upgrade to PHP 8.0, so these aren’t small bugs and WordPress websites going down on PHP 8.0 will cause its own fall-out.
So dropping support for PHP < 7.1 will help to allow us to support PHP 8.0 and adopting a time-based EOL schedule will take away all the uncertainty surrounding these kind of decisions for the future, increasing the chances that hosts as well as users will upgrade in time for future PHP drops.
Does that answer your question and clarify well enough why this is not about the devs, but really about the users ?
No, what you’re saying seems entirely about the devs.
If you’re saying that it is not possible to make
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
code which runs on PHP 5.6 and PHP 8, then, to be blunt about it, I don’t believe you.
But, you seem to be saying that it will take a lot of effort. That’s fine. We make that effort. We take on the technical debt so that we can provide the software to the widest audience. This is what WordPress has done since the beginning. And yes, it takes time and effort, but that time and effort has been well spent in the past, and I believe it will continue to be well spent in the future.
If this means that we won’t be able to use all the spiffy new features in PHP 8, well, that’s to be expected. If they are spiffy enough or add enough improvements, then we can add detection for them and use them accordingly. If something we used to do won’t work anymore, then we should fix the existing code to work around the problem in a backwards compatible way.
We don’t give up on backwards compatibility just because it is hard to do.
Thanks for that information,
jrf
! I wasn’t trying to say that making a change that benefits developers is bad, per se. 🙂
I agree it’s possible that providing more certainty among hosts and users will result in more upgrades, but it seems that working with hosts might be less intrusive for end users. I do see that getting ready to support
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
8.0 is going to be a lot of work, and it’s pretty important to get more help on that, as soon as possible.
Thank you Juliette (and Matt, Joost, and Sergey) for putting the proposal together.
I think there are two factors here, which the later comments above have picked up on – the ability to know when there will be a change in supported versions of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
, and agreement on what those PHP versions will be (fixed range, or a progressive schedule towards a tightened fixed range).
Knowing when the change will happen will allow all parties (hosts,
plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
and theme devs, and our newly site-health–educated users) to make informed decisions – that should drop the chicken-and-egg situation between hosts and WP.
I’m in favour of the 3+4 suggestions, even if we start at 5+4 and move towards it in some incremental steps over a couple of years. That said, if getting hosts, users and plugin/theme developers to take action is deemed to be a sticking point, then fewer bumps should be made that don’t already tie in with parent dependencies (PHP).
I like the fact that there is a schedule.
I’m not particularly fond of the specific timeframes, but it’s better than nothing.
It adds some predictability we were previously lacking, and at this point, it’s just better than what we currently have (which is basically just unpredictable, uncertain, a complete lack of any plan).
Certainly an improvement in the right direction.
Hello!
TL;DR
: I’m all in favour of this proposal. I’d also prefer even shorter support times.
The full version:
I’m just a very humble hosting provider for non-profits and small businesses which cannot even afford the cost of a monthly fee just to keep their sites online; as a consequence, I tend to do maintenance on 25-year-old websites (really!) — some of which, obviously, were ported to WordPress 15 years ago or thereabouts. My work is essentially voluntary and unpaid; although I
love
doing it, I
also
need to ‘keep things simple’.
At some point in time, I was ‘supporting’
five
different
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
versions, mostly because a few sites were using CMS from 1997 or so, which I had patiently changed over the years to keep up with PHP upgrades… which worked relatively well until 5.6. The move to 7.0, however, was simply way too much work for me, mostly because the lack of support for the ancient
mysql
extension…
A one-person-setup, working a few overtime hours as a ‘pet project’, simply cannot afford to support so many ancient technologies at the same time; over time, I managed to get pretty much everything working under PHP 7.4, one or two sites under 7.3, and just one (grrr!) with… 7.0. But I
essentially
focus on 7.4 (and the upcoming 8.0, of course). To do so, for a period of time, before official 7.4 support by WP, I was pushing a few of the more critical WP installations to the first
beta
Beta
A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.
versions that already supported 7.4, just to see if everything else (plugins, themes…) would work, too (and find replacements otherwise). I did
not
worry about
WP
itself — I simply have 100% confidence on the
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
team to do their work well, and, once they announced that WP was fully PHP 7.4 compatible, I did not even bother to check if the backups had been done correctly…
In other words: from my own perspective,
so long as WP continues to run
, I’d prefer to make sure I can run
everything
on one single version of PHP — and that means the
current stable version
(it’s a waste of time to choose anything else). I have the same approach to all other components in the system — although I have to admit that sometimes some components
might
lag a bit behind (such as OS upgrades or
MySQL
MySQL
MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored.
/MariaDB updates). Nevertheless, maintaining different stacks with different versions, some of which outdated, is a nightmare (I have suffered for
years
because there was no clear and easy way to upgrade one server with Ubuntu 16.04… until eventually I had to take some time off to work out a way… yay COVID-19 and staying at home 🙂 ). My
current
nightmare is an ancient server,
not
under my control, running a version of Plesk that is so ancient that I’m embarassed to say which it is, and which, with a
huge
amount of effort, I managed to get running a heavilly patched version of PHP 5.4… but not anything more recent… no way I could run a
recent
version of WP on it, so the site is still running on that 1997 CMS, to my dismay… and there is no way to get the hosting provider to update their 15-year-old setup: they provide ‘dirt-cheap’ hosting (which the site owners love!) on ancient hardware and even more ancient software — if you wish to have a more recent version, you have to
pay
for it. Personally, I see this kind of approach as being unethical, not to say
stupid
, since such ancient software/OS versions are extremely vulnerable to attacks through well-known security flaws… but, alas, I have
no
vote in the matter,
except
for saying that I won’t support that specific website further until they move it to something more recent which can run the current stable version of WordPress…
Anyway… this is merely anecdotal evidence, of course, but my point is that end-users
couldn’t care less about what version of WP they’re running
, and much less about what version of PHP is required for doing so. All they want is the cheapest possible solution which, at the same time, is the easiest to use (i.e. WP!…).
If
I have the underlying stack fully at my disposal, I will, as a matter of fact, install the latest stable versions of practically everything — there is no point to keep using (and maintaining!) any sort of ‘older’ versions. It’s just a waste of time, for which I will
not
be paid.
And although my minimal scenario probably doesn’t apply to the vast majority of the millions (billions?) using WordPress, I’d say that from the perspective of those who have to keep those sites running, ‘forcing’ an upgrade for the sake of more security, more features and more efficiency is the way to go.
Personally I had no idea that was any support for WordPress for
nine
years or even
more
. I think that’s insane. I’m ok with whatever proposal, of course, but I would definitely prefer a
shorter
‘mandatory upgrade’ period. In my experience,
most
people (and that often includes yours truly), if they
know
that they have, say, nine years to upgrade their software, they will postpone such upgrades indefinitedly — and forget all about it until, 9 years later, I get a phone call asking why the site is down. Rather, I would definitely agree with the establishment of a culture of ‘regular upgrades’ — the idea of placing all sorts of warnings of ‘impeding obsolescence’ on the WP backoffice is a wonderful idea — simply because that means that end-users, even if clueless about whatever runs ‘below’ their websites, will at least get acquainted with the notion that they have to do their upgrades every once in a while.
It’s a bit like the issue with domain names. Most of my end-users don’t have a clue what a ‘domain name’ is, why they have to regularly pay for one, or what is involved in setting one up and making sure that ‘it works’. In fact, they only figure out that something is wrong when the site disappears or no more email is coming in. In that regard, even if some registrars allow long-term registration with discounts (say, 5 years…), these are actually counter-productive IMHO — because the end-user will just be bothered twice per decade and obviously not remember what they did have to go through on the last time they defaulted on their payments… while, on the other hand, having domain names being paid every year means that end-users will very likely figure out a way to automate the process so that they don’t need to bother with it every year.
The same, IMHO,
should
apply to PHP and, ultimately, WordPress. If end-users are made aware that they have to do a major upgrade ‘every year or so’, they will be better prepared — at least psychologically — to deal with often-recurring upgrades, and that means keeping up to date with the latest stable versions. Remaining stuck with a 9-year-old WordPress installation ‘just because we can’ is, well… a risky attitude, inviting hackers, scammers and spammers to easily defeat old, well-known security flaws. And then it’s up to sysadmins and website designers to clean up the mess…
It’s also not only WordPress: it’s the whole ecosystem with its plugins and themes. When WP (or PHP…) gets bumped up a version or two, things start to fail.
Plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
maintainers who have been very active in the past may have, for all purposes, abandoned them (again, I’m guilty of having that attitude as well towards my own few published plugins… I simply cannot keep up with everything!); by contrast, those who constantly upgrade their plugins and themes will necessarily ‘bump up’ their own code to the latest & greatest — and if end-users are reluctant to do the same to WordPress + PHP + MySQL, well, their sites will stop working. Simple.
So, sure, I subscribe to this proposal, and I’d be more than fine with even shorter support times (anything over 5 years is, IMHO, excessive).
I can relate to this (I have one server that I can’t update
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
because the database code is spaghetti).
But I come to a different conclusion, based on WP’s history. I can keep running the same old version, and it will get security updates, although my plugins won’t.
This is the mentality we have trained our users to. This is what we need to address with some changes in policy.
WP is after all,
GPL
GPL
GNU General Public License. Also see
copyright license
, so it is offered “as-is, no warranty”.
For the specific case of
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
support, I’m not a fan of the fixed schedule and would prefer to remain fixed on usage numbers instead.
My main objections would be that: switching to fixed schedules has never went well for us in the past, and that by trying to adhere to such timeframes, we don’t leave enough flexibility to account for users or what hosts do.
While it’s a nice thought to provide support only back to a certain point, the truth of it is that unless we are explicitly using those new features of the new versions in the code, then there’s nothing preventing us from simply writing the core code to also work on older versions.
Back when automatic daylight savings time (timezones) support was introduced, we still supported
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
4. Now, at the time, PHP 4 and 5 were very different, and adding in such support for PHP 4 was not feasible. So there were checks added to detect when the PHP 5 functions were available, and the code was jiggered to work differently with it. Eventually, PHP 4 support was dropped, and a fair amount of that back-compat code was removed, but that was a long time in the process before we could really get to that point, because hosts had not updated and so forth.
While we’re at the point where most hosts are starting to offer PHP 7 support properly, I feel it’s not quite at the point to say we can use those features. PHP 5 is still used by a bit under 25% of the userbase, so fixing the timeframes to move forward even unto PHP 8 doesn’t seem reasonable.
The argument about whether PHP supports their versions of not don’t really apply to WordPress. We write code to work for users, which means supporting whatever their hosting service runs, regardless of whether the PHP developers support it or not. Sometimes that means taking on the technical debt of making backwards-compatible code.
Obviously, none of this applies to
plugin
Plugin
A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory
or can be cost-based plugin from a third-party.
or theme authors, who can easily write whatever they want and only support PHP 7 and up if they choose to. We’ve added requirement messages and support to the
API
API
An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.
to allow them to do that, and to have older systems not try to update to code which requires newer ones.
But for core, I don’t think we should consider a plan that abandons users and WordPress installations based solely on time rather than data received. When the numbers show that PHP 5 is much smaller than 25%, then sure, we can discuss dumping support for it. Until that happens, we shouldn’t try to push, because all that does is to put users in spots where they’re running old code with no upgrade path available to them. Users are at the mercy of their hosting service, and we’ve had success in getting those hosting services to upgrade. That seems like the continued and logical path to follow. Using the users inability to upgrade as leverage to force hosts to change is not in their best interests, nor ours.
Just my 2 cents.
What are your thoughts on the characterization of most of that 25% as ‘zombie users’?
Because its not as if those users’ websites will stop working, they just won’t be able to upgrade to the latest and greatest version of WP (which many don’t seem to be doing anyway).
Giving them the name “zombie” doesn’t mean that they don’t exist.
A site that nobody visits doesn’t phone home to check for updates and thus we can’t include it in our stats.
So, those are *active* sites, in some fashion. Even if they’re unmaintained, they are still being actively used to some degree, and so we should care about them as well. Simply discounting them and putting them behind some label doesn’t mean that they don’t matter. If we leave them no upgrade path, then they certainly will never be upgraded.
Frankly, I hate those graphs. Those pies have too many slices on them. I want to see a single slice that says 99.9% of all sites running “WordPress”. I don’t want there to be a version number. I hope that before we get to WordPress 10.0, we eliminate versions and just have the software auto-updated everywhere, to the latest and greatest code. This notion of fragmenting the userbase here seems antithetical to that, because it’s only adding more slices to the pie instead of reducing them.
So, based on
clorith
data at:
I have made this little summary of the data:
So, in a year:
BAD
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
= -31.784%
I heartily support this change, and transparency around this decision. I see no downsides to the proposed plan.
To visualize the
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
compatibility I’ve created a chart of
Supported PHP Versions
for each WordPress version. Hope this will bring clarity around past PHP compatibility.
Talked to
jrf
about the data and the chart. In the future there will be an extra data layer showing whether the PHP version was actively supported at that time or not.
Reading through this post the first thing that seems strange is this:
Additionally each WordPress release will receive security updates for four years.
Why would such decision be made in a proposal on the timing for bumping minimum
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
version? Sorry but this seems quite out of scope here.
Officially WordPress supports only the latest “major” version, like 5.4, 5.5, 5.6, etc. There may be security updates for old (and very old) versions but there aren’t any feature fixes and/or updates. Trying to propose a change to a “support period” of 4 years here is not appropriate imho.
In that terms, all references to “nine years” in the post should be read as “five years”. This clearly reflects the current situation and doesn’t make the proposal any different.
If I’m reading this (long and very “picturesque”) post right, the “proposal” is to enforce when WP bumps its minimum required
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
version.
The tl;dr is to take version bump control out of the hands of the WordPress devs and give it (indirectly) to the PHP devs by matching the PHP release schedule + 5 years.
I don’t have particularly strong feelings either way, what’s good for PHP is generally good for WP 🙂
On the other hand removing freedom/control from the WP devs is not a good thing. This means minimum PHP version will have to be bumped whether or not that would benefit WP, but also that the version cannot be bumped to a newer one when that will benefit WP. Thinking that the second case is unacceptable.
In that terms I’m “against” the proposed schedule being enforced, and “for” the schedule being published and followed as “strongly recommended”.
It’s not in control of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
developers. The match of the release cycles is incidental.
Yes, yes, and more yes.
Honestly, if it were me, I’d make the LTS promises two years. Four years is
extremely
generous, but I imagine that might be precisely the point since we’re talking about WordPress. In any event, setting these hard requirements will ultimately be nothing but good for the entire WordPress community. ❤️
People have been reaching out thinking I support this proposal. I support it being posted and discussed, but not the conclusion. I’ve read all the comments posted so far.
The right policy for WordPress
core
Core
Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
is to have users drive what we support, measured by usage, not other projects with their own priorities and stakeholders.
As Otto pointed out, plugins can choose their own requirements if for whatever reason they need to require newer versions of
PHP
PHP
The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher
, but core doesn’t.
I do think we can help get PHP5 below 5%: There are two hosts with a lot of participation in the WP community that host a significant number of PHP5 sites. I have spoken to both, and have heard from the CEO of one that they’re prioritizing getting these sites upgraded, even if it means going one by one. The other host is still investigating what they can do but I’m optimistic.
I would love any help from the hosting group or other people in the community asking hosts to prioritize upgrades, and I’d be happy to personally hop on a call with any executives to make the business case for why they will actually save a ton of money and support time getting their sites on the latest and greatest WP and PHP.
Comments are closed.
Site resources
Email Updates
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
Join 6,695 other subscribers
Recent Updates
Recent Comments
No Replies
Current Release
The current release in progress is
WordPress 7.0
. Planned future releases are listed on
the Project Roadmap
. Feature projects not tied to specific releases can be found on
the Features page.
Regular Chats
Note:
All chats happen on
Slack
Weekly Developer Meetings
: [time relative]Wednesday 15:00 UTC[/time] in
#core
About the Dev Chat
Agendas
Summaries
Performance Weekly Chat
[time relative]Tuesday 15:00 UTC[/time] in
#core-performance
New Contributors Chat
The 2nd and 4th Wednesday of every month at 17:00 UTC in
#core
See all meetings →
Recent Posts and Comments
Team Pledges
2664 people
have pledged time to contribute to Core Team efforts! When looking for help on a project or program, try starting by reaching out to them!
compose new post
reply
edit
go to top
go to the next post or comment
go to the previous post or comment
toggle comment visibility
esc
cancel edit post or comment
Loading Comments...
You must be
logged in
to post a comment.