Last weekend I attended SunshinePHP (it was a blast; you should go next year if you didn’t this year…or if you did, for that matter). Friday night, there was a panel on minimum PHP versions, with an eye to raising the bar to something in recent, non-end-of-life history rather than allowing versions that won’t get security fixes anymore. The battle cry there was one of pushing hosts, devs, sysadmins and communities in general to newer versions (5.5, 5.6, and 7 late this year) in the name of better speed, better security, and a much happier environment for developers.

This battle cry was mixed with the explanations of some panel members on why their packages still support PHP 5.2 and 5.3 (remember, both now no longer get security fixes), with remonstrances that increasing a version requirement on CMS-centric frameworks like CodeIgniter, or CMSes themselves like WordPress and PyroCMS would end up stranding user bases on unsupported, vulnerable software if they increased their minimum version requirement to something reasonable, rather than getting those devs and end users on a supported, more dev-friendly version of the runtime. For full-stack frameworks, and given the proliferation of, and ease of migration to, 5.4+ hosts, I find this unconscionable, for reasons stated eloquently by Anthony Ferrara.

But another member of the panel also supports PHP 5.3 with his libraries: Paul M. Jones with the AuraPHP project. Why am I not railing against this…and the fact that the Aura v2 libraries actually downgraded their version requirements relative to Aura v1? Paul mentioned that the effort to allow 5.3 compatibility was quite low (remove short array syntax, remove callable typehints), but there’s a better reason: Aura libs can be used to modernize applications and serve as a bridge to current versions…and you want to put the other end of the bridge where those apps are sitting right now.

You see, Paul’s book about Modernizing Legacy Applications in PHP addresses real problems in real code bases. Those code bases are likely running on an old version of PHP, maybe because they flat-out won’t run on anything newer, thanks registering globals or using some other feature that has been removed in the last few years (mostly in 5.4). A lot of these issues are poor coding practices to start with and many don’t take long to fix (PHP is quite good at backward compatibility), but you can’t upgrade your runtime until you get rid of the forward-incompatible changes in your code, and as you’re modernizing you need somewhere to refactor to.

Now, you could try and refactor your code base into a framework, if the framework supports 5.3 (which I argue that it probably shouldn’t), and if shoehorning your existing code into your framework all at once is an option (it probably isn’t). Or you can clean up your code over time, using libraries to avoid reinventing the wheel for concepts like URL routing, dependency injection and parameterizing where-in SQL clauses. The fact that these libraries are well-tested, decoupled and, yes, compatible with PHP 5.3 means that they can be used as part of an incremental refactoring process. You can even keep them around post-refactor because they’re well-designed, well-tested and compatible with PHP 7.

Nope, that’s not a typo; thanks to the Rasmus VM, I was able to test all of the Aura v2 libraries while at Sunshine against the current dev version of PHP 7. All but Aura.Session and Aura.SqlSchema passed right away. Jury’s still out on SqlSchema due to its database dependencies for testing, but a one-line change (more on that in another post) in Session fixed that library in the smoking-fast version of the Zend runtime that isn’t even out yet. Point being, the version compatibility bridge created by Aura libs is miles long, which is great news when you’re trying to enact a Renaissance on your old PHP code.

Do Aura v2’s low version requirements imply that other libraries and frameworks should strive for the same level of compatibility? Of course not; there’s no need to have a ton of actively maintained libraries serving as a bridge to projects currently living in the past. Nor should end projects stay on an older version because the library support is there. Don’t feel bad about using short array syntax, callable typehints and the like, whether in libraries or the projects consuming them. But if you’re still dealing with old code that won’t run past 5.3 (or 5.4), you have the tools you need to modernize your app to the point that it’s no longer bound to an outdated runtime. So what are you waiting for?

P.S. If you want to modernize and don’t know where to start, ping me. I may not have enough hours in a day as it is, but I’ve done forward-compatibility migrations before so I can answer some questions in that arena.