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

WordPress Trac noreply at wordpress.org
Sat Apr 16 15:11:38 UTC 2016


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

Comment (by seancjones):

 I would like to bring up a few things that are distilled from my dupe at
 #36542.

 My belief is that it is important that WordPress core and the plugins that
 surround it are eventually able to start de-cluttering the global scope,
 using a feature that has been in PHP for over 5 years - namespaces.
 Currently, WordPress uses the old-style namespaces which are just
 convention-based. These have obvious drawbacks. The features that come in
 later versions of PHP are nice, and certainly PHP 7 comes with some major
 performance updates, but PHP 5.3 is an extremely modest update which the
 vast majority of people who care who are running 5.2 should be able to
 upgrade to with limited issue.

 While many WordPress users may not know what PHP is, their hosts certainly
 do.

 I support a cohesive updating strategy. I am not proposing an upgrade from
 5.2.9 to 5.3 as a one-off. I am proposing it as part of a larger strategy.
 Yes, part of it is that we would be able to enjoy PHP as a truly object
 oriented language. However, another part of it is that it would be a good
 test-case as we try to determine our rollout strategy. I don't think 5.2.9
 -> 5.3 is a very contentious upgrade by itself, but once you get to
 suggesting that we only support PHP 5.5 and later, that would immediately
 shut down this argument, leaving us with 5.2.9 for another year or more.

 I would also point out that my ticket proposes an rollout strategy that
 calls for an updated minimum language with a delay in using any of those
 new features in core. That should have three clear benefits:

 1. You can backport security updates very easily for users who are
 currently running 5.2.9 for a while. I suggested 6 months to a year but
 maybe more realistically it should be a year or two.

 2. You can steadily raise the minimum supported PHP version so that people
 who are wondering why they cannot get the new releases reach out to
 WordPress support or their host and apply pressure in getting an updated
 version of PHP.

 3. Plugin and theme authors should be able to utilize newer versions of
 PHP simply by attaching to a newer version of WordPress. This would
 prevent a user running an old version of PHP from installing it/updating
 their version, but that would only reinforce the importance of getting
 their system upgraded.

 Ultimately, upgrades will leave a very small percentage of users
 vulnerable, but if someone is running PHP 5.2.9 at this stage, having a
 secure WordPress is barely going to make a difference. It's like putting
 duct tape on the bottom of a boat with a leak: Sure, it'll slow the
 inevitable, but it's not a permanent solution. IMHO, with an manageable
 group it's time we cautiously begin to address it.

 Replying to [comment:73 jorbin]:
 > Replying to [comment:72 jdgrimes]:\
 > > This is true, however, as long as we continue to push out security
 updates for older versions of WordPress (back to 3.7), this is really not
 much of an issue. Just because they can't update WordPress doesn't mean
 that they won't receive automatic security updates. (Unless they are
 running a version before 3.7, in which case they are already insecure.)
 >
 > That's a good point, but it also is part of the problem with updating
 the version at all. It makes backporting security fixes that much harder.

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


More information about the wp-trac mailing list