In March of this year, Iain Poulson published a post on the Delicious Brains blog called “Hey WordPress Plugin Developers, Stop Supporting Legacy PHP Versions In Your Plugins.” I agreed, and am a WordPress plugin author, so I read it and wished people would listen and moved on with my day without taking any action. Later, when we announced we were dropping legacy PHP support in Caldera Forms, I cited that post as one reason for the decision.
I’m being honest here, I was going to wait for someone else because I was worried that if I dropped support for PHP 5.5 and below, I’d get a ton of negative reviews or lose a ton of users or the sky would fall. But, we took a chance and the sky did not fall.
Yes, we lost a few users, but for a large WordPress plugin, more and more the choice, generally not a well-informed one, to use PHP5 in 2018 is a good sign that the user is more trouble than they are worth. I hate to have to think that way, but it’s not scalable to put the needs of those who do not maintain their servers or use a reputable host ahead of those who are properly prepared.
Yes, WordPress core still supports PHP 5.2. But there is no reason why a plugin developer should follow the standards for core development, when not working on core.
In this post, I’m going to show how we handled dropping legacy PHP support, share some insights from the team behind the Events Calendar who recently announced they will also be dropping support for legacy PHP versions. Then you can do the same thing for your plugin.
What Is Core Doing?
As long as I have been WordPressing, when PHP 5.2 support should be removed has been a hot topic of discussion at WordCamps. At the community summit before the WordCamp US 2015, it seemed like everyone but leadership was behind making this change.
The concern was that it was too complicated for users to change PHP versions. I was sitting between two employees of hosting companies, both googled “How to upgrade WordPress PHP version” and pointed at the long list of articles explaining the point and click steps in cPanel to do so.
Since then, core has changed the recommended PHP version to PHP7. There is also a project, called servehappy underway to raise awareness of this issue and eventually add tools to add admin notices.
In my opinion, this is a lot of fear-driven inaction. The Android and iOS app stores tell consumers every day that their version of Android or their model of phone is incompatible with an app upgrade or OS upgrade. People get this, it’s common.
I’m not in charge, and I fully acknowledge that my move faster argument probably comes from not fully understanding the scope of WordPress.
But, I’ve also done support for WordPress plugins since 2014. Every time I’ve told someone their lack of HTTPS or out of date PHP version was an issue, they’ve been happy to get the security and/ or speed boost. And even if they didn’t know what PHP was is, your system needs a software update makes sense to people.
It’s time for an aggressive timeline to remove PHP5 support from WordPress, as well as insecure HTTP, but that’s just my opinion.
One positive thing that has happened is that you can now add a PHP minimum version header for WordPress plugins. This acts as a warning for users but does not stop them from installing the plugin.
What Are Other Plugins Doing?
As I mentioned in the introduction, The Events Calendar product suite, a WordPress plugin calendar solution by Modern Tribe will soon require PHP 5.6 or later. In addition, Easy Digital Downloads 3.0, which is under development, will require a modern PHP version. I asked Jeff Serani, a strategist for The Events Calendar about what was most exciting for their team as they move into a PHP 5.6+ future:
The main reason for this adjustment is from a QA and Support familiarization team perspective. It’s far more efficient to cover testing on PHP 5.6+ with a wider range of tests, rather than having to water down our reach of testing when covering so many edge case scenarios. Shifting to more recent versions of PHP also allows us to lessen time spent on bug reports coming in for well-outdated versions. Shiny bells and whistles are fine from a dev perspective, but a better/more-reliable experience for customers is the key.
One concern I have, and I’ve heard from other WordPress developers is how to communicate this change to users, given our limited options allowed by the WordPress.org rules. Jeff told me about how Modern Tribe is tackling this problem:
We’re finding communication bit is easy with this change. The vast majority of our users are already on PHP 5.6+. For the remaining group, we’re introducing dismissible banner alerts targeting users <PHP 5.6, we’ve published a blog and KB as well as informed users via a newsletter update. We’ll plan to continue a similar path with communicating and ensuring folks are well-informed of this adjustment as we get closer to our end-of-year roll out. It helps seeing so many other plugin authors taking a similar initiative with their product suite. We, as a community, are ready for this change.
Our initial plan with fallbacks is to build in a block to prevent users who are not on PHP 5.6+ to upgrade to newer versions and the fallback would be simply that, the user can no longer upgrade. While we will inform any edge cases that arise that they can revert to back to an older version of the plugins, we’re still in planning for how best to handle these situations.
Dropping Legacy PHP Support Safely
That said, it’s clear that you should support legacy PHP support. Here is the way to do it safely and efficiently.
I think the two key things to keep in mind when you decide to drop legacy PHP support. The first is communication about the change. The second is making sure when you do make the change, you fallback gracefully. Let’s start with communication since that is very hard and has to get done first.
Communicating The Change
For Caldera Forms, we started with a blog post in March. We then made it so it looked like you could not create a form if your PHP version was out of date. Everything still worked. We just replaced the new form button with a big red warning about the PHP version.
Because I’m super pedantic, I introduced a whole API for the version checks and warning message. You could do something as simple as this to add an admin notice to alert affected users of the upcoming change and direct them to your PHP version related resources:
View the code on Gist.
We also set the PHP minimum version header:
View the code on Gist.
We only added Freemius Analytics to Caldera Forms recently, so our data isn’t great yet. While we did see some users uninstall over this, it was a small number.
Making The Change
Once our PHP 5.6+ only release came, I decided, based on a helpful conversation with Zack and Jeff from Events Calendar, on a plan for graceful fallback. I didn’t want installing the plugin on an incompatible site to crash the site.
It is important to keep the main plugin file PHP 5.2 safe. We have never supported PHP 5.2 in our commercial plugins, so this was already an established practice. The main plugin file should be responsible for checking dependencies and either loading a “bootstrap” file that is not PHP 5.2 compatible or showing admin notices without including the bootstrap file.
In Caldera Forms, if the PHP version check or the WordPress version check fails, in addition to the admin notice, we also add different shortcode handlers. Since the normal shortcode no longer works out of date servers, if someone updated and the plugin just put up an admin notice that wasn’t noticed, a likely scenario, for a different ranty post, they would not see the change.
Since the normal shortcode handler is no longer registered a naked shortcode would happen. Instead, I added a shortcode handler for the same tag, that shows a message — it’s different if you have access to edit Caldera Forms settings — that the form cannot be displayed. The exact messages that they show are in the titles of pages in our docs. The goal was to make it as easy as possible for users to figure out what they meant and how to fix them. I also created saved replies in Helpscout to help out team direct users quickly to those docs.
Again, the sky didn’t fall.
Now It’s Your Turn
WordPress has created a lot of technical debt for the web. The PHP language has evolved a ton since PHP 5.2 was released and WordPress plugin developers can help drive down its adoption and help increase PHP7 adoption, speeding up the web and demonstrating that WordPress core is wrong to still support PHP 5.2.
With the approaching end of life for PHP 5.6, and all of the great features of PHP7, why wouldn’t you want to?
WordPress core is moving slowly on this issue. I wonder how much that the caution is based on fear that arises from untested assumptions. Plugin developers can lead by testing this assumption that regular WordPress users can’t manage a PHP version upgrade.
Josh Pollock
Josh is a WordPress developer and educator. He is the founder of Caldera Labs, makers of awesome WordPress tools including Caldera Forms — a drag and drop, responsive WordPress form builder.
The post How To Drop Legacy PHP Support In WordPress Plugins appeared first on Torque.
