Minimum PHP version in Plugins

[TJNowell]

If I write a plugin that uses namespaces, and test locally and find no issues, everything is okay for me.

However namespaces is a PHP 5.3 feature, and a significant portion of the userbase is on 5.2.x.

Given the rise of PHP 5.3 usage, and oncoming 5.4 features, I'd like to be able to declare that such a plugin requires PHP 5.3 minimum else it will break, and for WordPress to respect this if the plugin is installed on a 5.2.x server by preventing activation of a plugin that is guaranteed to cause a fatal error as a result.

e.g. for one of my own plugins:

<?php
/*
Plugin Name: Local Indicator
Plugin URI: http://tomjn.com
Description: Indicates the current server used via a colour coded IP in the top admin bar, useful for telling live and Local dev environments apart
Author: Tom J Nowell, Interconnect/IT
Version: 1.3
Minimum PHP: 5.3
Author URI: http://tomjn.com/
*/

[F J Kaiser]

+1

[sergej.mueller]

Minimum PHP:
Minimum MySQL:

[sanchothefat]

+1

[lkraav]

TJN knows what he's talking about

[interconnectit]

I like the idea of this, but I think it needs quite a bit of consideration to make sure it's done the right way. Consequently I suspect the core team will bounce this...

For example, what happens is a working site is migrated to a different server that conforms to the WP minimum standards? The site would blow up as various plugins with different minimum PHP requirements suddenly threw up a whole series of error. It would make migrations a lot less fun.

It's definitely a nice idea, but it's more complex than the initial notes suggest.

[TJNowell]

Replying to interconnectit:

I like the idea of this, but I think it needs quite a bit of consideration to make sure it's done the right way. Consequently I suspect the core team will bounce this...

For example, what happens is a working site is migrated to a different server that conforms to the WP minimum standards? The site would blow up as various plugins with different minimum PHP requirements suddenly threw up a whole series of error. It would make migrations a lot less fun.

Two scenarios, either this is implemented, and the plugins are disabled, at which point the site may or may not blow updepending on how many other plugins rely on it and how well built they are.

Or, it isn't implemented and we get the current situation, aka the site blows up anyway and someone has to SSH in and disable the plugin manually

The alternatives being:

Implement a PHP based check in the plugin'

Then include the rest of the plugin if it passes. This is somewhat of a kludge, and adds additional performance cost. It's a tiny price to pay on a single plugin, but on 50 plugins it's a hassle, and it still leads the suer to activating a plugin then wondering why it isn't showing, and having to implement warnings and notices etc Not to mention that it forces implementation details on plugins that could be problematic.

One could also throw an error in the plugin activation.

Both fall apart in the above scenario of switching servers, both fall apart if a PHP call is made in the global scope that requires said minimum version, and the latter breaks when you update a plugin and the author has raised the minimum requirements

Implementation Logic Would thus need to:

• check current PHP version
• if it's lower than the minimum req of a plugin, do not show the activation, and warn in the search listings
• If said plugin is already activated, deactivate it, this should be done in the same place as the checks to see if the plugin folder/file still exists
• If an update is available and the min req version has changed, notify of the update but disable the checkbox and update button/links with an explanation "Update Requires PHP vXYZ"
• Repeat for whichever other minimum requirements are implemented

[codearachnid]

Replying to TJNowell:

One could also throw an error in the plugin activation.

Both fall apart in the above scenario of switching servers, both fall apart if a PHP call is made in the global scope that requires said minimum version, and the latter breaks when you update a plugin and the author has raised the minimum requirements

I think server migration definitely needs to considered but not necessarily a reason to shelve the idea. I would foresee some sort of "disable by notice" of activation until the conditions are met. Although as far as true test goes I think it should be more of a tag option verses true functionality disabling. I use a similar implementation on my own plugins already and don't feel that it would be expensive to run a basic type of check for this sort of thing. Ideally it would also help with filtering of plugins with the .org repos.

[F J Kaiser]

Replying to interconnectit:

For example, what happens is a working site is migrated to a different server that conforms to the WP minimum standards? The site would blow up as various plugins with different minimum PHP requirements suddenly threw up a whole series of error. It would make migrations a lot less fun.

From the original note: "by preventing activation of a plugin that is guaranteed to cause a fatal error"

If your code/theme doesn't respect if a plugin isn't active, then it's your (themes) fault.
Before you update WP to a newer version, you have to do several checks and tests if your site will still work. The same goes for a new server.

If you look at the ​list of requirements on wp dot org, you won't find cURL or the GD library mentioned - which are just the tip of the iceberg of what's needed to run WP smoothly. If your server doesn't offer the needed PHP version to run everything you want (like a specific plugin), you have to search for a new host. And the same goes for several other requirements like memory, disk space and PHP extensions which may be required by a plugin that you want to use.

I think this ticket does a lot: It doesn't only guarantee that an installation will still run when a plugin doesn't meet the requirements, it will as well offer a possibility to write future proof code that devs will use. And this might lead to more people pushing their hosts to upgrade their PHP versions. Maybe it will as well enable WordPress to move to a fresher PHP version much sooner than we all thought. As everybody knows: WordPress lives and dies by its ecosystem of themes and plugins. And people can and will adept to it.

[markoheijnen]

I don't think we should implement this in core. To me a plugin should work on every WordPress installation. That to me does make a plugin good or not. Obviously stuff added to 5.3 and 5.4 is cool to use.

The migration problem isn't one to fix. The reason is that you would need to check the PHP/MySQL version on every request to really do it well and that is a performance penalty.

[TJNowell]

Replying to markoheijnen:

I don't think we should implement this in core. To me a plugin should work on every WordPress installation. That to me does make a plugin good or not. Obviously stuff added to 5.3 and 5.4 is cool to use.

The migration problem isn't one to fix. The reason is that you would need to check the PHP/MySQL version on every request to really do it well and that is a performance penalty.

This is naive, while we'd like this in a perfect world, we don't live in a perfect world. PHP 5.3 offers solutions to problems that aren't fixable in 5.2, name spacing being a major example. They weren't added on a whim.

What's more, other libraries that a plugin might require weren't built for WordPress. What if I built a plugin that by its very nature required use of a library that was built with 5.3 in mind?

[markoheijnen]

Replying to TJNowell:

Replying to markoheijnen:

I don't think we should implement this in core. To me a plugin should work on every WordPress installation. That to me does make a plugin good or not. Obviously stuff added to 5.3 and 5.4 is cool to use.

The migration problem isn't one to fix. The reason is that you would need to check the PHP/MySQL version on every request to really do it well and that is a performance penalty.

This is naive, while we'd like this in a perfect world, we don't live in a perfect world. PHP 5.3 offers solutions to problems that aren't fixable in 5.2, name spacing being a major example. They weren't added on a whim.

What's more, other libraries that a plugin might require weren't built for WordPress. What if I built a plugin that by its very nature required use of a library that was built with 5.3 in mind?

Namespacing isn't something a plugin needs. It's helps you out to structure code. So it's not naive thinking when you can make the plugin working on 5.2 by not using namespacing. It wouldn't work less.

Libraries is indeed an issue and I also sometimes use them. However I would never release the plugin on .org.

[TJNowell]

Replying to markoheijnen:

Replying to TJNowell:

Namespacing isn't something a plugin needs. It's helps you out to structure code. So it's not naive thinking when you can make the plugin working on 5.2 by not using namespacing. It wouldn't work less.

If your plugins share common code, namespacing is a massive help to prevent conflicts and clashes between differing versions. Sure on a clients machine you can separate them out into some kind of library plugin but on org that isn't as feasible

Libraries is indeed an issue and I also sometimes use them. However I would never release the plugin on .org.

I'd be apprehensive about this too, but if your plugin is already on org when the library makes a shift to 5.3 while making the 5.2 version unusable? E.g. a social network API

But if I had a perfectly working plugin working under 5.3, I'd like the option to put it up responsibly, warning 5.2 users, rather than backporting to 5.2 which could be a lot of work, then undoing all the work when WordPress shifts to 5.3.

Other examples might be an example plugin demonstrating clojures and other 5.3/4 features for tutorial purposes

For reference here are the 5.4 and 5.3 new features:

​http://www.php.net/manual/en/migration53.new-features.php
​http://www.php.net/manual/en/migration54.new-features.php

There are other changes such as compatability breaking changes, deprecations, and bugfixes, not to mention significant performance boosts

[MikeSchinkel]

Replying to TJNowell:

Replying to markoheijnen:

Replying to TJNowell:

If your plugins share common code, namespacing is a massive help to prevent conflicts and clashes between differing versions. Sure on a clients machine you can separate them out into some kind of library plugin but on org that isn't as feasible

I've built a ​library manager for this purpose, to allow multiple plugins to embed the same library but only have one of them loaded into memory. I'd love to see a similar concept included in core but I have a lot of blog-advocacy to do before I add a trac ticket about it to ensure people actually understand it and why it's a good solution vs. other approaches.

Libraries is indeed an issue and I also sometimes use them. However I would never release the plugin on .org.

I'd be apprehensive about this too, but if your plugin is already on org when the library makes a shift to 5.3 while making the 5.2 version unusable? E.g. a social network API

But if I had a perfectly working plugin working under 5.3, I'd like the option to put it up responsibly, warning 5.2 users, rather than backporting to 5.2 which could be a lot of work, then undoing all the work when WordPress shifts to 5.3.

I agree that "just say no" is not a pragmatic answer. Unfortunately ​62.4% of WordPress users are still on 5.2.x which mean IMO it's irresponsible to publish a plugin that requires PHP 5.3 except for in unavoidable circumstances like you quote.

But if there were a "Minimum PHP" tag then lots of plugin developers would use it and disenfranchise many, many others whose webhosts haven't made the change or haven't made the change easy or obvious.

Ironically ​I suggested a "Move to PHP 5.3" campaign on Tom McFarlin's blog just a few days ago. I think the best way to solve this is get the WordPress community to make a big push for upgrading to PHP 5.3 in the next few releases with a notice of move to PHP 5.3 for 4.0, maybe including a features that are PHP 5.3-specific starting in 3.7 that would get many users to (learn how to) upgrade.

[sabreuse]

I'd much rather see a move like @MikeShinkel suggests, to keep moving core toward a higher minimum version while also supporting/nudging major hosts to do the same. Requiring a minimum version higher than core's for a plugin just messes with the end user: after all, the very great majority of users have no real control over which PHP version they're using.

I completely sympathize with wanting to use some of the newer PHP features (not to mention wanting to refactor some old ick), but a plugin in public release doesn't seem like the place to do it.

[markoheijnen]

Yeah, WordPress should make the step but I guess we need to wait at least a year. The high percentage 5.3/5.4 is just to low for now. I would close this ticket as worksforme but thats just me.

[MikeSchinkel]

Replying to markoheijnen:

Yeah, WordPress should make the step but I guess we need to wait at least a year.

Ideally the community shouldn't wait a year to start promoting the idea of moving to PHP 5.3.

[dh-shredder]

Having plugins marked as requiring certain versions of PHP could help push users to upgrade (which helps push hosts to upgrade), to allow core to then require a higher version in a faster manner.

My my view, anyway, there is no question as to whether plugins are starting to require PHP 5.3. They are. The questions should be, "How can we best work with them?" and "How can we best help users get upgraded to newer versions of PHP?"

[TJNowell]

Whether it is responsible or irresponsible as a developer to include a PHP 5.3 plugin in the wp.org repos is irrelevant, and a separate topic. Not all plugins come from the wp.org repositories and this change would still be useful in we lived in an alternate timeline were wp.org plugin repos never existed. Even then, it still doesn't resolve the problem of minimum MySQL version mentioned earlier.

If I write a plugin that uses namespaces and someone finds it and installs it on a server running 5.2, it will fail. It should instead degrade gracefully and warn the user. The user should be able to see "oh I have 5.2, it needs 5.3" and choose whether to upgrade or pick another plugin.

At the moment we have the worst case scenario as the default scenario. I would prefer that a policy of a wordpress.org specific setup did not dictate the entire ecosystem

ps: There are already plugins that require 5.3 or above on wordpress.org

e.g. ​http://wordpress.org/extend/plugins/wp-favicons/

I found a number of other plugins that tried ot do the same thing in a cursory search but had to do refactors to fix problems for people using 5.2 who reported problems as crash bugs. Those developers looked bad for writing buggy code, despite their code being perfectly fine.

[MikeSchinkel]

Replying to TJNowell:

If I write a plugin that uses namespaces and someone finds it and installs it on a server running 5.2, it will fail. It should instead degrade gracefully and warn the user. The user should be able to see "oh I have 5.2, it needs 5.3" and choose whether to upgrade or pick another plugin.

Maybe I'm missing something but your plugin can resolve this issue on it's own. Have your main file version_compare() for PHP 5.3 before require()ing any files that contain namespaces and if PHP 5.2.x then tell the user and ​deactivate the plugin. Does this not work for some reason I have not considered?

[markoheijnen]

And those developers should look bad since they didn't add a nice message on activation what MikeSchinkel describes. I just find that plugins need to solve this them self. PHP and MySQL is one thing but you still can have other server configurations that are needed.

The big problem is that most people don't know the versions they run on. Putting an error can have some users say something to their hosts that they need a newer PHP version but most people will find another plugin. Forcing hosting to upgrade is a good thing but I doubt this ticket will help to that.

I do think that this discussion should move to the hacker list. Since we don't discuss the code but the need of the feature.

[F J Kaiser]

Replying to MikeSchinkel:

Maybe I'm missing something but your plugin can resolve this issue on it's own. Have your main file version_compare() for PHP 5.3 before require()ing any files that contain namespaces and if PHP 5.2.x then tell the user and ​deactivate the plugin. Does this not work for some reason I have not considered?

Sure this does work. But you have to do it either on runtime (which most people already do) or during the register_activation_hook() callback, which is the opposite of ideal. "Better" developers will use the hook and cook their own soup while not that good devs have all different sorts of failing components or performance leaks. As core cares about the inclusion of plugins and the whole surroundings, it IMHO should as well care about those parts. It simply is core territory and not plugin material. WP core maintains an array of active plugins as well as outputting admin_notices. And this checks would be needed exactly there.

And yes, tickets are in some cases also here to discuss something. In this case (1) should we implement this and in case (2) how should we implement it.

[bpetty]

The way I see it, there's two different approaches to implementation if a plugin wants to be 5.3+ only.

First, the plugin header indication as suggested by the OP. This is only necessary if the plugin repository itself was going to conditionally do something with it, and if it did, the only suggestion here is filtering plugin search results. Otherwise it's just additional metadata that can be listed anywhere in the plugin description or installation instructions.

But that brings up the question: Why would you want your plugin hidden from search results if it's just a matter of someone upgrading their version of PHP to run it? We should be encouraging users to upgrade, right? The more plugins they find doing this, the more likely they are to take the necessary steps to upgrade PHP. Your plugin could automatically start working again the second they upgrade PHP (assuming you didn't deactivate it, and just "disabled" it temporarily instead).

The second approach here is simply implementing the requirement in the appropriate init hooks, disabling the plugin, and showing a notice of some kind. As discussed earlier, this is already possible. Is there something wrong with a simple call to deactivate_plugins($my_plugin) that make this too difficult? What would make this easier?

Regardless of what API WordPress provides for doing this, you obviously still need to make sure your main plugin file is fully syntax compatible with 5.2, and can't include anything 5.3+ until after checking requirements, so you still have nearly the same amount of work you would have to do no matter what.

There's no point in adding a new plugin file header setting as opposed to PHP plugin API if the plugin repository doesn't need it or use it for anything.

[F J Kaiser]

Replying to bpetty:

Regardless of what API WordPress provides for doing this, you obviously still need to make sure your main plugin file is fully syntax compatible with 5.2, and can't include anything 5.3+ until after checking requirements, so you still have nearly the same amount of work you would have to do no matter what.

That's not completely true. You can add comments like #, // or /**/ before you add the namespace foo statement. So checking this from core would be much easier as your plugin could be fully PHP 5.3+ compliant and wouldn't require a bootstrap file.

[TJNowell]

WordPress loads the first 8Kib bytes of the plugin file as it would a text file, so the syntax of the file is irrelevant as far as the PHP version used is concerned at that point because no PHP parsing or execution of the plugin has taken place yet. How else do you explain how WordPress knows to execute the file with the header in and not the other files?

foreach ( (array) $plugins as $plugin ) {
    if ( '.' == dirname($plugin) ) {
        if( $data = get_plugin_data(WP_PLUGIN_DIR . '/' . $plugin) ) {

And get_plugin_data() does uses get_file_data() which does:

    // Pull only the first 8kiB of the file in.
    $file_data = fread( $fp, 8192 );

Performance wise, doing it in Core would be better. Instead of every plugin checking itself, repeating the check over and over again, Core should do it all at once, giving the following benefits:

• Saves plugin developers time
• Provides a means of warning users before they go through the hassle of uploading and installing the plugin
• Can be cached in the database, so no checks may be needed at all if the plugins don't change version

To force every plugin to do this check and have an unnecessary level of indirection is to encourage bad design, and demonstrates poor architecture that's fixable.

There's all this talk about plugins in wordpress.org should be 5.2 compatible just as WordPress is, but:

• Nobody actually justified this
• Not all WordPress plugins come from the repository
• Not all WordPress installs run the latest version, and thus not all installs have the 5.2 min req yet ( though this is a problem in its own right )
• Not everyone is aware fo what PHP is capable of and which version introduced what. We're not all experts, and developer X may have used namespaces not knowing they required 5.3
• Everyone talks about WordPress being more than just a blog, if that's the case we should ask responsibly and professionally and expand our scope beyond the limited usecase of a new user loading plugins off of wordpress.org. A lot of client work goes on, and we can't anticipate all the end cases, so lets take care of the basics and at least fail gracefully rather than showing a white screen of death in various cases

Implementation Notes

We already define the minimum requirement for WordPress here:

​https://github.com/WordPress/WordPress/blob/master/wp-includes/version.php#L28

We check for WordPress min PHP&MySQL version on install here:

​https://github.com/WordPress/WordPress/blob/master/wp-admin/install.php#L150

and there's a function to do the same here:

​https://github.com/WordPress/WordPress/blob/master/wp-includes/load.php#L103

Here is the check wp_get_active_and_valid_plugins that determines the plugins to load:

​https://github.com/WordPress/WordPress/blob/master/wp-includes/load.php#L479

The first step would be to modify the get_plugin_data function to look for the minimum version:

​https://github.com/WordPress/WordPress/blob/1c816c795b0030a91f9bfa212da894575b090db6/wp-admin/includes/plugin.php#L72

This is called here in the plugins page:

​https://github.com/WordPress/WordPress/blob/55fb020e84fd46bd56668facd1f3a74be1776cbf/wp-admin/plugins.php#L238

and here in the upgrader class:

​https://github.com/WordPress/WordPress/blob/9890179bce40df7ede22ca18e5b5900825915221/wp-admin/includes/class-wp-upgrader.php#L496

We'll want to change wp_get_active_and_valid_plugins to check the PHP version accordingly and remove such plugins, preventing white screens of death, failures to load, and other issues that could arise.

The rest is informing the user via a notice bar if an active plugin is removed in the above check, disabling the activate link, and adding a note in the plugin listings that the plugin hasn't met its minimum requirements. It could even have the activate link still available, albeit with the warning showing

[bpetty]

Replying to TJNowell:

Performance wise, doing it in Core would be better. Instead of every plugin checking itself, repeating the check over and over again, Core should do it all at once

This doesn't have to be in core to be efficient and optimized, you can cache this in your plugin too. In fact, there's really nothing that needs to be cached, just check the PHP version like you would anywhere else you needed a fallback because a new PHP function wasn't available to you.

Besides, in reality, most plugins do support PHP 5.2. It's actually a rare few that have decided they can't handle the same requirements that WordPress has chosen to work with.

• Nobody actually justified this

Nobody has to. WordPress has chosen to support PHP 5.2 because that's what most people are still using, and it's not hard to support. That choice was already made for you when you decided to write a plugin for WordPress. If you want to call your plugin a "WordPress plugin", it should support the same requirements WordPress supports. Core shouldn't have to go out of it's way to ensure that plugins can implement additional server requirements that WordPress doesn't require itself. That's the very definition of an "extended" feature - which should be implemented in your plugin.

No one is saying you have to support 5.2, just that WordPress does (and would obviously recommend you do too), and as such, this isn't something we actually want to implement in core because we don't want to encourage plugin developers like yourself to write incompatible plugins if you don't actually have to.

• Not all WordPress installs run the latest version, and thus not all installs have the 5.2 min req yet ( though this is a problem in its own right )

That, on the other hand, is exactly why plugins do have "minimum WP version required" and "tested up to" header fields. It should be enough for users of your plugin to know that they have the correct version of WordPress, and not have to look up anything else (since they should have already done so when they installed or upgraded WordPress).

• Not everyone is aware fo what PHP is capable of and which version introduced what. We're not all experts, and developer X may have used namespaces not knowing they required 5.3

On the contrary, all PHP developers are very aware of this, and if not, they shouldn't be calling themselves a PHP developer. In fact, every single feature and function in PHP very clearly states what version of PHP it is available in from the documentation.

Besides, if they don't know, how are they supposed to know that they should be marking their plugin as 5.3+ anyway?

[MikeSchinkel]

Replying to TJNowell:

Performance wise, doing it in Core would be better. Instead of every plugin checking itself, repeating the check over and over again, Core should do it all at once, giving the following benefits:

• Saves plugin developers time

There are many things people request be included in core that get denied yet all of them save developers time, so not a winning justification. Believe me, I've had many requests denied.

• Provides a means of warning users before they go through the hassle of uploading and installing the plugin

Is that really that such a hassle? Not ideal I know, but so bad we have to fix it?

• Can be cached in the database, so no checks may be needed at all if the plugins don't change version

Version checks are very lightweight. If the plugin is disabled when it's found to be on PHP 5.2.x then the check is not done over and over. Or the plugin can cache in the database too.

To force every plugin to do this check and have an unnecessary level of indirection is to encourage bad design, and demonstrates poor architecture that's fixable.

There any many other things plugins are forced to do on their own, many of which I'd like to see implemented, so line forms in the rear if "bad design" is the justification. :)

There's all this talk about plugins in wordpress.org should be 5.2 compatible just as WordPress is, but:

• Nobody actually justified this

Maybe you missed it or misread but ​62.3% of the current user base in on 5.2.x. There's the justification.

• Not all WordPress installs run the latest version, and thus not all installs have the 5.2 min req yet ( though this is a problem in its own right )

Currently 2.3% are on < 5.2.x so while a problem it's a small problem and IMO many of those sites have likely not been touched in years thus not likely to run into a problem with plugins.

• Everyone talks about WordPress being more than just a blog, if that's the case we should ask responsibly and professionally and expand our scope beyond the limited usecase of a new user loading plugins off of wordpress.org. A lot of client work goes on, and we can't anticipate all the end cases, so lets take care of the basics and at least fail gracefully rather than showing a white screen of death in various cases

If you are doing client work aren't you operating a higher level? Can't you validate this on your own? Don't you build sites on a test domain before deploying to a live server? Don't you make sure that your clients are running on PHP 5.3 or later? For professional work, I think this is a non-issue.

NOTE: I have absolutely zero authority over what gets included in core so I'm just voicing my opinion, same as you are voicing yours. One thing that might help would be for you to explain why this has caused such an issue for you? Clearly you are passionate about it, maybe there is some explicit real world problem it as caused for you (vs. an abstract problem) that if we understood we could better appreciate?

P.S. If your request was to instead have WordPress.org scan the files for PHP 5.3 features and automatically mark them as PHP 5.3 required I would think it a better idea. By adding a Minimum PHP required tag you would be creating a trinary state: know good, known bad and unknown. If you can't make it known good vs. known bad I think this proposal has less value.

P.P.S. This is likely my last comment on this because I don't actually feel that strongly about it, it just seemed that nobody else was mentioning the perspective I was seeing.

[F J Kaiser]

Replying to bpetty:

This doesn't have to be in core to be efficient and optimized, you can cache this in your plugin too. In fact, there's really nothing that needs to be cached, just check the PHP version like you would anywhere else you needed a fallback because a new PHP function wasn't available to you.

Well, then please elaborate how you'd efficiently do that check. Especially compared to the efficiency reading the header comment.

Or even better: Tell me (or show with code) how you'd do the check for the following plugin.

/**
 * Plugin: Foo
 * Description: Bar
 */
namespace foo;

// Some functionality

[rmccue]

Replying to F J Kaiser:

Or even better: Tell me (or show with code) how you'd do the check for the following plugin.

a.php:

/*
Plugin Name: Foo
*/

if (version_compare(PHP_VERSION, '5.3', '>')) {
    include 'b.php';
}
else {
    add_action('admin_notices', create_function('', 'Foo requires PHP 5.3 or newer.'));
}

b.php:

namespace foo;

// Some functionality

It's only six lines extra to check the PHP version in your code, plus you can do other things in there. For example, although it's horrible performance-wise, you could dynamically rewrite your classes to use non-namespaced names. (I actually have a proof-of-concept of this lying around somewhere.)

I don't think this is something core needs to worry about, given how easy it is to do it yourself. Recommending close.

[F J Kaiser]

Replying to rmccue:

(...) although it's horrible performance-wise, you could dynamically rewrite your classes to use non-namespaced names. (I actually have a proof-of-concept of this lying around somewhere.)

I asked: "(...) please elaborate how you'd efficiently do that (...)", so this really isn't the answer. But nvm, it as well isn't where I wanted to get with my involvement in this discussion.

WordPress already pushes devs to use a lot of not-state-of-the-art code design patterns. This one (extremely minor) extension of the code base could bring us all (starting from users, to devs and even hosters) a big step towards a modern and competing environment and would allow us to pull a lot of code seamlessly into WP with just adding a header comment and calling it a plugin. This could so much open the door for more modern PHP versions - even on shared hosts. Let's see it positive, add this and try to prepare the environment for a switch to PHP 5.3+. One day we will need it. Let people better be prepared.

And please don't be so trigger happy with adding the close workflow keyword.

[markoheijnen]

Adding this to WordPress doesn't bring us somewhere. Users will find other plugins to solve the same issue they have, developers will make plugins users can't use and hosters don't have a clue it exists and hava a multi year upgrade plan.

I also don't see anything why rmccue is happy to close it. He recommend it and that is fine.

I'm closing this ticket for multiple reasons:

• more then 60% is running PHP 5.2 and if you want to build something useful try to let it work on PHP 5.2. So in general try to let it work. If it's for clients you know the server so these checks aren't needed.
• PHP and MySQL aren't the only thing a plugin needs a version for. Do we also need an extra line for all software that need to be installed? Like GD or Imagick is a must. Curl need to be installed. etc.
• You can easily implement this yourself without performance cost. Maybe even create a central plugin that takes care of it.
• It's nothing to do with preparation since PHP 5.2 code will work perfectly on 5.3. It's not that it breaks.

[nacin]

My take: I think it's clear from the last few comments that parsing namespaces isn't a good selling point for a minimum PHP version header. That said, I'd like to see this conversation continue. Back when we had a minimum of PHP 4.x and many plugins were supporting only 5.x, it was a bit of a bumpy ride, as everyone had to do their own thing. Given that PHP is starting to move to a faster release cycle, it may eventually get to the point where we'll deal with minimum version changes more frequently. I could see us moving to PHP 5.3 as early as 2014. That means we should either do something, or not, depending on how you view this situation. Either way, I think it's worth further exploration and discussion.

Adding the "close" keyword is not trigger happy. It is merely a recommendation. Closing a ticket could be considered trigger happy, but it wasn't in this case — especially when discussion can continue, and when tickets can always be re-opened.

[markoheijnen]

This was probably also a duplicate of #12260

[bpetty]

Replying to nacin:

I could see us moving to PHP 5.3 as early as 2014.

At which point, plugin authors would simply mark their plugin as having a minimum version requirement on that version of WordPress.

Honestly, if you're concerned about "bumpy" transitions, the last thing you want to do is enable or encourage plugin developers to use completely different (and even more restrictive) PHP version requirements than the version of WordPress someone has installed. This can only make the problem worse. Instead, if there's going to be anything managing minimum versioning requirements, it should only be on the version of WordPress installed - and we already have the cautionary fields in place for that (they just aren't strictly enforced).

[nacin]

#12260 was marked as a duplicate.

[SergeyBiryukov]

#25635 was marked as a duplicate.

[afragen]

So it's been 16 months and now stats show that about half of the previous cohort of users are on 5.2 (now 32%)

Is it worth supporting a plugin header such as Requires PHP: 5.3 or as above and hook a function in plugin activation that doesn't allow activation and throws an admin notice if the Requires PHP header doesn't list a version that works and assumes the lowest acceptable version of PHP if the header is missing?

It would seem a much cleaner solution by having this in core than having it in a myriad of individual plugins.

[F J Kaiser]

Replying to nacin:

My take: [...] I could see us moving to PHP 5.3 as early as 2014.

poke

[nacin]

Still not happening, and our 5.2 numbers didn't decline as I'd like. Plan now is to lean on hosts to update accounts to the latest version of WordPress and PHP 5.4+, and see where our numbers are later this year.

[jb510]

It's really not just about namespaces (or magic constants like DIR or anonymous functions or DateTime::diff or ots of things), it's about user experience.

In the last 6 months I've had as many sites white screened on update by plugins from .org using 5.3+ functions. Heck, QueryMonitor was one of those plugins!

All I can add to this at this point is say that I really wish a year ago a PHP Required version check for plugins had been added core. Seems like a _very_ good idea.

[DvanKooten]

I'd love to see this added to core as well.

All my new plugins already require PHP 5.3+ in which I use something like Ryan suggested, checking the PHP version and deactivating the plugin straight away if the requirement is not matched.

I'm currently in the process of upping PHP requirements for my existing plugins. To (try to) prevent crashing sites of users, I push out an earlier update (long before the new version is released) in which I don't show the major version releases of that plugin for sites not meeting the new requirement.

If core did something like this by default, it would really help plugin authors move forward and use more modern development practices..

[TJNowell]

Keeping in mind that soon 5.4 will reach end of life, 5.3 is no longer supported, and no longer receiving security updates, and you're running a 5.2.x system

[dd32]

It's worth noting that although these older PHP's are EOL'd by PHP, some linux distributions will continue to support security updates for them for years to come (LTS releases).

For now I'd encourage plugins who want to increase their minimum requirements to simply follow the deactivate-on-activation route.

[alexander.rohmann]

I think this is something that needs to be addressed by bumping the requirements of WordPress itself.

@nacin

Plan now is to lean on hosts to update accounts to the latest version of WordPress and PHP 5.4+, and see where our numbers are later this year.

Maybe it's time to lean more aggressively and openly? It feels like by the time anything happens, PHP 5.4 will be EOL (considering 5.3 is EOL next month)

@dd32

It's worth noting that although these older PHP's are EOL'd by PHP, some linux distributions will continue to support security updates for them for years to come (LTS releases).

That doesn't make LTS the responsibility of WordPress. They can simply stop updating WordPress, and provide their own layer of security just like they do with PHP.

I'm sure this has been discussed enough, but I (and many others) have been waiting patiently for quite some time, and I'd like to rock the boat a bit here.

At some point, WordPress itself carries more weight than the majority of webhosts.

There are obviously graceful paths to the future. For example:

1. Pick a major version of WordPress that will refuse to update to another major release unless a PHP version is met.
2. Communicate to major web hosts that this will take place in 12 months (or whatever arbitrary timeframe).
3. Continue to offer minor updates to that last branch for an additional timeframe.

This allows them two periods of time to update - more than generous. No general-purpose hosting company will be able to offer a service that doesn't support WordPress, so I predict they will comply. They are running out of excuses to update by the day as it is.

At some point, development must be allowed to evolve. Windows just went through a similar process by completely dropping XP. Maybe it was a bumpy ride for some big players, but shame on them for dragging their feet. In the end the web development community could not be more grateful (no more IE6-8.) It is in the interest of Open Source projects to appeal to developers.

[jb510]

Replying to nacin:

Still not happening, and our 5.2 numbers didn't decline as I'd like. Plan now is to lean on hosts to update accounts to the latest version of WordPress and PHP 5.4+, and see where our numbers are later this year.

I'm confused. This ticket is about instituting a PHP Version check for plugins right? Not moving core to require a specific version. What does it matter what the 5.2 usage numbers are?

As @nacin pointed out, this was bumpy spot when going from from 4.x to 5.x. It's likely going to be just as bumpy going from 5.4 to 5.6 soon and from 5.6 to 7.0 in a year or two.

Why don't we put a version check in core NOW and avoid all that headache two years down the road? What is so fundamentally wrong about adding a minimum PHP version to a plugin header?

[alexander.rohmann]

@jb510
Would not bumping the minimum version for core be the more straightforward way to address this? Personally, I don't care for an official way in core to provide a minimum version. In a way that promotes fracturing the plugin ecosystem. It's just dipping your toe in the water. It would seem developers are already solving this in the plugin code itself. My point is that for development to evolve, WordPress itself needs to natively support modern PHP.

[jb510]

Replying to alexander.rohmann:

Would not bumping the minimum version for core be the more straightforward way to address this? Personally, I don't care for an official way in core to provide a minimum version. In a way that promotes fracturing the plugin ecosystem. It's just dipping your toe in the water. It would seem developers are already solving this in the plugin code itself. My point is that for development to evolve, WordPress itself needs to natively support modern PHP.

I don't think so. There are other tickets about bumping core's PHP version and while that will eventually happen that doesn't address the specifics of this ticket.

Bumping core today would solve the immediate problem but it doesn't address that has been and continues to be an on-going problem where core allows users to blindly activate a plugin that might not be compatible with their current hosting environment.

Don't think about PHP 5.4, think about 7.0. What happens when plugins start requiring PHP 7.0? WordPress is going to run fine on 7.0 (it already does actually) long before core _requires_ 7.0.

You're right, some developers are solving this by checking the PHP version in their plugin before running, but some of us think that's redundant and this would be better handled by core. There ought to be a standard way to handle it across all plugins. Where core reads the comment block and says "hey, sorry I can't activate plugin X because it says it requires PHP 7.0 and this server is running PHP 5.6".

In fact the recent PHP constructor change bring up that there should probably also be a maximum version specified in some cases.

[pento]

Adding this to Core doesn't solve the underlying problem of how to get users to upgrade, all it does is tell them they can't do something because reasons.

We have the browser version check, because we can at least give people instructions that will work (except for some corporate environments) to upgrade their browser. The equivalent instructions for upgrading PHP aren't so simple.

"If your host uses cPanel, login to your cPanel (using your cPanel username, not your WordPress username. No, it's probably different to your domain management username, too). Click on PHP Versions, and select PHP 5.6. If that's not available, select PHP 5.5. If that's not available, contact your host..."

You get the idea.

We're working with hosts to identify sites running old versions of PHP, and to upgrade their PHP versions automatically, but it's naturally a slow process. The hold up isn't WordPress, it's random scripts that people run that haven't been updated since PHP 4. Sites break, and the hosts then have to fix it.

In the mean time, I have no problem with plugins using tools like ​WPupdatePHP, but I don't think such a check is appropriate for Core.

[knutsp]

If minimum PHP version for a plugin was to be implemented in core, then there should also be a maximum. I remember plugins using "call-time pass-by-reference" leading to a lot of problems when PHP was upgraded. And then we have MySQL versions and browser versions. Plugins may even only work in combination with a specific theme (framework) version(s), and so on. This is all to complicated for core to implement, or partly implement, leaving a lot of other cases unsolved.

Plugins that result in fatal error are not activated, due to sandboxing it. That is what core should do, and does.

Plugins should provide their own, more or less graceful fallback when their ideal environment is not fully present, and may be give users a message about what doesn't work. We do that falback with CSS when dealing with old IE browsers, for example.

If core was to implement this suggestion then it would also be a signal that WordPress encourages plugin developers to set their own PHP minimum and at the same time take a kind of responsibility for it. This would be double standards, since Core itself has a (lower) requirement and since wordpress.org/plugins is a repository, presumably, for all users.

This is what I think is the reason behind "inappropriate for Core" (@pento).

And this not being implemented just increases the pressure to get Core to require PHP 5.3 soon. I really think WordPress is strong enough to shake up the hosting providers by declaring it's intention and give a date for it, now.

[alexander.rohmann]

My apologies for the wrong ticket. I looked for one but could only find this. A maximum version is a good idea. That's standard in many places, like PECL extensions.

Fully agree with @knutsp. If plugin develops are encouraged to deviate from the "WordPress requirements" you end up with a mess of mismatched versions. This dilution results in more things for the end-user to think about. Over time it degrades the stability/reliability of WordPress as a whole because you have no idea what to expect when activating a plugin.

I agree 100% that hosting compatibility is a concern, and in fact it is my primary concern. The major setback here is lethargic outdated hosts - who are never going to change until WordPress necessitates it.

So what if hosts are reluctant to update because of their own slew of legacy application cliental? I've seen this point made a few times, and I can't fathom why that is something we should be solving. I fail to see how that falls on WordPress as a responsibility.

Considering the influence of WordPress, I certainly understand being gracious - but at this point we're coddling them. Owners of non-WP legacy PHP sites will at some point (soon) need to realize their mistake and pay up to get a new system. Why should WordPress be hostage to other people's failure?

[markoheijnen]

On topic, to me this still should not happen. Plugins should follow the requirements of WordPress. So I agree with knutsp on the double standard point.

To my knowledge WordPress isn't working with hosts that much at all. Maybe a bit but far from enough to increase the PHP version without talking with them on a plan. Also the influence WordPress thinks it has isn't that big if it comes to forcing PHP version. If you look closely it isn't about updating PHP since most hosts already did that. It's all about killing PHP 4.4, 5.2, 5.3 and soon also 5.4.

The only way to play nice, we should work with the PHP community, other open source projects and host to set a date where we want to kill PHP versions older then 5.4 for example. This would be a date that is more then 9-12 months from now since it will take some time. As pento mentions, it are the random scripts and projects that break due to things like deprecated/removed functions. I have been part of such migration(5.2 to 5.5) and it does cost time and preparation. Mostly because support doesn't have to have the knowledge to help out.

[jdgrimes]

Just running some numbers based on the WordPress stats:

If the number of users on PHP 5.2 continues to drop at its current rate of ~0.14% per week, it will be about 94 weeks or almost 2 years before it goes to essentially 0. PHP 5.3 usage is dropping at ~0.25% per week, meaning it will approach 0 in about 2.5 years. Usage of 5.4 is still on the rise.

In 1 year, 5.2 usage will probably be ~6% and 5.3 usage ~20%. So it is probable that over one quarter of active sites will be not updated at that time. A push from WordPress might be able to improve that number. But remember that by the time we get there, both 5.4 and 5.5 will be dead. And right now a lot of people are moving to 5.4 and 5.5.

I'm not sure what point I'm trying to make here, but I guess we're in for a long battle against outdated PHP. It is really an issue that is much bigger than WordPress, and yes, it's going to take the whole PHP community to find a long-term solution.

I don't think that we should make it any easier for plugins to require a different PHP version than WordPress. And I do think that we should try to up WordPress's version ASAP. The question is, how soon is possible? I have long thought that WordPress should just pick a date. How about, "on 28 Aug 2017, we will stop supporting unsupported versions of PHP" (Yay PHP 7!). It is a generous 2 years distant and actually fixes the problem for good because we never have to decide when to drop a PHP version ever again.

[alexander.rohmann]

2 years is reasonable.

How much time has been wasted allowing PHP EOL to be open to interpretation?

It doesn't matter who you are (host, open source project, etc.), if you are using PHP you should be able to respect their release cycles. PHP has people working hard to provide LTS, and plan how things evolve. The "PHP community" at large seems to have no respect for that. What right do we have to disregard this, and be heavily dependent on PHP?

When all this goes down here's the stance I'd like to see WordPress take:

WordPress will only run on PHP versions found here: ​http://php.net/supported-versions.php

That's how it should be, and that would solve all these problems going forward.

[TJNowell]

There're Trac issues about the minimum version of PHP for WordPress already, that's not what this Trac issue about, and while I agree with the sentiments, that's not what this Trac issue is about, and it's irrelevant.

Even if we have PHP 5.6 as EOL at the end of the year, and 5.7 5.8 and 5.9 exist, what if my code requires 5.8 as a minimum for whatever reason? That's the purpose of this ticket

[TJNowell]

As for solving these problems, if I write a plugin that requires PHP 7 language features because it depends on a library, but 5.6 is still good, a minimum PHP of 5.6 for WordPress doesn't make the problem go away

[alexander.rohmann]

Sorry for hijacking your ticket. If you know where this would be on-topic let me know. I couldn't find it in trac anywhere. On-topic, I'd still disagree that core should encourage plugins to use anything that core can't utilize immediately as touched on above (51/52)

A car dealership's service center wouldn't facilitate or recommend aftermarket alterations. They're totally possible, but that's on you. Thinking about the big picture, what would happen if all developers suddenly had preference of what to support or not support? Users could get anxious at just the thought of activating a plugin to see if it works or not.

[TJNowell]

If it doesn't exist, create a new ticket ^_

[alexander.rohmann]

Fair enough. #33381

[maratbn]

Too bad that this ticket was closed.

So far I released 2 plugins that require PHP >= 5.4 due to the use of short echo tags and namespaces.

Most of the problems reported by users are from trying to run the plugins on various PHPs < 5.3, which do not have namespace support. I already have in-plugin logic to test for PHP < 5.4, but that only works on PHP 5.3, because anything less will error-out on the namespace syntax, which also has to be the first line.

Work-arounds for that would add a slight performance penalty for each HTTP request to the site, which is just not worth it for the vast majority of users running some more recent PHP. But if WordPress already did this the same way it already checks for compatible WordPress versions when installing themes/plugins there would be no additional performance penalty.

[swissspidy]

#35469 was marked as a duplicate.

[seancjones]

I'd really like to revive this ticket. (I apologize if just reopening it is considered poor form. I know it's probably better than launching a new ticket).

I am NOT trying to discuss #33381 here. That is a PHP upgrade for core. This is an optional tag that can be used to help filter plugins and, as I hope to successfully argue, improve user experience AND developer experience, in an age where new installs have to jump through insane hoops to install PHP 5.2.9.

I'd like to see this implemented for the following key reasons:

• The vast majority of users are now on versions later than PHP 5.2.9
• A good chunk of plugins are writing code that is not compatible with PHP 5.2.9.
• As we continue to diverge, plugin developers will increasingly forget what is PHP 5.2.9 compatible. For example, anonymous functions are incredibly convenient.
• It is fair to highlight the experience of the user over the developer. Neglecting this makes the user's experience worse at the expense of the developer. This is a lose-lose proposition.
• There is some precedent, as stale plugins that have not received updates for a long time are not searchable on the wordpress plugin page. Why should a plugin with a PHP version that is too high be easy to download?
• It does not require an upgrade to PHP's core version.
• It helps to shift the user's blame from developers to hosts. If a user complains that they can't download a plugin, and they received a notice that it was because their PHP version is too low, developers don't get bothered, users don't get confused, and hosts get rightfully pestered by the people who are paying them, upping the ante for an upgrade.

This helps to bridge the gap between #33381 which may not happen for a long time, and what we have now. It does not force anything on core features, but it does provide a mechanism to lean on hosts by giving them a very present economic reason to do it. If a host isn't offering good service, ditch them and go elsewhere!

How?

My idea is to have this work similar to hiding plugins that have not seen updates for a long time, these plugins could instead have a disabled submit button, with a note that the plugin is incompatible with your WordPress install, and a link to a help page on WordPress.org, for how to address the problem.

[danieliser]

Replying to seancjones:

Oh please lets do this. even with proper checks in plugins, users still submit ticket after ticket saying it doesn't work for them. This would entirely alleviate huge amounts of wasted support time as well as ensuring that over time hosts will opt to update PHP versions sooner than later.

[joostdevalk]

Been discussing this again with some people, including @matt, and decided to open a new ticket with mockups and a list of what to do to actually make this happen: #40934

[pento]

Closing in favour of #40934, which has a clearer direction and not as much history for interested parties to wade through.