Minimum PHP version should be 7.x

[discobot]

---

Read-only archive: https://petitions.classicpress.net/posts/6/minimum-php-version-should-be-7-x

Author: stefanos82

Vote count: 113

Status: planned

PHP 7.x (exact version TBD depending on usage, community, and our resources) for v2.0.0.

~ posted by Wade Striebel

Tags:

• request-modify-feature

---

Comments

I respect the idea here, but I don’t think we can reasonably pull it off in a short time frame. See: https://wordpress.org/about/stats/

28.1% of WordPress installs are using PHP 5.5 or earlier.

38.5% of WordPress installs are using PHP 5.6.

By making this decision, we would be excluding two thirds of all active users.

I think the best we can reasonably do is to drop PHP 5.2 and possibly 5.3-5.5 support for the initial release, and come up with a clear strategy to upgrade beyond that in later releases.

~ posted by James Nylen

I understand what you mean. By the way, I trust more these results https://w3techs.com/technologies/details/pl-php/5/all

If people want to reduce the minimum requirement to 5.6, that would be fine with me.

I believe though that if we give no other option to people, they will move to 7.0 and we will solve many problems ahead of time.

~ posted by stefanos82

According to that source, 66.6% / 83.5% = 79.8% of PHP users are on 5.x.

I’d prefer that we make this decision slowly and carefully, with a small bump in the initial version. Then maybe we can collect usage data and increase the PHP requirement with each version.

~ posted by James Nylen

I’d like to see a warning in the repo for any plugin that doesn’t have PHP 7.0 support yet. Hope that lights a fire under any devs who are dragging their feet on getting this done. It’s both a security and performance issue to stay at 5.x at this point, even 5.6.

~ posted by BlogAid

Absolutely. Start with a clean slate and don’t take on the technical debt of GutenPress. However, some way is needed to provide an alternative solution for those who are not ready. Maybe we could fork ClassicPress and do a ClassicPHP version??? Or, maybe a ClassicPress 4.9.8 LTS

~ posted by Terence

I actually just transferred a client’s site where it broke with PHP 7.0. But its an old site that really needs updating. But that’s the client’s decision not mine to make.

For security purposes 5.6 should be the minimum - but if you make 7.0 the minimum, you are excluding the majority of users who would probably gravitate to ClassicPress.

Honestly I like the idea of PHP 7 as a standard - but its too early to consider it. I vote for 5.6. Anything below that is a security risk.

~ posted by Avrom

Only half kidding [above].

This backward compatibility idea has its merits and is largely its commendable, but everything and everyone, at some point in time, has to move forward, or they hold everyone else back.

What would perhaps be more useful, right now, than a discussion about whether we draw a line with PHP 7.0, is a discussion about the principles behind coming to [technical debt, type] decisions like this, what motivates the arguments, and how the decision, when eventually arrived at, should be made.

That discussion should also include ideas on what thought is given to–what is actually done for, and the opportunities left to–those the decision leaves behind.

Otherwise it just becomes a free-for-all question of who shouts the loudest, or who has the most compelling use-case, or perhaps who has the cabal’s ear, which I thought was the primary reason we are all here in the first place.

A bit like democracy. Mob rule by another name.

~ posted by Terence

I don’t think merely incremental bumping of the minimum required version of PHP is the way to go here, nor do I think we should be influenced by statistics of PHP usage. Many sites running old versions of PHP probably haven’t been updated in years, and aren’t likely to be. So waiting for users to move to a later version would be like waiting for Godot.

It’s also unlikely that ClassicPress would have enough clout in the short term to influence users to move to a later version of PHP unless they have already made a conscious decision to use ClassicPress. If the latter is true, they will be reading our materials that explain what choices and decisions we have made, so they will know the minimum PHP version required. So, again, I don’t see any reason for merely incremental bumping of the required PHP version.

I see a very strong reason for setting the bar at either 5.6 or 7. It makes a clear statement of where our priorities lie. Strong security is paramount.

I don’t feel strongly about whether the minimum version of PHP should be 5.6 or 7, provided that we understand that, if we choose 5.6, we will have to revisit it sooner rather than later as 5.6 ceases to have full security support at the end of 2018.

So the choice seems to me to depend more on practicalities. Would it be easier to migrate to 5.6 first, and then move to 7 later? Or would it be easier to go straight to 7?

~ posted by KTS915

@Terence Let’s keep the thread on track please. People are offering good insights here on PHP requirements and I don’t see anyone off-topic.

PHP versioning is very important for launching ClassicPress. ClassicPress will be retaining a LAMP (PHP and MySQL) environment vs. the new PHP and REACT framework Gutenberg offers.

The basic argument is 7.0 will run faster and be more secure (that’s important). But that can also break existing themes and plugins.

I’m all for going 7, but a lot of people who try ClassicPress won’t understand why their site breaks, and will blame the software. Going with 5.6 will help the majority of new users switch over.

~ posted by Avrom

Would it be easier to migrate to 5.6 first, and then move to 7 later?

I think 5.6 first. We may not like it, but there are a ton of people still on older versions of PHP.

I’m all for going 7, but a lot of people who try ClassicPress won’t understand why their site breaks, and will blame the software.

We will not break people’s sites: we will just deny the migration (or the upgrade) if the PHP version is one that we do not support.

~ posted by James Nylen

We will not break people’s sites: we will just deny the migration (or the upgrade) if the PHP version is one that we do not support.

That makes for an even stronger argument for setting a minimum version of PHP at either 5.6 or 7.

I think 5.6 first.

Yes, this discussion has me thinking that this would be the better option to start with.

~ posted by KTS915

To me, the discussion about breaking sites is a mute point. Sites are already breaking due to popular plugins cutting off support for anything below 7.0.

And what is supported is not really up to WP. It’s up to PHP devs.

5.6 only has security support. Why would WP want to stay with a version that holds back all the new security and performance features, especially considering that hosts are desperate to make the upgrade for their own sake’s.

And why would WP want plugin devs to continue maintaining a plugin that has to support PHP 5.6, 7.x, and Gutenberg? That is a heck of load on them.

It seems like dragging this out will ultimately cause more headaches and site issues.

I hope we can leave the mentality behind that sites don’t require some technical expertise, and begin educating DIY site owners that they now have to pay attention to what’s going on with the back side. Too much is changing now that they’ve never had to pay attention to before, like PHP, HTTPS, security, and more.

WP has the opportunity to help move things faster into the future instead of being so afraid of breaking something.

~ posted by BlogAid

To me, the discussion about breaking sites is a mute point.

It is a moot point, but that’s because, as @James Nylen explained, we won’t be breaking sites at all. We will just prevent them from installing ClassicPress.

And why would WP want plugin devs to continue maintaining a plugin that has to support PHP 5.6, 7.x, and Gutenberg? That is a heck of load on them.

Whether we set a minimum version of PHP 5.6 or 7 (or anything else) will have no impact on such plugin developers because WP will continue supporting lower versions of PHP anyway. So this is a red herring.

5.6 only has security support. Why would WP want to stay with a version that holds back all the new security and performance features, especially considering that hosts are desperate to make the upgrade for their own sake’s.

I think you are conflating different issues. Nothing is stopping users or hosts choosing to use PHP 7 to take advantage of its security and performance upgrades. Setting a minimum version of PHP for ClassicPress, on the other hand, is about enabling us to rip out old PHP code that is no longer secure and which currently exposes everyone who uses WP to its insecurities.

So long as CP’s minimum version of PHP is still getting security updates, then we will continue to achieve that purpose. So 5.6 would be just as good (for the moment) as 7. Which is why I suggested earlier that this seems to be more of a matter of what is easier to do initially.

~ posted by KTS915

Of course nothing is stopping folks from using PHP 7. It’s that the same millions of site owners who have no idea that Gutenberg is about to roll out, and have never heard of ClassicPress, also don’t know that the PHP version matters.

Simply disallowing them to install it is not the same educational experience, and doesn’t light a fire under plugin devs. That’s my real point. We’ve already got a mess on our hands. Let’s help folks get where we’re all going faster.

~ posted by BlogAid

@Avrom Who said anyone was off topic? Please explain as I don’t understand what you are getting at.

~ posted by Terence

@KTS915 and @James Nylen are absolutely correct in their logic. There seems to be very little justification for talking on all the WordPress technical debt in ClassicPress, and doesn’t it (somewhat) defeats the purpose of the hard fork solution?

~ posted by Terence

I am for a gradual approach but more faster then compared to wordpress itself.
Anyway bump to php 7.0 for me is not enough, because 7.0 will be derepcated and unsupported for december 2018.
In case is better to have php 7.1 or 7.2 http://php.net/supported-versions.php

With the bump we can remove also a lot of unit tests suites.

Anyway this after the 1.0.0 LTS release when we will start to do changes more heavy in the core.

~ posted by Daniele Scasciafratte

The argument about the current statistics of PHP 5 is not acceptable. Users who have an outdated PHP version will probably not update WordPress (and will not migrate to ClassiPress). PHP 7 is the future, if you have to migrate, make the effort to migrate to something that is safe and up to date.

~ posted by mickael

I think @Daniele Scasciafratte makes an excellent point. We should be taking a vote on “7.x (current version)” as opposed to “7.0”, since the release date of the anticipated 7.x version of ClassicPress is not stated. And don’t forget @mickael what you say is all true, AND its orders of magnitude faster.

~ posted by Terence

“Users who have an outdated PHP version will probably not update WordPress” - Likewise, @mickael, this is not enough of an argument for us to know where we actually stand here.

We will need to collect some data on PHP versions of people who want to switch to ClassicPress. We can do this using our migration plugin.

~ posted by James Nylen

@james I think it depends on what ClassiPress wants to become later. If ClassiPress wants to attract as many people as possible, yes, PHP 7 is not the right idea…

~ posted by mickael

There is a compelling argument which can be made for page load/site speed and PHP 7.2 is, in fact, three times faster than PHP 5.6. --> https://reviewsignal.com/blog/wordpress-hosting-performance-benchmarks-2018/

~ posted by Terence

I run all my servers on PHP 7.x for this reason (and others, it is just so much nicer to code against).

We are going to bump to 7.x as soon as we possibly can, but I am thinking that 5.6 is a better intermediate step.

~ posted by James Nylen

The difference can be significant so making 7.0 as a minimum is a great idea!
Some real word numbers to showcase the performance differences:

WordPress 4.9.4 PHP 5.6 benchmark results: 49.18 req/sec
WordPress 4.9.4 PHP 7.0 benchmark results: 133.55 req/sec
WordPress 4.9.4 PHP 7.1 benchmark results: 134.24 req/sec
WordPress 4.9.4 PHP 7.2 benchmark results: 148.80 req/sec

Old PHP versions are not just slower but also more vulnerable. Still millions of WP sites are running on 5.6 or lower More benchmark numbers are listed here https://kinsta.com/blog/php-7-hhvm-benchmarks/

~ posted by Tom Zsomborgi

So I got thinking about this (remember I’m coming from a multisite standpoint as it is primarily what I use). Support for below 5.6 shouldn’t even be considered. Most shared hosting providers don’t even (want) support anything below 5.6 anymore so we should drop support as well. I say minimum version being 5.6 and if people are in a situation where they can’t use 5.6+ then it will leave a gap in the market for a managed solution which is not a bad thing. The ability for people to build a SaaS business around WordPress is one of the primary reasons some of the more sophisticated plugins come to be, these businesses will spend the money an average blogger won’t on development. Even at 5.6 I do believe it’s not something we should encourage or support long term but more as a stepping stone. Support 5.6 with a dashboard notification that it’s out of date and support will be dropped in a future release. PHP 7 is where we want to be as quickly as possible without alienating the average guy.

~ posted by Dustin Snider

Love the idea of jumping straight to PHP 7, but I think it will curb enthusiasm to use the platform as long as WP is still supporting old versions. Hosts aren’t ready for it. Many devs aren’t ready for it. I think it would shoot CP in the foot to start with PHP 7. That said, once CP is well-adopted, it will make more sense for hosts and devs to get with the program and CP could lead the charge.

~ posted by John

Support 5.6 with a dashboard notification that it’s out of date and support will be dropped in a future release.

This sounds fine to me, though we’ll probably need some help implementing if it is going to make it into v1.0.0.

~ posted by James Nylen

PHP 5.6 min. But very soon PHP 7.x.

The sooner the better. I use multisite for almost all projects. PHP 7.2 is my preference.

Suggestions about people who either can’t or won’t upgrade the PHP version seem rather moot to me. If a person is interested in changing to another version of WordPress, they should be able to handle upgrading to PHP 7.x . Either this is a break from the old or it isn’t.

Hosting isn’t what it used to be. If a host isn’t keeping up with stable releases of PHP the client should change. I know there are a lot of plugins and themes slow walking the upgrade. If there is going to be a separate update process using Github or another source for CP, then those wanting to work with this project will provide updated versions of plugins and themes. It’s to everybody’s benefit.

My opinion.

~ posted by a ClassicPress Supporter

I’m all for 5.6 minimum (even though PHP 5 will get its last security update in ~60 days) and gradual steps toward 7. With 7, though, I don’t think we should step-by-step it… just dive in with whatever is current at that time. Anyway, this has already been discussed at length here; I’m just really wanting to know: what is the final decision?

~ posted by Code Potent

@CodePotent the label “Planned” has been added, which means that it is scheduled for v2.0.0

~ posted by Pieter Bos

We haven’t made a final decision about which specific version to support in the 7.x series, though. We’d like to take a look at usage by version, support timelines, etc before we do that.

~ posted by James Nylen

In the other hand, keeping support for old PHP versions can really help when migrating a new site from an old one. Lets say you need to revamp an old website for your client, it’s very convenient to be able to run both old and newer websites on the same server, until the new website is ready for production. But if the old site doesn’t support recent PHP version and CP doesn’t support olders, you’ll need to develop the prototype to an other server, which bring a lot of complications…

~ posted by maxime

I run WordPress sites on PHP7.2 with very little issues. Most plugins and themes I have found don’t have a problem and WordPress is okay with it. How old are the sites you are talking about? What version of WordPress would you be working with that wouldn’t support PHP7.0?

~ posted by a ClassicPress Supporter

I’m actually talking about old websites that don’t run on WordPress

~ posted by maxime

If the core target market is businesses, we need to frank to the end user. We should bump up to stable versions to reduce backward compatibility management, security issues and bad software practices.

I also think we can always invest in getting business owners to see advantages plus task their hosts to up their PHP versions support.

~ posted by Laurence Bahiirwa

@maxime Sorry, that’s a crazy reason to support older versions of PHP. Any decent developer has a local copy of the site to develop on, and isn’t doing development directly on production lol

~ posted by Xander Bertison

Here’s what I am thinking as far as a plan for this change:

• All ClassicPress 1.x versions will support PHP 5.6 and greater.
• We’ll bump the minimum PHP version with each major version of ClassicPress, and use a PHP version check to make sure the site is compatible with the new version. If the version check doesn’t pass, then we’ll block the upgrade (similar to how the migration plugin works today).
• When we get closer to version 2 release, we’ll take a look at the distribution of PHP versions on ClassicPress 1.x sites.
• In a ClassicPress 1.x release, we’ll include a prompt to upgrade older PHP versions. This should help move the needle further and push more people to upgrade.
• We’ll use the results from the active installation numbers, as well as the PHP support timeline, to decide on a minimum PHP version for ClassicPress v2.x. It may be as high as PHP 7.2 and 7.3, but we need more information about active installations, timeline, etc first.

If that works well going from v1 to v2, it should be an approach that we can repeat with each major version of ClassicPress.

~ posted by James Nylen

I think the above sounds like a perfect plan!

~ posted by Xan Bertison

James that’s a wonderful plan. It is mindful of users.

~ posted by Laurence Bahiirwa

This is slowly picking pace with https://github.com/ClassicPress/ClassicPress/issues/438

~ posted by Laurence Bahiirwa