[development] Easier PHP4 compatibility for Drupal modules

[Larry Garfield]

On Tue, 10 Jun 2008 16:22:01 +0200, Eric-Alexander Schaefer <eric.schaefer at eas-consulting.de> wrote:
> Earnie Boyd schrieb:
>> I say just refer them to http://www.gophp5.org/ and add the banner to
>> your project page.
> 
> How will that help small community sites with a cheap hosting company
> that refuses to upgrade to php5?

It gives them a nice long list of hosts who want their business and aren't hamstringing them.  That's why GoPHP5 still has that list up. :-)

>> Drupal 7 will only support PHP5.
> 
> There should be a cut like this to encourage the upgrade, but all
> previous versions including contributed modules should support php4.
> 
> Eric

PHP 4 vs. 5 compatibility is a lot more than just what functions are available.  What you're looking for is the PHP_Compat library, available in PEAR.  It's user-space backports of most of the new functions in PHP 5.  It's under the PHP License, but I believe the author said he was willing to relicense it for us under the GPL.  I actually wrote a patch to add about 80% of PHP_Compat to Drupal 6 early last year, which Dries rejected.  (In hindsight, I believe he was right to do so.)  One of the key problems with it, I didn't realize until later, is that PHP parses and loads conditionally loaded functions *even if the condition is never met*.  The condition being met just aliases the internal name of the function (some gobbldygook unique string) to the requested name.  It eats up memory either way.

However, many many modules don't support PHP 4 for other reasons.  Frankly I think it's foolish for any module that deals with XML to even bother trying to support PHP 4; the XML processing system is completely different, and PHP 5's XML processing can save you 40K of source code over PHP 4's.  (cf, Amazon Tools module.)  The way object references are handled are different as well.  SPL classes really have no capability to be backported.  Proper timezone support didn't exist until PHP 5.2, much less 5.1.  Plus, many of us, like the OP, don't even have access to a PHP 4 system anymore to test against.  I don't even know if some of my modules work in PHP 4.

I agree that a common php4.module is better than several modules re-implementing various PHP 4 utilities themselves and causing namespace collisions.  However, Drupal 6 modules that depend on PHP 5 features should be declaring that fact in their info files to prevent themselves from being installed on unsupported versions.  Having a "compat" module will mean users will have to edit (hack) the info files of those modules to remove the php requirement line, and then hope that the PHP 5 features it depends on are covered by the compat module.  I do not see "hack the module and pray" as a viable recommendation to give anyone.

The better solution is to make it as easy as possible for people to migrate off of hosts that are still running a version of PHP that is no longer supported anyway.  Point them to GoPHP5, point them to "migrating to a new sever" instructions on drupal.org, etc.  Helping extend the life of PHP 4 is doing people a disservice, just as much as keeping them on Windows 98 for longer would be.

--Larry Garfield