I can clearly remember when I was a Ghost Programmer – clocking in and out of 9 to 5 jobs, and switching off when I got home. Like most jobbing coders, I used to have ideas that I’d play around with when I knocked off the job, some half-arsed side projects and the odd little job for friends or family, but largely I’d not think about coding on evenings and weekends. There must be thousands and thousands of developers just like this working on PHP projects right now.
I tell you this, not to try and boast about how far I’ve come, but mainly because during those times I never once thought about (or cared about) the version of PHP I was coding on. PHP versions were always constrained by the hosting company, and that was something that was dealt with by my boss, or my client (depending on if I was working full time or contract). Many times I had no idea what version I was using to develop on locally, or if that version was in conflict with the version being run on the production server. Many, many times I had code returned with the comment “our server doesn’t support x function”.
I thought of PHP versions like I thought of PHP extensions, it’s nice if the server supports what I need, but if not I can just code around it.
I mention this period of my life for lots of reasons. Most people reading this will be doing so because they’ve seen me promote it on Twitter, or they’ve seen someone they respect in the PHP community promote it on Twitter (if I’m doing my marketing right). You’ve already won. You’re following people who do the same job as you on Twitter, you’re reading blog posts, you’ve probably been to a conference or two. You’re aware of the community, and therefore you’re aware of the community driven best practices. I bet you, like me, try to make sure the projects you work on are running on the latest stable version of PHP. When that’s not possible, you at least try and make sure the PHP version you’re running is secure and largely bug free. That means running a version of PHP that is not end-of-life (EOL).
There’s been a lot of discussion in and around the community lately about PHP versions. Certain high profile projects are still supporting versions of PHP that are end-of-life, and therefore are almost certainly insecure. Over in my own little corner of the PHP world, Zend Framework 2 still supports PHP 5.3.23 which is EOL. I’m not here to cast the first stone.
I completely understand why large projects like WordPress, who have a huge install base, try to support as wide a number of PHP versions as possible. They make their money by people installing and using their software, so they need their software to be able to run on as many platforms as possible. But, and in my mind it’s a pretty big but, for me, these products are not solely aimed at developers. They’re aimed at the semi-technical person who wants to get a blog (or a CMS, or a shopping cart) installed and running as cheaply and quickly as possible. The owners of these projects have a vested interest in making installations of these products trivial, and that means shared hosting, and that means PHP versions that went out of support in the Dark Ages. You can one-click install this software on many shared hosting environments and have a blog running without even knowing what PHP is, let alone if it’s secure.
I can understand that argument, even if I find it difficult to forgive it.
But there are also another set of products that ARE aimed squarely at developers. These are frameworks, foundation packages and componenets that aim to help development be as rapid and easy as it can be. It trivialises lots of fundamental security problems by supplying things like escaping in the views, input filtering, SQL abstraction and parameterisation. Its job is to help make sure that most of the things you do as a developer are secure. It’s these projects I have a problem with supporting versions of PHP that are EOL.
When I was a 9 to 5 developer I wouldn’t have known if the version of PHP I was running was insecure. But I did badger for upgrades of both PHP itself and extensions because I wanted to use a tool that would make my life easier. There are thousands of people developing on insecure versions of PHP who have no idea of the problem because their framework supports that version. For me (and this is a contentious opinion I know), it’s reckless for these project owners to trade their user’s security for install numbers. Because, again in my opinion, that’s exactly what is happening. You would rather have nice big install numbers for your framework or component than ensure your users are running their application securely.
There would be uproar if there was a known security hole in ZF2 and as a community we decided not to patch the bug because it would lower the target market for the framework. That’s exactly what’s going on when projects support EOL versions of PHP when they’ve had an opportunity to move on.
For me it’s negligence.
-FIN-
