It’s been almost a year since PHP7 shuffled shyly onto the Internet. The lack of attention it received is positively baffling. Perhaps it is fear of the unknown, or perhaps it is because there are enough people around who still remember what it was like upgrading from PHP4 to PHP5.
Or it could be simply that as a free, open source product, PHP doesn’t have a multi-million dollar budget lavished on marketing it. Yet, this being the first major update to the Web’s most popular server-side programming language in 12 years, you’d think it would have generated considerably more excitement.
The people responsible for developing and maintaining PHP have promised that version 7 is going to be more efficient than the previous release by a long way, which is certainly a great selling point. You may then think it’s probably high time to consider upgrading now that it’s been around long enough for the potential problems to be identified and fixed. But before you rush to start the installation, perhaps you should take a moment to contemplate exactly what that is going to mean.
Besides, that assumption that being nearly a year old means all the problems have been found and fixed is fundamentally wrong. Serious problems were still being identified and processed as recently as October 13. By the time you get around to viewing that link, the list will probably have grown.
Then there’s the issue that if you don’t fully manage the server yourself, your ISP might not be installing the latest “bug free” version of PHP7, they may be installing an older version. And after they’ve installed it, you might not be able to patch it yourself, so that means at the very least you’re adding to your own workload and the administrator’s workload by having to request patches as they’re released.
Walk, don’t run
Upgrades are one of the leading causes of headaches and insomnia for administrators, and for developers it’s even more detrimental most of the time. So before you upgrade, you need to be totally sure that you need to do it, want to do it, and that you’re totally prepared to do it.
Green light on all three criteria? Well, I guess you can probably go ahead and do the upgrade, then. But you’d better be totally sure about that last one.
Don’t misunderstand what’s being said here. You definitely should upgrade to PHP7, but what you really need to avoid is rushing into it. The more time you can give yourself to be totally prepared, and the more time you have for testing and correcting things, the better it will be for you and your clients.
This is especially true if you have a lot of third party software running on the websites you host, because many of them are likely to just stop working. Fixing those third party applications won’t be a lot of fun because not every coder maintains your high standards of code formatting. Actually, most of them don’t, which is why the PHP4 to PHP5 upgrade was so painful for so many.
This comment from user Detain on SlashDot in 2007 explains the agony of upgrading and the consequences for those who manage websites for others. With PHP7’s even more pedantic approach to error handling, you really have to wonder just how many times you’re going to hear from customers complaining that you broke their site during those first few weeks after the upgrade is implemented.
Determining the need
This is the logical place to start. If you don’t urgently need to upgrade, then it’s very sensible to wait, and that’s a really good thing because it means you can afford more time for getting ready.
The primary question to ask yourself is: Are your current programs running sluggishly? If the answer to that question is no, then the number one reason for upgrading is already eliminated.
Why you might want to, regardless of need
There are actually some very good reasons why you might want to upgrade to PHP7 and most of them can be explained by this infographic from Zend. It’s clearly been created to sell you on the idea of upgrading and will probably influence you that way, but just be aware that unless you have a particularly heavy server load or your applications are absolutely monstrous in scope, you most likely won’t see much of a visible difference in the execution of your programs.
To put this in the proper perspective, PHP5.6 is already more efficient than other popular server-side languages such as Python, Perl, or Ruby. PHP7 is just a whole lot more efficient again, so you’re getting an extra order of magnitude in terms of speed and performance over something that was already very good.
Where PHP7 really does seem to shine is with WordPress 4.1, and certainly anyone who does a significant amount of WordPress development will appreciate improved efficiency. As a WordPress developer, you also know that any kind of upgrade you do needs to be done cautiously, because there’s considerable risk that some plug-ins or even entire templates may malfunction when something in the operating environment changes.
This need for caution isn’t unique to WordPress, it’s actually necessary with every CMS, but WordPress comes with so many plug-ins compared to all of the other available CMS options, that there’s potentially more that can go wrong. You can’t be certain that your upgrade won’t have problems just because somebody else’s didn’t, unless you are using exactly the same plug-ins.
Apart from the efficiency factor, PHP7 also provides improved error handling (which is ironically likely to be the source of most early teething troubles immediately after upgrading) and a new comparison operator, promisingly named a “spaceship operator” but unfortunately not quite as exciting as the name suggests.
But maybe the best reason of all for why you might want to upgrade to PHP7 is financial, and if you can mirror the experience of Badoo, as explained in this blog post, you’ll definitely be vindicated in making the choice to upgrade.
This is more than just a boy scout motto, it’s a rule to live by. Never more so, in fact, than when you’re planning to implement a major upgrade.
Your first step is going to be examining things as they are now. This means making a detailed list of all the software currently in use on all the sites you are hosting. Then you need to do some research into each and every one of those programs which depend on PHP, which in fact is likely to be most of them.
Suppose, for example, that one of your customers is using Pommo for sending out newsletters. This is a popular list-based mailing program because of it’s simplicity and the fact that it gives you control over message throttling. Those factors help to keep it popular despite the fact that everyone using it experienced difficulties during upgrades to PHP5.3 and then to PHP5.4, and you can be certain that the jump to PHP7 will be a much bigger one.
To research this effectively, you’ll need to start by doing a Google search for something like “Pommo upgrade problems PHP7”. Learning from your mistakes is excellent, but learning from the mistakes of others is way better (because that way you don’t have to suffer the consequences of the mistakes). Yet it’s here that you’ll encounter the first of many frustrations.
As of November 2016, if you’re one of those brave souls making the effort to upgrade to PHP7, you’re still firmly a member of a minority. So far, very few people have been willing to make that technological jump. This is despite glowing testimonials, like the one from Badoo, who claimed they saved $1m thanks to this upgrade. But then again, the logical question is: “What does one million dollars mean to a company like Badoo?” For them, it’s probably chump change.
You see, when a multi-billion dollar company says they saved a million dollars, it’s nearly the same as you saying: “Since I started leaving the Jag at home and driving a Mazda hatchback to work, I’m saving at least $20 a week on fuel.”
Unless you’re already spending more than one million dollars on your server solutions, it’s not very likely that you’re going to save that much, even if Badoo could do so. Such claims need to be put into some sort of perspective before you can apply them to your own situation.
Of course, even though Pommo is popular, the userbase is dwarfed by bigger enterprise-level applications like WordPress, so you should find far more results for major league applications versus the relatively minor league ones. It will still be slim pickings, though, and you’ll be mostly on your own.
That last statement is a clue as to why so few people have gone ahead with that upgrade. Even companies that provide shared hosting—usually so eager to foist upgrades on their clients without asking first—are showing incredible restraint. They know how much extra work the upgrade is going to generate for them, and you can be sure that this pales into insignificance compared to how much extra work it’s going to make for you.
Just in the case of Pommo alone, there are at least 238 individual PHP files spread over more than 20 directories. And that’s just one application out of maybe more than a dozen you’ll need to learn the anatomy of and perform surgery on.
At the heart of all these problems is one simple fact: many old but still popular PHP applications were created for PHP4, and received only minor changes to make them compatible with PHP5 (which still was largely backwards compatible with PHP4). In PHP7, that backwards compatibility has been eliminated, and anything created with PHP4 style constructors is going to fail. Likewise if any lazy developers used non-standard PHP code block declaration tags, those sections of code are not going to work.
Another potential problem is the removal of # style comments from ini files, and that is likely to affect even more programs, including possibly your own self-developed ones. That commenting style is incredibly widespread, due to being used in many other programming languages.
Now for the upgrade
Hopefully by this point you have already conducted a thorough audit of your hosting environment and you know how many applications may need to be adjusted, and you have a handy list of problems and solutions that others encountered. Now you’re ready to roll up your sleeves and get to work.
Ideally you should be performing an upgrade test in an isolated environment before going live on the Web with it. This won’t always be possible, however, so if you don’t have that luxury, you should start by backing up absolutely everything.
It has been recommended by many experienced upgraders to purge your system of PHP5 before attempting to install PHP7, and who are we to argue?
The process of uninstalling PHP5 will vary depending on your operating system. For Linux, which is what most PHP developers will be using, you can use sudo apt-get purge php5-* but use the -s switch first to run a simulation of what will happen before you go ahead and do the uninstall, and by no means should you ever use the -y switch for something as big as this, no matter how confident you are. An example of how to run the simulation is: sudo apt-get -s purge php5-*
If you’re on Windows, there is no simulation possible, but it’s also probably a little safer compared to removing PHP5 from a Linux system. You may be able to uninstall PHP5 from the control center, or you may have to manually delete it from the command line. From the command line, you would navigate to the location of your PHP5 folder, then use: rd PHP5 /s/q (if your version of Windows doesn’t support rd, use rmdir instead). If you prefer the comfort and safety of being prompted for each file and directory before deleting it, just leave off the /q (quiet mode) switch from the end.
To uninstall from Mac OS/X, if your PHP5 wasn’t installed as a package, you’ll need to use BASH. From a BASH terminal, you can navigate to the location of PHP5, which will probably be /usr/local/. Then you need to unlink any symbolic links already created by the system with sudo unlink /usr/local/php5 followed by a manual removal of the entire PHP5 directory with sudo rm -rf /usr/local/php5-* (if you’d like extra protection against accidentally deleting something, use the switch -rfiv in place of -rf, as this will prompt you with a verbose explanation at every step).
The procedure again varies dramatically between different operating systems. On all systems, performing a manual installation (by compiling from source code from the latest stable release from https://secure.php.net/downloads.php or find it on GitHub) is the best, but most complicated, way to do it.
Note that there are different packages available for Windows and ‘Nix-family operating systems (Unix, Linux, OS/X). Make sure you download the correct one for your system. Inside the archive files, you will find instructions on how to do the compilation.
Alternatively you can use the Microsoft WebPI on Windows, as long as you’re aware it comes with a lot of extras such as SilverLight, which you may or may not want. On Linux (Debian-based and Ubuntu-based systems), you can use apt-get or whatever similar command your system uses (eg: yum). You’ll need to locate a reliable repository or ppa and add them to your software source list. It’s not our place to recommend any unofficial repositories, so we won’t do that.
After installing, you’ll need to test all your existing PHP applications to see if they still work. Many of them possibly won’t.
The first thing to check for, as noted earlier, is PHP4 style constructs, and non-standard PHP code declaration tags. Find them and replace them with modified versions for PHP7.
Next check for error handling problems. PHP7 actually improves error handling, with many previously unrecoverable fatal errors being able to be handled, but that comes at a price that some legacy code won’t work correctly if it uses older style error handling methods. You can test for any kind of exception or error, but the PHP5 method of catching an exception of type Exception won’t work. You can specify each unique type of error that you expect to encounter, for example:
This means in PHP7 you can scan for different error types and respond to them differently, depending on what caused the error, and without needing to do a lot of additional coding. As for what won’t work in PHP7, it’s this:
So you’ll need to look for that type of code structure in the applications you’re checking and replace it with:
There’s going to be plenty of other little “gotchas” lurking in most programs too, but there are just too many scenarios for us to try to document them all. Eventually you should be able to solve any problem through a combination of Googling, contacting the original application developer, and asking questions on developer forums.