WordPress.org

Make WordPress Core

Opened 13 months ago

Closed 13 months ago

Last modified 6 months ago

#23880 closed feature request (wontfix)

Minimum PHP version in Plugins

Reported by: TJNowell Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Plugins Keywords:
Focuses: Cc:

Description

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/
*/

Change History (38)

comment:2 sergej.mueller13 months ago

Minimum PHP:
Minimum MySQL:

comment:4 lkraav13 months ago

  • Cc leho@… added

TJN knows what he's talking about

comment:5 MZAWeb13 months ago

  • Cc wordpress@… added

comment:6 follow-up: interconnectit13 months ago

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.

comment:7 in reply to: ↑ 6 ; follow-up: TJNowell13 months ago

  • Cc tom@… added

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

comment:8 in reply to: ↑ 7 codearachnid13 months ago

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.

comment:9 F J Kaiser13 months ago

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.

comment:10 follow-up: markoheijnen13 months ago

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.

comment:11 in reply to: ↑ 10 ; follow-up: TJNowell13 months ago

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?

comment:12 in reply to: ↑ 11 ; follow-up: markoheijnen13 months ago

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.

comment:13 in reply to: ↑ 12 ; follow-up: TJNowell13 months ago

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

comment:14 in reply to: ↑ 13 MikeSchinkel13 months ago

  • Cc mike@… added

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.

comment:15 sabreuse13 months ago

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.

comment:16 follow-up: markoheijnen13 months ago

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.

comment:17 in reply to: ↑ 16 MikeSchinkel13 months ago

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.

comment:18 dh-shredder13 months ago

  • Cc mike.schroder@… added

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?"

Last edited 13 months ago by dh-shredder (previous) (diff)

comment:19 follow-up: TJNowell13 months ago

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.

comment:20 in reply to: ↑ 19 ; follow-up: MikeSchinkel13 months ago

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?

comment:21 markoheijnen13 months ago

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.

comment:22 in reply to: ↑ 20 F J Kaiser13 months ago

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.

comment:23 follow-up: bpetty13 months ago

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.

comment:24 in reply to: ↑ 23 F J Kaiser13 months ago

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.

Version 0, edited 13 months ago by F J Kaiser (next)

comment:25 TJNowell13 months ago

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

comment:26 alex-ye13 months ago

  • Cc nashwan.doaqan@… added

comment:27 follow-up: bpetty13 months ago

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?

comment:28 MikeSchinkel13 months ago

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.

comment:29 in reply to: ↑ 27 ; follow-up: F J Kaiser13 months ago

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

comment:30 in reply to: ↑ 29 ; follow-up: rmccue13 months ago

  • Keywords close added

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.

comment:31 in reply to: ↑ 30 F J Kaiser13 months ago

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.

comment:32 markoheijnen13 months ago

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

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.

comment:33 SergeyBiryukov13 months ago

  • Resolution changed from worksforme to wontfix

comment:34 follow-up: nacin13 months ago

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.

comment:35 markoheijnen13 months ago

This was probably also a duplicate of #12260

comment:36 in reply to: ↑ 34 bpetty13 months ago

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).

comment:37 nacin11 months ago

#12260 was marked as a duplicate.

comment:38 SergeyBiryukov6 months ago

#25635 was marked as a duplicate.

Note: See TracTickets for help on using tickets.