We have the same problem. The backwardscompatibility issues are small, and we could easily fix our own apps. But we also do hosting for several hundreds of websites not created by us. Getting all our customers to fix their sites (and providing them with a means to test) will be hellish.
What strategies can be employed by shared hosts to deal with this problem? Given that there isn’t a magic wand to fix it and many shared hosts have limited manpower, what to do?
For me, wearing a “shared host customer” hat, the number 1 issue is information – if a host want’s to migrate to PHP5, they need to communicate a clear schedule for doing so, with realistic time frames (e.g. at least 3 months warning). With that should be the warning that customers need to start testing their code against the new PHP version.
In general, as I’ve said before, think there is room for improvement on the type of information some shared hosts provide. All PHP installations are not the same, even when the version numbers are equal, that magic
php.ini file or available extensions being the difference between code that “works” and code that doesn’t. To that extent think shared hosts need to release full details here – the exact PHP 5 version they plan to use, a sample
php.ini reflecting how PHP will be configured, a list of extensions which will be available and anything else that might be relevant.
Those steps should be enough to satisfy experienced PHP hands. But what about those for whom PHP means just downloading and FTPing code found via places like Hotscripts?
Imagine the best approach there is giving customers an environment to be able to test their code on. The expensive but perhaps most effective would be laying on a test server running PHP5. Reality, cost and broken URLs are an issue there though.
An alternative approach might be providing users with a “ready to install” LAMP or WAMP environment which reflects the planned configuration but they can run on their own PCs – something along the lines of XAMPP or similar.
Somehow a technical solution would also be nice. Wonder if sandboxing capabilities of runkit could be used to help shared hosts spot customers problems for them automatically. That doesn’t fix the problem but at least people can be warned. Perhaps similar info could be extracted using PHP on the command line using the lint option
$ php -l