[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
----------------------------+---------------------------------

Comment (by blobfolio):

 I might be thinking about this the wrong way, but as I see it, the main
 benefit of allowing plugins to set their own minimum PHP requirements is
 just that: letting the plugins do it.

 Code compatibility analyzers are useful and all, but the technology can't
 be run without human oversight. Ultimately, they're just looking at files
 in a bubble. The only way to ''know'' for sure is to view it in context
 by, e.g., running it.

 The most common problem with code analyzers is that they'll end up
 returning inflated requirements because code flows aren't always apparent
 out of context. For example, the WordPress core will use `hash_equals()`
 when it can (a progressive security enhancement), but that function wasn't
 introduced until PHP5.6. In fact, running `phpcompatinfo` against the
 current WP trunk turns up `7.0.2` as the minimum version for me, which
 ''isn't quite right''. Haha.

 But wait, there's more! PHP releases don't just differ in terms of markup,
 functions, plugins, etc. They also differ in behavior. How can an
 unmonitored code analyzer guess at the author's intent?

 For one, this means considering every system function that has had its
 behavior changed somewhere down the line (in a compatibility-breaking way,
 at least). As a plugin author, I might choose to require PHP5.3 because
 `fnmatch()` started having better Windows support at that time. That
 particular function exists as far back as PHP4, but for my hypothetical
 purposes, didn't do what I wanted until PHP5.3.

 There are also fun issues like PHP7's ability to support scalar hinting in
 function declarations (e.g. `function foo(string $bar){ ... }`). When run
 on PHP7, the value passed as `$bar` will be cast as a `string` (or die
 trying). But when run on versions prior to PHP7, that same code will be
 expecting `$bar` to be ''an object belonging to the custom class
 `\string`''.

 Given all that, I would be hesitant to incorporate automated compatibility
 scanning at all, for any purpose, even as a fallback for plugins that
 don't assert their own details. All that accidental inflation would make
 the plugin repo a lonely place for granddaddy PHPs.

 '''TL;DR'''
 This is an excellent enhancement proposal, but one which I think only
 really applies to developers who are conscious about this sort of thing.
 Any attempt to get this executed without human participation is going to
 have consequences and possibly result in an overall worse UX for many site
 operators.

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