[wp-trac] [WordPress Trac] #40934: Allow PHP version requirements for plugins & themes
WordPress Trac
noreply at wordpress.org
Wed Jun 7 02:52:18 UTC 2017
#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
More information about the wp-trac
mailing list