1. Change thousands of lines of code (probably `sed`-able)
2. Patch PHP to re-introduce the original bug/feature
3. Downgrade PHP back to the version that had the
bug/feature you were relying on
Why is option 3 not considered in this thread? It was working before, and evidently they can control the version of PHP (since they can patch it). If upgrade breaks X, and you rely on X, don't upgrade. If you need to upgrade for Y, do so, and fix X. That's just how such things work.
Problem 1: The old versions do not get security patches. For example, entering the number 2.2250738585072011e-308 hangs the interpreter in old versions, as far as I know this is unpatched in PHP <=5.1. This allows a very effective denial of service.
Problem 2: You are delaying the unevitable; it's nice to use new features of the language, having to code in old versions is a pain for developers. Small continuous upgrades are easier to handle than rare gigantic ones.
Small continuous upgrades without ever changing your code is the same cost as a gigantic one without ever changing your code - they either work, or they don't, in variously subtle or spectacular ways. The tipping point lies at some changeset, you just need to hit it.
You upgrade, you may need to change things. It's just a fact of life. Or, you pick a library / language / framework / everything that guarantees 100% backwards compatibility as documented, that never has bugs (since fixing those breaks 100% backwards compatibility), and you never use features in even remotely-unexpected ways. Like in this case.
Ah, I must have missed that part, thanks. Though changing hosts is equivalent-enough to upgrading software that I think the point still stands. They probably changed hosts to save money - either go back, or fix what the changes broke, it's part of the standard expectations of changing things.
edit: actually... no, that still doesn't work. They clearly have 100% control over the interpreter since they can patch the source and use the patched version.
