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
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.
A few things to add here.
WordPress – who I used to really enjoy making fun of for this – are actually doing some amazing things to try and fix their PHP 5.2 addiction. I was talking to Andrew Nacin, who mentioned they are tracking sites still using PHP 5.2 to run. They are then contacting the owners of these sites, and the host companies themselves, to try and help the upgrade process, even offering advice.
Different projects have different approaches. Drupal might just say “Fuck you we’re recoding everything.” but WP has a stronger focus on compatibility, and that goes beyond the developer mindset of just “change it randomly and if the end users notice they cant upgrade and don’t know what PHP 5.4 is or how to find one then… well… they should find out or something.” That approach as you say might work in communities that are heavily developer dominated, but do not work for everyone.
I’m not a huge fan of any of these projects staying behind on older versions, but I do understand why each of them has their own unique reasons for doing what they do.
> 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.
I know what you mean, but something to remember is that these developer focused tools are used to build WP-like software, which is NOT developer focused. This is why I sometime use the example of PyroCMS when talking about this stuff. We had to stay a fair way behind what was popular with developers so we could be popular with our marketplace. Competing with WP is already hard enough without going all hard modern dependency on people.
Luckily, these FWs are getting better.
ZF2 is dropping PHP 5.3 as you know: https://github.com/zendframework/zf2/issues/7095
CodeIgniter 3 now recommends PHP 5.4 and has added a “should” to PHP 5.2: https://github.com/bcit-ci/CodeIgniter/commit/934d6d9797f4dadd4e4d05b12bc4d7309fedb6c3
It even adds a security warning:
> It should work on 5.2.4 as well, but we strongly advise you NOT to run such old versions of PHP, because of potential security and performance issues, as well as missing features.
I mention all of this just to highlight that the situation is not as dire as one might think looking at your and Anthony’s posts. 🙂
I’m didn’t intend it to paint a dire picture, only give my own opinions! But thanks for your feedback Phil.
Thanks! Yeah, I know you weren’t pointing and shaming. I guess a shorter version we could both agree on is:
Unless you have some f**king exceptional reasons for doing so, you need to be releasing new versions of software in which you clearly label that you only support currently supported versions of PHP.
I don’t really buy into this, outside the WordPress case. WordPress is meant for the non-technical to get going with and that’s fine. The bigger ‘problem’ in WordPress is the commitment to BC in terms of plugins anyway.
Outside end-user friendly products I don’t think the argument that people are building products that need maximum compatibility really holds water. For a start most things (based on statistics I just made up) built with e.g CodeIgniter are going to be for a specific use and built by someone technical . That person has a few options:
1. Advise their client on finding hosting that supports 5.5, 5.6 whatever. We talk about this stuff as if there isn’t a shared host in the world that runs anything past PHP 4. If you are technical and buying services from people who don’t offer something up to date then you are a Bad Person.
2. In the case that their client just won’t abandon CrapHost, you’re just going to have to go ahead and use an older version of your framework. Tough luck! Hey, with git you can even use the very moment before those breaking changes were introduced. Moving the latest version of your framework to an actually supported version of PHP doesn’t mean that the old versions are going to magically poof and disappear. I realise it would be more work but as a framework maintainer you can also look into LTS and back-porting what you can.
5.2 is old old news, and this discussion around versions is going to keep coming around again and again until it’s dead. I’m fairly insulated from all of this because I don’t work on friendly end-user deployment focused products, but frankly I’m not sure why it’s even up for discussion when we’re already 4 years past 5.2 EOL