[wp-trac] [WordPress Trac] #33381: Strategize the updating of minimum PHP version.

Sun Mar 5 22:11:56 UTC 2017

#33381: Strategize the updating of minimum PHP version.
-------------------------------------------------+-------------------------
 Reporter:  alexander.rohmann                    |       Owner:  jorbin
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
Component:  General                              |  Review
 Severity:  normal                               |     Version:
 Keywords:  needs-codex dev-feedback 2nd-        |  Resolution:
  opinion                                        |     Focuses:
-------------------------------------------------+-------------------------

Comment (by jdgrimes):

 I think it might be useful if I explain why I, as a responsible plugin
 developer, felt compelled to prepare to possibly update the PHP
 requirements of my plugin. While of course there are some nice "candy"
 features that newer PHP versions have (and some that are more
 substantial), that actually hasn't really informed my decision. Nor has it
 been just an aversion to encouraging the use of outdated PHP. It is much
 more practical considerations, specifically relating to user experience,
 that have lead me here. I am sure that to some degree these same things
 inform other developers' decisions about this, so I think it is worth
 explaining in depth.

 In a word, it is the maintenance burden, but I realize that doesn't tell
 the whole story. After all, it is often pointed out that WordPress has
 been able to remain compatible with older PHP versions without too much of
 an undue burden. But the burden is significantly greater for plugin
 developers, and so let me explain why, and why I believe that WordPress
 needs to take this into account.

 To ensure continued compatibility with each supported PHP version,
 WordPress runs its test against each on Travis CI. I do the same thing
 with my plugin, but there is an added catch: I also need to ensure
 compatibility with each version of WordPress that my plugin supports.
 WordPress only needs to run against 7 different build environments (PHP
 5.2-7.1), with PHP nightly also added to keep an eye on compatibility with
 the next version of PHP. But my plugin needs to run against each of those
 versions of PHP ''in combination with'' each supported version of
 WordPress. Even when I limit support to the last two versions of
 WordPress, that comes out to 21 different build environments: 7 PHP
 versions x 3 WordPress versions (4.6, 4.7, and trunk).

 This isn't unbearable, and if that was the extent of the issues, then I
 would happily continue to support as many PHP versions as WordPress does.
 But that isn't where it ends. Because in addition we have to consider
 plugins that integrate with other plugins. When we throw this into the
 mix, even when only the latest version of the other plugin is supported,
 the number of builds is multiplied by 2: 21 x (stable + development
 versions of the other plugin) = 42.

 Even that isn't too unbearable, but here is where the real kicker comes
 in. My model is developing extensions for my plugin that integrate it with
 other plugins. So now we are talking about testing the extension against
 each version of the plugin that it supports, each version of the other
 plugin that it supports, on each version of WordPress that it supports, on
 each version of PHP that it supports. Once again, even if we limit the
 extension to only supporting the latest version of the plugin that we
 extend, our builds multiple by 2: 7 PHP x 3 WordPress x 2 other plugin x
 (stable + development of extended plugin) = 84. That is approaching the
 unreasonable and the unmaintainable, and adding one more PHP version to
 the mix adds 12 more build environments to test against.

 Ignoring for a moment the ability of Travis to handle this number (which
 it can, but it starts to feel like abuse to me at a certain point), the
 fact is that maintaining compatibility also requires actual fixing issues
 brought up by build failures that relate to specific combinations. At a
 certain point it just becomes too much of a burden for a plugin developer
 to try to handle.

 Which is the reason that I decided I had to prepare to start dropping PHP
 versions if WordPress itself doesn't soon (which would seem almost
 miraculous).

 Not every plugin developer is in this exact situation of course, but the
 general fact of maintenance burden, as well as other reasons that are
 often brought up, mean that more and more plugin developers feel compelled
 to diverge from the PHP requirements of WordPress.

 '''As a result, more and more users are going to have to encounter the PHP
 version issue anyway, regardless of what core does.''' But unless we take
 the initiative, it is not going to be a positive, educational experience
 that we have carefully tailored for them to make the whole thing as smooth
 as possible. Instead it is going to be a hodgepodge of different
 experiences involving different plugins. Some of those experiences may be
 pretty good (though if I do say, I think we can do better if we try), and
 some of them... won't be. Like:

 - The plugin developer doesn't respond to the users' support request.
 - The plugin developer hasn't communicated this very well to start with,
 so most users are just confused, and FUD sets in.
 - The plugin developer decides to up the requirement for an existing
 plugin, and when users update it breaks their site.
 - Or, even if it doesn't break their site, the plugin just stops working.
 (Instead the update should be prevented, as BuddyPress did, and
 [https://github.com/WordPoints/wordpoints/issues/623 I've done in my
 plugin]. As a side note I hope that helps set the record straight about
 whether I care about the users. :-)

 At the very least, even if the approach recommended by @dd32 is followed
 and we continue to promote the plugins-first approach here, we should try
 to unify the experience of users so that this experience gives them as
 little frustration as possible. The only way to really do that in an ideal
 fashion though, IMO, is if core actually steps out and takes the lead
 here, so that plugin developers don't have to. But maybe there is room for
 discussion there.

 The main point is, that '''users are going to encounter the PHP version
 issue through WordPress, and it is up to core/the core community to ensure
 that encounter is positive and educational'''.

 ----

 One other thought that I just had (and yes I know, I talk too much
 sometimes :-):

 There is going to come a day when WordPress is going to have no choice but
 to drop older versions, if it wants to continue supporting the latest
 versions. It may be far into the future, but at some point PHP 8 is going
 to come out, for example, and code compatible with PHP 8 is not going to
 be compatible with PHP 5. (I don't recall the specific example that
 brought this to mind, but it has to do with things deprecated in PHP 7,
 IIRC, possibly other issues too.) So, if for no other reason, WordPress is
 going to have to come up with a strategy here that will bring up the
 minimum version to 7.0 by the time PHP 8 comes out. (Could be decades,
 could not be, I don't really know if there is any way to know at this
 point.) Currently, most people who are updating appear to be updating to
 PHP 5.6, so it is possible in theory that this will be an issue. Let's go
 ahead and begin testing out strategies now, before it ever gets to the
 place where it becomes a necessity. (Possibly even something presently
 unforeseen could cause it to become a necessity, so it is best to be
 prepared.) Hopefully though, by that time hosts will have their act
 together on this. But yeah, I'm not going to hold my breath.

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