The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Remove jQuery Migrate 1.x. This is planned for WordPress 5.5.
Update to the latest version of jQuery and add the latest jQuery Migrate. This is tentatively planned for WordPress 5.6 depending on test results. Updating to the latest jQuery UI, version 1.12.1, is also planned for 5.6.
Remove jQuery Migrate. This is tentatively planned for WordPress 5.7 or later, depending on testing.
As planned, a Test jQuery Updatesplugin was released to make it easy to test different versions of jQuery, jQuery Migrate, and jQuery UI. Please install it and thoroughly test if everything works as expected, especially on the front-end, or at the settings pages of other WordPress plugins.
How to help with testing
The plugin has a settings screen found under the Plugins menu in WordPress admin. Different versions of the jQuery libraries can be selected there for testing. Please test by:
Disabling jQuery Migrate, and leaving jQuery and jQuery UI at the default versions (for WordPress 5.5).
Test jQuery Updates settings screen, under the Plugins menu.
Updating your code
To get ready for this jQuery update, it’s important that you update your code. The migrate plugin will assist you in identifying issues. Additionally, the jQuery Core 3.0 Upgrade Guide and 3.5 Upgrade Guide provide detailed information about what has changed. As the browser supported list is also updated, this is also a great time for you to revisit what versions of browsers are supported by your themes and plugins.
How exactly would migrating WP core to vanilla, and then leaving jQuery as an optional dependency with a depreciation notice that devs should be using es6 + wp.scripts whenever possible break back-compat?
migrating WP core to vanilla, and then leaving jQuery as an optional dependency…
Right, the long term goal is to gradually migrate WP Admin to Vanilla JS. There is a lot of code to migrate, so it will take a while… Patches are welcome 🙂
Even if all of WP Admin is migrated to Vanilla, the jQuery libraries and plugins will still be available to enqueue through Script Loader, to maintain backwards compatibility.
Best place to get involved in migrating WP Admin to Vanilla JS is to just do it 🙂
Identifying some (old) code that can be converted, opening a Tracticket and adding a patch, and mentioning it in Slack would most likely bring other people that are interested.
Such a great news. Google PSI and Lighthouse is always telling update the jQuery. It has lots of vulnerabilities. Happy to hear it’s finally getting updated.
But on a side note I really think WP core should push devs to start using vanilla JS or Vue and stop using jQuery. Honestly jQuery is a lost cause. Javascript has come a long way since the jQuery days.
I tried out the plugin and so far everything works as expected, great work @azaozz! In the past we had seen issues with certain parts of the customizer breaking when we upgraded jQuery.
Thanks! Yes, I’ve heard about issues with some parts of the Customizer, but haven’t seen any, yet. Perhaps jQuery 3.5.1 plus jQuery Migrate 3.3.0 fixed them 🙂
If you know your plugin won’t work on older WP, you should:
1. Update the plugin headers so “Requires at least:” is set to the version you now support
2. Put in a version check on activation “If WP is less than 5.5, auto-disable”
The first one should prevent people on older WPs from updating, the second makes sure you don’t crash them.
__( 'This plugin can not be activated because either your WordPress instalation has an outdated/unsuported PHP version or you are using an outdated/old WordPress version.<br><br>This plugin requires a minimum of <strong>PHP 5.6 or greater</strong> and <strong>WordPress 4.9 or greater</strong>.<br><br> Your install:<br><strong>PHP: ' . PHP_VERSION . '</strong><br><strong>WordPress: ' . $wp_version . '</strong><br><br>You need to update either one of them or both, before you are able to activate and use this plugin.<br>- <a href="http://wayback.fauppsala.se:80/wayback/20200829174030/https://wordpress.org/support/update-php/" target="_blank" rel="noopener noreferrer">Learn more about updating PHP</a><br>- <a href="http://wayback.fauppsala.se:80/wayback/20200829174030/https://wordpress.org/support/article/updating-wordpress/" target="_blank" rel="noopener noreferrer">Learn more about updating WordPress</a>', 'wp_jquery_manager_plugin' ),
In WordPress 5.5 we introduced the new wp_get_environment_type function which allows retrieving the type of environment the current system is. We originally allowed changing the environment types, which we’ve decided is a mistake. It makes it so that plugins and themes can’t rely on any given environment being one of a limited and known list of types, and thus can’t rely on the feature.
For this reason, as of WordPress 5.5.1 it will no longer be possible to override the list of possible environment types.
Which environment types do we have?
The following environment types will be supported as of 5.5.1:
production – this is the default. A site that is running live, connected to the internet and reachable on the internet.
staging – this is what you would use for staging environments, probably both connected to and reachable on the internet.
development – this is what you would use for development environments that are reachable on the internet, we automatically enable WP_DEBUG on environments where this is the environment type.
local – added in 5.5.1, this (usually development) environment can reach the internet but is not be reachable from the internet.
By limiting the set of environment types in this way, WordPress core, plugins, and themes can change their behavior depending on this setting.
What happens if you changed the setting?
If you’d already set an environment variable to allow changing the environment types, this will no longer function. If you’d set the WP_ENVIRONMENT_TYPE constant to something else than one of the four allowed environment types, it will reset to production.
It’s nice to see some clearer definitions of the different types as part of this change.
Is it worth calling out what “use for staging environments” vs “use for development environment” means, especially since that’s the primary thing that separates staging/development/production? There’s an assumption here that there’s a common / shared understanding of what those are.
Dev is generally in progress, often uncommitted, sometimes broken code.
Staging/test, is waiting for sign off from a stakeholder.
Production/live, self explaintory?
Most best practice workflows involve the code moving from dev to staging, and the database moving from production to staging, so you can spot any problems before moving the code on to production. Smaller teams or individual developers will often skip the staging step since they are not integrating code from multiple features/developers and just pull the live database into dev. Bigger teams often have PII issues to consider and so often cannot just ship the production db to dev.
forward movement + momentum on some of the bigger projects of Gutenberg, like Widgets, Full site editing, and the Post Block suite
Improved UI for accessibility and mobile, especially surrounding Toolbar and pop-up like components (like menus and Popovers)
there also appears to be a tiny performance improvement compared to 8.7.
@itsjonq ended the overview of this new release by giving huge personal thanks to everyone who helped me before/during the release process to help get 8.8 out.
I’ve started in on Block Directory work. I’m starting in on updating the current install flow (via block inserter search). I’ve already got some good feedback that I am using to make a new iteration that should be posted in an hour or two. I will also be exploring block management in and out of the editor.
I’ve been focused on other tasks the past week. For the next week, I’m continuing work on the global styles sidebar at site edit & controlling the block editor.
I’ve continued focusing on the “G2 Components” project.Enough of the foundations have been designed/built, so I’m starting to explore large things like:
Prototyping/Building large/complex UI
Documentation (to support prototyping/building)
Tooling to improve design/dev experience
I’ve continued to host Zoom sessions where I collab design/dev things in G2. I plan on continuing! They’re wonderful .I’m blogging all notable updates here.
Thank you for the work that is happening and does not make it into this list!
I’m here to flag that 5.5.1 will be released a bit more quickly than usual because of some pesky bugs that were discovered. It would be great if some block editor bug fixes were included! Happy to help if needed. The proposed schedule was just published.
Woohoo! I’m starting the “What’s Next” post for September and wanted to check in with this crew collectively to see what will be the focus for the month including any specific PRs, discussion issues, etc you’d like to flag. Don’t need to cover it all in this meeting but high level items would be lovely
@andraganescu the work on the new editors (Navigation and Widgets) will continue in September
@youknowriad I see a continuous effort on “Controlling Block Editor APIs” as well, I’m hoping to “finish it” on September if things go well.
I want to raise that we want to move those editors out of experimental. There is a great deal of work still happening and still needed, but it’s important that they become visible sooner rather than later.
@mapk With Matias’ recent feedback on the Widget Editor, I think this can happen. It appears we’re keeping a closer tie-in with my initial designs which are pretty much implemented.
@paaljoachim I was thinking about the general importance of drag & drop. How we can improve it in Gutenberg?
A discussion followed suggesting we add drag and drop in select mode and debating how it should work when writing
Wondering if, in conjunction with any documentation being done for getting setup to do testing, if there wouldn’t be someone willing to do a zoom for folks interested in getting all the tooling needed to get started. It’s a bit of a barrier of entry for some folks.
@mkaz announced in a follow-up that he’ll be hosting a “hallway hangout” session on contributing documentation to Gutenberg repository. It will be an introduction covering GitHub PR workflow and environment setup. The session will be on Tuesday, Sept 1st @ 1600 UTC / 9:00am PDT. It will be recorded and posted for those who can not make it.
See @audrasjb post for details on the scheduled maintenance release for WordPress 5.5.1 after a handful of bugs were identified on WordPress 5.5 “Eckstine”. The first Release Candidate is planned to be on Thursday, August 27, 2020, and the Final release planned to be on Tuesday, September 1st, 2020 estimated time 20:00–21:00 UTC or later depending on work to be done on the remaining tickets.
see @thewebprincess post on the dev chat – APAC Edition Meeting Summary – August 20 2020. “… the group is discussing changing the timing, and also proposed the probability of renaming both chats to equalise their weight a bit more”. There was a suggestion to identify the dev-chats by time using the UTC timezone. However, some from the group pointed out that because of daylight savings it might be confusing and complicated to identify the dev-chats by time. View the discussion here. The discussion is still ongoing. To make a comment/contribution reply to @thewebprincess post.
Components check-in and status updates
The first CoreCSStriage is being hosted today at 4pm EDT in the #core-css channel. One hour before the weekly Core CSS chat.
@carikee flagged milestone tickets for privacy initiatives that still open and need to be looked at #51092, #51110 & 51144.
There is nothing of note from the Build/Test Tools component at the moment other than the before mentioned post about PHP updates.
Open Floor
The meeting pivoted into a 5.5.1 pre-RC scrub run
Ticket#50910 has had some testing but could use some more tests. It is hopefully going to land for 5.5.1-RC1, so the more eyes the better similarly for #51129.
@carikee asked committers for their input on whether to use the REST API to expose user consent on the front-end. Also, the need to add the extra 10KB or so to expose wp.data to the front end.
The meeting continued as a 5.5.1 pre-RC scrub run by @desrosj.
Next Dev Chat meeting
The next meeting will take place on Wednesday, September 3, 2020, 10:00 PM GMT+2 in the #coreSlack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.
Shortly after WordPress 5.5 “Eckstine” was released, a small handful of tickets were opened reporting identified bugs. Because a few of them are particularly inconvenient, 5.5.1 will be a short-cycle release so that they can be addressed more quickly.
Hi and thank you for your comment and for opening this ticket!
This one was milestoned earlier today since the bug has been reproduced by another contributor, but it won’t probably make it for 5.5.1 as it still needs a patch. It’s currently milestoned for 5.5.2, waiting for someone to propose a patch for this issue.
We discussed doing a triage every two weeks one hour before the weekly meeting. @kburgoine will lead the first one this week, on August 27 at 4pm EDT!
CSS audit updates
@isabel_brison added the media query counts to the CSS audit doc, the last remaining item! She mentioned finding that the audits were running on .css.orig files which was bloating the counts. We discussed that these and .rtl files should not be included in the counts because they are not authored files.
@kburgoine asked if the audit counts are including block editor CSS. We discussed that for now, the audit only includes wp-admin and wp-includes, but the tooling we have can be used for other code-bases. @ryelle suggested documenting the steps for running audits similar to these steps for pulling color data.
The next step for the audit is to update the counts excluding the .css.orig files, and @isabel_brison volunteered to do that in the coming week.
Color scheming updates
@ryelle re-ran the core color extraction steps using the approach referenced above, and the list of unmatched colors is now much more concise. This is quite a useful tool! @ryelle identified that the excess colors were coming from Gutenberg. Since the colors are much more manageable now, it will make sense to go to design for feedback a bit later in the process once the PostCSS piece is in place and we can see the reduced colors in wp-admin.
@kburgoine asked if there was any way to break down this task into smaller pieces – it is a lot of work for one person. @ryelle said that later in the process, once we have files with the reduced colors, there will be many smaller tasks such as manual cleanup and testing that will be fit for more contributors.
Open Floor / CSS Link Share
There were no open floor topics.
@kburgoine shared a very slick Codepen that changes the font weight of a menu item on hover, without causing a reflow/jump on following menu items!
For the Open Floor:
I have been chatting with @mapk regarding this issue: http://wayback.fauppsala.se:80/wayback/20200829174030/https://github.com/WordPress/gutenberg/issues/24561
We were talking about drag & drop in regards to dragging widgets between widget areas, but then we began to talk about the importance of using drag & drop. How important is drag & drop? What can we do to improve this feature?
While most people here will probably mostly know me as a (PHP) 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 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 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 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/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 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!
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 and WordPress Developers, we track our PHP Version and what WP requires on a constant. Cheers 🙂
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.
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 releasebranch 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 of PHP, 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 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 is found in a newer version then if it affects the older version a patch 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 developer, but even if I never worked for core I work in application and plugin 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 X. And they will. The fact that core might technically work with the version Y 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 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 X 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, such as cryptographic features, and exploits centred around timing.
You could argue that hosts “patch” 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 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.
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.
Regarding GoDaddy, what Nick mentioned is true. To upgrade to PHP 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.
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 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?
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 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 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 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 and extensions development.
This entire discussion could be much more informed with the data on intersection of PHP 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 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.
User switched to PHP 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.
Between December 2024 and December 2028, WP 6.7 would still receive security updates = 4 years of security support
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 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) 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?
I believe the reason for this is many years of having to support PHP 5.2. This potentially caused some plugin 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.
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.
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.
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’s 3. But sure, if 5+4 is what is going to happen for now, I’ll take it! 😀
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 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 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, 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!
I 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 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 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 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, 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 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 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 bar and Post Formats…
– 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 support cycles.
This is a very bad idea. The success of the PHP 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 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 changes suggested.
For comparison, Ubuntu LTS Longterm support releases last 5 years, React didn’t exist 7 years ago.
So effectively this means that we cannot use PHP 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 for development, and then use Rector to convert the code to a lower version of PHP and generate the theme/plugin 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’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.
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 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, 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, 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.
I’d suggest working with the biggest enterprise Linux vendors (Red Hat and Canonical at least) to make sure your PHP 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 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. 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 proposal, especially around backporting Site Health. Bonus if we’re able to trigger an email to the site 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 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.
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 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 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 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”.
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.
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 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 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 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 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 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. 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 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.
Why waste time on old PHP 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 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 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 and rejecting supporting of new PHP release. As regular WordPress plugin dev, I think WordPress need to synchronize minimum supported PHP version with PHP Team timeline +1 year.
I am for syncing the WordPress supported minimum PHP 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 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 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 security fixes for many old releases.
Each WP version only runs on certain PHP 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 version X” field for plugins/themes, as well as an accompanying notice on the updates page to inform the admin that some of their plugins have not been tested with the latest WP and/or PHP versions.
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 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 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 security fixes for WordPress versions up to four years back.
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 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? From my read, the proposal seems to primarily benefit developers — but I might be missing something, so I thought I’d ask!
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 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 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 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, 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 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 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 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 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/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 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 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, so it is offered “as-is, no warranty”.
For the specific case of core 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 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 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 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.
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.
Great news! I wish this was in 5.0!
I’m really exciting about this. This helps improving performance of websites and make WP sites look more “modern”.
Wow, this is great news, I’m sure a lot of people will love it. By the way, I did my bit by translating the plugin into Spanish.
Thank you! Yes, would be great if the explanation and testing instructions on the Test jQuery Updates settings screen are translated.
Since I have been using jQuery 3.x for years nows, I’m happy to see this change in core soon. Nice work!
That’s great! Have you run into any compatibility issues with core or WP themes or plugins?
Awesome!
This is great news 🙂
This is great news, but stops here?
It’s well known issue that jQuery size grows over time:
http://wayback.fauppsala.se:80/wayback/20200829174030/https://mathiasbynens.be/demo/jquery-size
and current one (3.5.1) is 287630 bytes, minified is 89476.
Why not announce “End of an era.” by switching to Vanilla JS?
Or Vue
Because this will break 1/3 of the web (+/-).
Never gonna happen.
How exactly would migrating WP core to vanilla, and then leaving jQuery as an optional dependency with a depreciation notice that devs should be using es6 + wp.scripts whenever possible break back-compat?
This is an amazing idea. I wish it was possible. But I’m sure it’s not gonna happen as it will break a lot of websites.
Right, the long term goal is to gradually migrate WP Admin to Vanilla JS. There is a lot of code to migrate, so it will take a while… Patches are welcome 🙂
Even if all of WP Admin is migrated to Vanilla, the jQuery libraries and plugins will still be available to enqueue through Script Loader, to maintain backwards compatibility.
where to start?
@azaozz best place to get involved is the js slack channel or somewhere else?
Best place to get involved in migrating WP Admin to Vanilla JS is to just do it 🙂
Identifying some (old) code that can be converted, opening a Trac ticket and adding a patch, and mentioning it in Slack would most likely bring other people that are interested.
(Old) jQuery plugins can also be replaced if they have Vanilla equivalents. See http://wayback.fauppsala.se:80/wayback/20200829174030/https://core.trac.wordpress.org/ticket/47069.
I’m glad this is proceeding!
Such a great news. Google PSI and Lighthouse is always telling update the jQuery. It has lots of vulnerabilities. Happy to hear it’s finally getting updated.
But on a side note I really think WP core should push devs to start using vanilla JS or Vue and stop using jQuery. Honestly jQuery is a lost cause. Javascript has come a long way since the jQuery days.
I tried out the plugin and so far everything works as expected, great work @azaozz! In the past we had seen issues with certain parts of the customizer breaking when we upgraded jQuery.
Thanks! Yes, I’ve heard about issues with some parts of the Customizer, but haven’t seen any, yet. Perhaps jQuery 3.5.1 plus jQuery Migrate 3.3.0 fixed them 🙂
Is there an official suggestion for plugins to be compatible with older versions of WP once they update their jQuery to be 3.x compatible?
If you know your plugin won’t work on older WP, you should:
1. Update the plugin headers so “Requires at least:” is set to the version you now support
2. Put in a version check on activation “If WP is less than 5.5, auto-disable”
The first one should prevent people on older WPs from updating, the second makes sure you don’t crash them.
I check both on minimum PHP version and WP version. I hope somebody could use this. This is what I do:
// Activation processregister_activation_hook( __FILE__, 'wp_jquery_manager_plugin_activation' );function wp_jquery_manager_plugin_activation() {if ( ! current_user_can( 'activate_plugins' ) ) {exit;}global $wp_version;$php = '5.6';$wp = '4.9';if ( version_compare( PHP_VERSION, $php, '<' ) || version_compare( $wp_version, $wp, '<' ) ) {deactivate_plugins( basename( __FILE__ ) );wp_die('<p>' .sprintf(__( 'This plugin can not be activated because either your WordPress instalation has an outdated/unsuported PHP version or you are using an outdated/old WordPress version.<br><br>This plugin requires a minimum of <strong>PHP 5.6 or greater</strong> and <strong>WordPress 4.9 or greater</strong>.<br><br> Your install:<br><strong>PHP: ' . PHP_VERSION . '</strong><br><strong>WordPress: ' . $wp_version . '</strong><br><br>You need to update either one of them or both, before you are able to activate and use this plugin.<br>- <a href="http://wayback.fauppsala.se:80/wayback/20200829174030/https://wordpress.org/support/update-php/" target="_blank" rel="noopener noreferrer">Learn more about updating PHP</a><br>- <a href="http://wayback.fauppsala.se:80/wayback/20200829174030/https://wordpress.org/support/article/updating-wordpress/" target="_blank" rel="noopener noreferrer">Learn more about updating WordPress</a>', 'wp_jquery_manager_plugin' ),$php). '</p> <a href="' . admin_url( 'plugins.php' ) . '">' . __( 'go back', 'wp_jquery_manager_plugin' ) . '</a>');}}See example on GitHub:
O! this is great news!
wow, finally this is proceeding! 😀