[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