PHP

PHP carries a reputation that stopped matching the language years ago. Today's PHP has declared types on parameters, properties and return values, enumerations, and a static analysis ecosystem that finds bugs before a single line runs. What has not changed is something else: the distance between PHP written with discipline and PHP written in a hurry is still enormous, and most of the PHP that causes trouble belongs to the second group.

Our way of proving which group we work in is to show the code. ZoneMirror, our cPanel and WHM plugin for replicating DNS zones to Cloudflare, is published under the MIT license: static analysis at PHPStan level 8, the strictest level on the usual scale, and 690 test methods running green against PHP 8.2, 8.3 and 8.4 in continuous integration. That is not repository decoration: it is what makes it possible to upgrade the PHP version the day it is due, instead of postponing it for years out of fear of what might break.

The other half of PHP work is not in the code, it is on the server. PHP lives inside a concrete configuration — version, extensions, memory limits, and on shared hosting layers like CloudLinux and CageFS — and a real share of production problems is born there rather than in the application. We cover that part too, and it is documented in public: the diagnostic cases we have solved on cPanel servers are written up on the blog, with the symptom, the cause and the complete fix.

With legacy applications the criterion is the same and the order matters: first pin the version and the dependencies, then static analysis with a baseline of what exists, then tests around each area before changing it. Rewriting is sometimes the right answer, but it is almost never the first one, and taken without measuring it is the most expensive way to rediscover what the old system already knew. If your PHP application works but nobody dares touch it, that is exactly the starting point we know how to work with.