PHP Tips, Resources and Best Practices for 2015
PHP has had many reputations over the years, but being insecure as a language never really was one of them.
The core team, all its faults notwithstanding, is rather quick in pouncing on all security matters, and updating PHP to the latest version will often allay all worries. But the end users, such as we are, tend to mess things up. We don’t update, we use outdated packages or packages with holes in them we’re not aware of, we use ancient extensions… we expose ourselves to risk in some truly creative ways.
Tips, Resources and Best Practices
Let’s start 2015 off right, shall we? This post will list important resources you should have in your brain/toolbelt before building anything with PHP in 2015. I’ll do my best to keep this post up to date, so it stays relevant indefinitely, but, like I said, I’ll need your help.
Keep your PHP up to date
When I wrote about the cancer that is legacy code, I focused on application code. I still firmly believe that you should never develop for the lowest common denominator, else you risk becoming the very thing that’s holding your language’s progress back. That’s not the focus of this section, though. Recently, a new version related discussion ensued.
CodeIgniter and WordPress are sticking with PHP 5.2 support (a version that’s been dead for four years now and shouldn’t exist on anyone’s server), and Anthony Ferrara responded in his blog post. Before you read this section any further, I implore you to read that post first. It’s important.
What that post accomplished was getting some people too lazy to upgrade riled up.
They argued for legacy support without considering the damage they’re doing to the PHP ecosystem. Anthony wrote another post in which he further explains his stances, and finished up with yet another post taking apart installation percentages of old PHP versions across the web, comparing them to the stability list to find out how many servers running PHP out there are insecure by default and hackable – today. The results are frightening to say the least.
If you’re developing something and are running anything but the latest major version of PHP, I urge you to give these posts a thorough read. If your client insists on host X or version Y for whatever reason, refer them to these posts, educate them, and help them see the error of their ways – teach them about the vulnerabilities they’re introducing to their project, and tell them about the horrors that can happen if they don’t act before it’s too late. Upgrading your PHP’s version is not something you should file under “we can do that later”. Do it now, and do it often.
Avoid outdated hosts
Inspired by the aforementioned discussions, Phil Sturgeon compiled a table of current PHP versions supported by various hosts. You can find it at PhpVersions.info or if you’d like to contribute and add some missing values, on Github.
I recommend you steer clear of all shared hosting in general – there are extremely cheap VPS providers out there now, like DigitalOcean (feel free to check them out via my ref link for a leg up).
Don’t be these guys. It starts out innocent and simple, but when you end up having to lend out your partner while doing someone else’s laundry, it stops being fun.
When opting for a VPS, other than saving you from sharing an environment with everyone else or being susceptible to the instability of a system as introduced by someone else, setting up your own server from scratch is a fun and rewarding experience you should be familiar with anyway. Besides, you can see on the list that barely anyone has the latest PHP version as the default one – why settle for anything but the latest software when starting a new project?
Encryption is crazy important today. Not just as a means of defending yourself from government snooping, but also as a way to make sure your clients and website visitors are protected as well and aren’t leaking any personal data. With advocates such as Ilya Grigorik and his pitches for TLS to Google announcing it would favor websites with HTTPS in search results, there’s no question about the ever increasing importance of HTTPS, even for simple websites.
While there are workarounds to getting HTTPS everywhere, one shouldn’t rely on those – it’s our responsibility as web developers to improve the web at large. HTTPS is not directly related to PHP, but whenever you’re starting a new PHP project it’s generally easier to set up your server to use HTTPS before you start coding, rather than in the middle of a project. To help you get through this often cryptic, daunting and discouraging task, (at least until Let’s Encrypt is out) Chris Palmer put together this Google Doc.
Secure your PHP
Don’t be these guys.
Follow best practices in password protection, generation, encryption and authentication. Read books and use packages like those suggested on the SecuringPHP site.
Stay on the Right Way
PHP The Right Way is responsible for improving the life of many a PHP project out there. In book form or digital, PTRW is an indispensable resource for making sure you’re fit to handle the challenges of modern app development. If you feel like it’s missing something or just want to contribute with typo corrections or alternative resources and guides, feel free to do so via Github.
Avoid Bad Packages
Almost two years ago, Fabien Potencier of Symfony fame announced the creation of a list of vulnerable packages for PHP. A year and a half later, this became standard part of Symfony and was turned into open source public domain property. You could now post your composer.lock file to their API or the web interface, or even the CLI tool, and it would check your project for vulnerabilities. However, this still required one step from the end users, and we’re lazy, lazy people.
Enter Roave team, the laziest of us. They made a security-advisories package which uses this database of known vulnerabilities. As Marco Pivetta explains in his blog post, you require it in your project like any other package, but instead of downloading anything, the package serves as a meta-package, not downloading anything and instead checking for whether the bad versions are required in your project. It will warn you and prevent even the attempt to download those packages, saving you not only a checking step, but a step that includes deleting them as well.
I urge everyone doing PHP development to include this in their projects. By jointly attacking the common vectors of insecurity, we’ll be one step closer to eradicating security holes on a large scale.
Dodge common mistakes
We’ve compiled lists of common mistakes before. Read the following posts to learn what to avoid:
- TopTal’s list of 10 Most Common Mistakes PHP Programmers make
- 7 More Mistakes Commonly Made by PHP Developers
- 18 Critical Oversights in Web Development
By keeping these in mind, you’ll save yourself a world of trouble and major headaches down the road.
Use Vagrant! Even PTRW says so.
Vagrant helps you run cloned environments in small, headless virtual machines that forward requests to ports inside the machine, letting you use your host’s browser and your host’s IDE without interference. Want to nest a virtual machine inside a virtual machine? You can do that too, and it’s all completely safe! We’ve got a bunch of Vagrant tutorials and explanations under the Vagrant tag, so if you’re confused about the technology, read up.
Here at SitePoint, we have an officially endorsed fork of the Homestead Vagrant box (prepared by Laravel’s Taylor Otwell, but compatible with any framework and PHP application) called Homestead Improved. It’s runnable in under five minutes and you’ll have a completely encapsulated PHP environment to play in – with no fear of messing up your host OS or other projects. Made a mistake? Just destroy, rebuild, and you’re back where you started (with zero code lost) in a minute!
Note that we’re using this box in all our tutorials, so getting familiar with it now will both save you some time in the long run, and help you follow along with everything we do with great ease, not to mention the effect it’ll have on your local development environment.
Blackfire.io is a service from SensioLabs, the guys in charge of the Symfony framework and all its related technologies. It’s a transparent and low-overhead profiler able to analyze your code and alert you to issues with everything from application logic flow to interactions with the DB engines and even the cache layer. Blackfire is already installed in the Homestead Improved box mentioned above, so if you use our box or the original Homestead, you’re all set!
Catch problems before they throw a wrench into production! More detailed tutorials regarding Blackfire are coming soon!
We looked at some important links and resources for starting off your 2015 PHP projects properly, with performance and safety in mind. If you’re already using all these approaches, good for you – you can help us spread the word. Tell your friends and developer circles about it, direct them here, point the newbies who ask you how to get started our way and refer to the specific links in the post whenever someone tells you that legacy code should be supported and old PHP versions are fine. Send them here, and we’ll rough’em up!
Disagree with any of these? Would you add some critical resources that the resources we’ve linked to don’t already mention? Let us know – I’ll make sure the list gets updated!