[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:  joostdevalk
     Type:  task (blessed)  |      Status:  assigned
 Priority:  normal          |   Milestone:  4.9
Component:  Plugins         |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  dev-feedback    |     Focuses:  ui, administration
----------------------------+---------------------------------
Changes (by pento):

 * owner:   => joostdevalk
 * status:  new => assigned
 * focuses:   => ui, administration
 * component:  Administration => Plugins
 * type:  enhancement => task (blessed)


Comment:

 Several years ago, I was strongly against this kind of change, but I've
 more recently been convinced of its merits.

 As far as the technical aspects go, I don't think there's much
 disagreement - it's relatively simple to implement (4.9 should be an easy
 target).

 The far harder problems here, as @johnbillion mentioned, are the people
 problems. How do we explain to site owners what's going on, and what they
 need to do to fix it? Historically, we've written these problems off as
 being too hard - we didn't have the resources to document how to fix it,
 and previous attempts (see: the abysmal failure of GoPHP5's effort to make
 a dent in PHP4 usage) were unsuccessful.

 Over the past several years, there have three changes in the WordPress
 world that changed my mind on this.

 - '''Reframing the discussion.''' This has always been discussed as "how
 to get Core using a newer PHP", plugins have always taken a back seat.
 Focussing on plugins allows us to think of it as less of a "breaking back
 compat" issue, and more of a "graceful degradation" issue - if a feature
 (in this case, a plugin) doesn't work in your version of PHP, you simply
 don't get to use it, though your site will happily continue running if you
 choose to do nothing.
 - '''The hosting community.''' The relatively newly formed hosting
 community gives us a much stronger link to interested hosts than we've
 previously had. Historically, host discussions have happened through ad-
 hoc pinging of contacts, which is wildly unreliable. With hosting input on
 this, it should be much easier to hook into host-specific upgrade
 information. If we can detect the host (or the host automatically installs
 a plugin to alter the appropriate filters), then we can link directly to
 host documentation, giving the user the most accurate information for
 their scenario. Indeed, it would potentially be possible to perform the
 upgrade from within wp-admin, if the host provided the necessary command
 to run.
 - '''The documentation and translation community.''' Where we don't have
 host-specific information, we will need documentation for everyone else.
 Historically, both the documentation and translation teams have been
 overworked and understaffed, but they've been making great strides over
 the last couple of years. Co-ordinating this kind of documentation effort
 is well within our capabilities at this point.

 As a bonus, we also have a bunch of prior learning that the Yoast team can
 provide, through their experiments with encouraging upgrades.

 As far as benefits go, I don't think anything has changed from earlier
 discussions, but I'll list them as I see them.

 - '''Performance.''' No-one argues that newer PHP versions are much
 faster, particularly from 7.0 onwards. Upgrading PHP gives us a faster
 internet, and a better experience for everyone.
 - '''Security.''' While many hosts backport security fixes to their
 internally maintained PHP versions, there are plenty that don't. A more
 secure web is always a benefit.
 - '''Improved WordPress Developer Experience.''' Getting started with
 developing for WordPress is easy, in part because we really only use
 coding practices from 10 or more years ago. This has been both a strength
 and a weakness for WordPress - it's easy to get started, but it's hard (it
 could even be interpreted as officially discouraged) to advance to modern
 practices, which risks alienating a new generation of developers with no
 interest in maintaining 14+ year old code. This is a balance, but it feels
 like the balance has tipped too far in the wrong direction.
 - '''Setting a direction for Core.''' The things we learn from allowing
 plugins to set a minimum PHP version will inevitably influence how we
 choose to bump Core's minimum PHP version. Bumping Core's PHP version is a
 much bigger problem, but taking this first step will help us get there.

 Ultimately, the current strategy of "wait for PHP usage to naturally
 evolve" is working, albeit very slowly. If this doesn't work, we can fall
 back on how it was before. But, done correctly, I don't believe this
 project can harm WordPress, so the worst case is "nothing changes", and we
 can go back to the drawing board. The best case is that we get a good bump
 in PHP usage, and a way forward for Core's PHP version, too.

 @joostdevalk: I assume you're interested in leading this effort? If that's
 the case, consider it "blessed". :-)

 Also, do you have any data on the effectiveness of the Yoast campaign?
 That would be interesting to see.

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