[wp-trac] [WordPress Trac] #40934: Allow PHP version requirements for plugins & themes

[WordPress Trac]

#40934: Allow PHP version requirements for plugins & themes
----------------------------+------------------
 Reporter:  joostdevalk     |       Owner:
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  4.9
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  dev-feedback    |     Focuses:
----------------------------+------------------

Comment (by jdgrimes):

 Replying to [comment:14 johnbillion]:
 > If we are going to consider exposing the user to a PHP version
 constraint, it's important to qualify it with the benefits that it
 provides. In a world of microservices, packages, and dependency
 management, this is routine stuff, but WordPress doesn't operate in this
 world. I'd like to see a document put together which answers:
 >
 > * What are the ''real'' benefits to plugin and theme authors of a PHP
 version constraint mechanism?
 > * What problems are caused by lack thereof?
 > * What are the benefits, if any, to end users?
 > * What are the benefits, if any, to WordPress core or the wider
 WordPress ecosystem?
 >
 > The answers will all be subjective of course, but they'll help guide us
 with regard to prioritisation and implementation. This may seem like
 overthinking things, but supporting a PHP version constraint for plugins
 and themes introduces a fundamental change to the way WordPress is used.

 I agree.

 Here is an answer to the first two questions from my perspective as a
 plugin developer.

 I know that usually when it comes to talk of PHP versions, the first thing
 that will be said is that "we can really do everything that we need to in
 PHP 5.2." There's truth in this, and as such in real life I find that the
 features offered by newer versions aren't what has pushed me to decide to
 drop support. It is really a question of maintenance burden. In other
 words, the features of new versions aren't very important (to me, at
 least), it is the bugs and other issues that arise from old ones.

 And really, it has little to do with the quirks of any particular version.
 It isn't so much about PHP 5.2 (or 5.3, or any other version) as it is
 about the burden of supporting 7+ different versions of PHP, each of which
 has quirks. Ensuring compatibility of a plugin with each supported
 WordPress version and each supported PHP version adds up.

 And it becomes frustrating that more and more time is spent supporting a
 legacy version of PHP that increasingly few users are actually using. It
 is time that could be put to the benefit of all users by building new
 features, instead of going down the drain just for 3%.

 This is what has compelled me to consider requiring a different minimum
 version than WordPress, something that I would really like to avoid. It is
 just in the best interest of users and developers alike.

 (I'm certainly not alone in this, many other plugin developers, especially
 those who take testing compatibility seriously are feeling much the same
 way.)

 Of course, I am welcome to do this without any action on core's part
 though. So what are the problems that handling this in core would solve?

 First, from the user perspective, it would give the user a much more
 consistent experience. More and more plugins are going to begin doing
 this, and not all of them are going to put the same amount of effort into
 making it a positive (if possible) experience for users. This effort will
 also be duplicative, wasting yet more time that could be put to much
 better use. So for the optimal user experience, the community coming
 together around this issue as a whole is best.

 From a developer side of that, the problems that are caused by a lack of
 core support for this is that it is more difficult for a developer to
 communicate this constraint to the user effectively. It is also means more
 work to prevent them from installing the plugin when it won't work, and
 especially to prevent them from updating to the version that is dropping
 support for their version of PHP (which if they did, it would mean the
 plugin would suddenly cease to function; not a good UX).

 And does this have benefits for the wider WordPress ecosystem as a whole?
 I think it does. Most of us have probably spent time (you and I in the
 last week, I think) struggling with issues tied to various PHP versions,
 particularly 5.2. The more versions we support, the more time is spent on
 this. It is significant enough that as a community we are able to do less
 actually useful stuff because of it. We are continually putting more time
 into this, with less and less return (as it is benefiting fewer and fewer
 users). At some point, we all agree that it is no longer worth it. That
 time may come at a different pace for different plugins, and at a
 different pace for many plugins than for core. It depends on how many
 people are on a team, and how many users on certain PHP versions there
 are. It is a decision that people are already making. Plugin devs are
 already confronting users with this, like it or not, and there is nothing
 that we can do about it (unless we make that against the plugin directory
 guidelines). In my opinion, the best UX is going to result from core
 support. Perhaps we're not quite to the place where the benefits outweigh
 the costs, but it is clear that many plugin devs believe, that for them at
 least, we are already far past.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40934#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform