[UPHPU] PHP 4 EOL Announcement

Mac Newbold mac at macnewbold.com
Wed Jul 18 10:44:30 MDT 2007

Today at 9:58am, Lonnie Olson said:

> Wade Preston Shearer wrote:
>>> Here's the crux of our problem: The sites work great as is. The clients 
>>> are happy. What reason do they have to pay for an upgrade that won't get 
>>> them any improvement? What reason do we have to eat the cost of an upgrade 
>>> to their site for free? What reason is there to risk a major upgrade and 
>>> any breakage that might go along with it when the existing stuff works 
>>> fine?
>> I agree. If it is a one-off custom website for a client, then, yes, there 
>> is no reason to update it if it's running fine. If you are developing an 
>> "application" though then I think that that is different.
> But I think these one-off custom websites, which are frequently hosted 
> virtually, are the biggest cause of slow adoption rate.

I agree, they're definitely a big cause. But it's hard to blame them if 
PHP5 doesn't give them a good reason to upgrade. Here at work we develop 
new sites and maintain old ones every single day, and we've gone for years 
without a compelling reason to install a PHP5 server. In fact, I'm very 
glad I haven't so far, at least up until 5.2 came out, because there was 
still a lot of upheaval within PHP5 I understand. We're in the process now 
of getting PHP 5 set up here for our new work, but we're also keeping PHP4 
around for sites that aren't compatible and would cost too much to 

One good case for upgrading is tossing the upgrade costs in with other 
improvements and changes to the site. In that case the cost of the 
php4->php5 retrofit is smaller compared to the other costs they'll be 
sinking into maintenance. But when they don't need any other changes, 
there is no maintenance cost anyway.

Once the security patches for php4 stop flowing, and new vulnerabilities 
continue to be found, php5 does offer something they'll want, and more 
will tend to upgrade. But they'll still do it hesitantly I'd wager, 
because they're being forced into choosing between two painful options: 
live with security holes or endure a painful upgrade.

You also said, "The old saying "Don't fix it unless it's broke" doesn't 
apply to programming, because the refusal to fix it will eventually 
*cause* it to break." I disagree at least partly with that. If none of the 
software changes (apache, php, mysql, web site, etc.) what reason would 
there be for any of it to break? I've seen a lot of web sites that don't 
break at all during upgrades within the PHP4 family, and can go for years 
with no maintenance costs.  It isn't practical to assume none of the 
software will need to change, cause any piece of it may have a security 
hole you want to fix, or a new feature you want to upgrade for.

When I do start upgrading sites to work with PHP5, I'm hoping that it 
isn't as painful as I fear it might be. For the most part the work we do 
has been very compatible with most of what I've heard about PHP5. For 
example, usually there's not much reason to use OOP on our projects, so we 
won't have to worry much about that in our upgrade. In a few places we've 
reimplemented php5 functions in php4, checking if the function exists 
first, and if not, declaring our own version. We've followed consistent 
practices with regard to things like register_globals and magic_quotes, so 
if changes are required, we can probably make them on many sites in the 
exact same way, making it quicker to do. But at a busy time of year, the 
idea of doing a bunch of upgrades when we have other things to work on 
that are more valuable to the client, the upgrade still doesn't sound 

If PHP6 is as painful to upgrade to as PHP5, they'll experience the same 
thing all over again, with people avoiding the upgrade and getting 
frustrated at all the extra pain they're going through because PHP decided 
to switch directions again. I have heard that PHP6 doesn't break as much 
stuff though, so hopefully that's not the case.

I would have been much happier if PHP5 was more backward compatible, and 
added new functionality without breaking old functionality, and simply 
deprecating it. Then in PHP6, they could remove the old stuff after people 
had time to get used to the new stuff. If you want people to upgrade, you 
need to make it as painless as possible, and as valuable as possible, or 
people will hold out until the cost is lower, the value is higher, or the 
cost of not upgrading gets too high to bear.

Anyway, it's a sad commentary that discussions like these are still 
happening after 3 years. It is a real problem, and a big one, and I hope 
the PHP team, as well as other open source projects, learn a whole lot 
from the mistakes that were made this time, and don't repeat them.


Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/

More information about the UPHPU mailing list