Nick Lewis, Larry Garfield, and Dries Buytaert are discussing the slow rate of PHP 5 adoption and how projects such as Drupal and WordPress should help encourage PHP 5 uptake by phasing out support for PHP 4. WordPress currently supports PHP 4.2 or greater. We don’t even use functionality that was introduced in PHP 4.3. Whenever we accidentally use a PHP function present only in 4.3 or greater during our development cycles, we get a fair number of complaints from testers who don’t have 4.3. PHP 4 is thoroughly entrenched. If we were to change WordPress to require PHP 5 right now, we would abandon the majority of our users. Given the current state of affairs, requiring PHP 5 in the near future would seriously marginalize WordPress.
PHP 4 is so entrenched because it does the job. The bugs afflicting PHP 5 haven’t helped convince hosts to move over either. Almost every time a host does a PHP 5.x.x update, WordPress and other apps are broken in some way. Convincing hosts to upgrade to PHP 5 when doing so results in a lot of unhappy users is a hard sell. Sticking with PHP 4 means less support headaches for them.
That said, I agree that we do need to get people moving to PHP 5. Convincing developers to move is easy. I sure would like to have some of the PHP 5 features to make my life easier. A lot of WordPress developers are chomping at the bit to use the goodies in PHP 5. Developer convenience is secondary to the convenience of users, however. Chasing the latest tools and stranding users in the process is not cool.
So, how do we bring PHP 4 to the end of its days without showing our users the door? I don’t think application developers should be spearheading an end-of-life on PHP 4. PHP needs to bite that bullet by setting an EOL date for PHP 4. An EOL on PHP 4 will be the biggest motivator for hosts to move to PHP 5. A lack of PHP 4 security fixes surely would make for some movement. Application developers would help by ensuring their stuff runs on the latest PHP 5 releases. Barring the occasional bugs, that is already the case with most well-known PHP apps. With a PHP 4 EOL in place, applications can EOL their PHP 4 support sometime thereafter. We at WordPress are in a similar situation with MySQL. We just recently bumped up our MySQL requirements. Part of what made that possible is the EOL announcements on older MySQL versions. If PHP is the chicken and applications are the eggs, I say the chicken gets to go first.