Thread

PHP 4 was discovered to be terminally ill on July 13th, 2007, when the doctors made the announcement that it had only until the end of the year to live.  They were confident that it would remain vital until December 31, 2007 (when support would officially be withdrawn), at which point it would be comatose, lifeless, only able to receive pain management (security fixes as needed) until 4 days ago, when PHP 4 fully expired.  However, like Shyamalan’s Crowe, PHP 4 has no awareness that any of this has taken place, nor that it is dead.  Likewise, neither do most server vendors or hosts.

Continue reading…

I loved that read and the analogy you put forward in that one Derek 😉

It is a shame though that hosts don’t catch up although I suppose they will when it comes around to PHP 6 we will probably all be using V5 then 😊

Great read!

Best wishes,

Mark

Great article. I feel your pain.

I develop solely in PHP 5 though I often run into clients whose host server runs 4 only. As ridiculous as it seems to me, I find myself better off developing in fashion that will be either be compatible or easily made so instead of griping about how stupid everyone is for not having updated by now.

In fact, this is one of the major reasons I switched to CodeIgniter: it helps me do this, and I’m glad you are sticking to the same philosophy for EE.

I think the mac development community has been dealing with this sort of thing for awhile, too having to make everything work and be optimized for both Intel and PPC.

Still, every time I run into a host that still uses PHP 4, I get that same feeling as a web developer as when I find people using IE 6: pure, unadulterated, ungodly rage that just isn’t healthy.

____________

Ben Midget
www.avanthill.com

Well, going PHP5 only doesn’t make sense for us at this point. That said, CI already has separate librariers for PHP4 and PHP5, so you’re not missing out: if your server supports it, PHP5 will be used automatically. I think that’s a workable approach.

Victor, the advantages are fantastic for developers, but at the end of the day, a site’s visitors don’t know or care what neat tricks or what scripting language was used to build the site.  I feel your pain, but it’s just not realistic to expect everyone to abandon a very stable and seaworthy ship.  Enterprise server solutions have to provide support on shipping products for many many years.  So the latest and greatest RHEL for example will continue to support (and patch themselves if necessary) PHP 4 for many years to come.

If you have the luxury of developing PHP 5 only, either from controlling where your clients are hosted, or hosting yourself, that’s great.  I’d love that control.  If every user of ExpressionEngine was hosted at EngineHosting, so many parts of our job would be so much easier.  But alas, that’s not the case, and is one tremendous difference between developing hosted applications (or client sites in general) versus a distributed application.

Kind of reminds me of this beast and the problems it brings! 😉

You note that PHP5 only has 40% market share… It would be interesting to know what the market share is for actually installs of ExpressionEngine.  That is, of all the licenses out there, what percentage are running with a server that can handle PHP5?  I’m guessing much higher than 40%...

I recently had my website make it into a nice little stumbleupon surge and was amazed to see that 95% of the users were using FireFox.  Obviously that says something about the users, and if that percentage stayed constant for my site, my IE worries would be much smaller.

Statistics are cool!

We collected (opt-in) that metric when we released 1.5.1, and at the time fewer than 10% were on PHP 5.  That’s of course quite some time ago.  But it’s pretty close to what the overall spread was at the time, and I would guess that the stats for users today matches the overall stats presented in the post pretty closely.  It’s of course only an indication of what was being used, not what that host allowed.  Unfortunately that’s not something easily measured.  But even if it were, it wouldn’t be a overriding measurement, as we’re interested in keeping the largest available market we can, not solely catering to existing users.

You know, this is the same problem as IE6 vs. IE7 and new browsers. I see it as a fundamental problem, because of the middle man that patches things up.

If we take a look at IE6, why do people still use it? Well, why wouldn’t they, they see a nice, functional page when they type in your adress.. why? Because you have gone through great lenghts to hack the CSS and everything just so it works in IE6. If the site works for users, why should they switch? If it ain’t broken, don’t fix it.

Same goes with PHP4 vs PHP5 and hosts. The software is free, so why don’t they upgrade? Well, why should they? Developers go through great lenghts to ensure that PHP4 is still supported, the people buying the web apps most often don’t look at the code, they just use it and it works fine, why should they tell the host to upgrade? And why should webhosts upgrade if it works?

Break it, make people notice it, tell them that if they want better/cheaper/whatever software because the devs don’t have to spend resources & money on fixing it for redundant old stuff and you’d get more functions and better safety, they should go tell their webhosts to take a day to update their old crap. Same goes for IE6, stop using css hacks, make people realise IE6 sucks and not supported by you, and that they should update.

If everyone sticked with the same old stuff, we’d still be sleeping on stone beds and hunt with sticks and stones for food. Evolution has to happen sometime, why not take the first step? :p
A little more serious, I can see why you need to support PHP4, it’s not your fault most webhosts are run by lazy people who won’t upgrade for reason X or Y or for no reason at all, but like I said, if nobody knows there is a better (and even better, free) upgrade to important software because people go to great lenghts to support the old, how would they know the new software exists?

Wolferey, I kind of touch on that in my last paragraph.  We (developers) would be fooling ourselves to think that we can enact revolutionary change in a separate industry by taking that stand.  Hosts would simply tell their clients to use other software.  Who is the client going to believe?  Should the client even be put in that position in the first place?  And in fact, a large number of developers tried this last year, and you can see the results of their labor.  Slow, steady, unmodified adoption rates of PHP 5.

they should go tell their webhosts to take a day to update their old crap

Hopefully you’re being sarcastic and don’t really think it’s that easy of a situation.  Ties into another statement:

The software is free, so why don’t they upgrade?

PHP may be free, but supported distros for professionally managed environments is extremely costly, to say nothing about the time it would take to update once support for new distros was purchased, and the time, headache, and support costs of all of the clients who are inevitably adversely affected by the change.  Before you go laying blame entirely on the hosts, you need to travel one more level up the food chain to the vendors who supply hosts with the operating systems and the support for those environments at the hosting level.

Imagine you are a hosting provider that has tens of thousands, or maybe even hundreds of thousands, of customers who use PHP 4 applications, to do business, to blog, to run forums, to run communities, using commercial applications, open source ones, and custom developed ones.

What are the odds that all of those sites will continue to work correctly after you upgrade your servers to version 5?  Pretty small chance.  In fact, most of your customer’s sites would probably break.  It would be a nightmare scenario for a host.

And actually, if you were in the hosting business, why would you even *want* to stop offering PHP 4 to your current customers who have perfectly functioning sites?  Nothing good will come from you forcing them to upgrade.  You’ll create incredible headaches for yourself.

From a hosting business strategy it does makes sense to offer both php 4 and 5 as an option for new customers.  There are still thousands upon thousands of PHP 4 only applications on the market, and of course lots of PHP 5 only apps, so a hosting company who want to be successful is better off giving their customer a range of options.  Hosts do not benefit from giving customer less options, they gain from giving users more options.

And as Derek mentioned, OS and hardware vendors have a say in this too.  We run Red Hat Enterprise on our servers, and they are very conservative about supporting new versions of Apache, PHP, MySQL, etc., until those version have been thoroughly tested and deemed very stable and secure.  The potential impact of a security hole or instability is quite severe, so as a responsible company, Red Hat plays it safe, staying several versions behind the current one.

As a software company, we’re in a similar position.  ExpressionEngine has been around for four years, and is installed in every conceivable hosting environment, on servers all over the world, so we would be crazy to drop php 4 support when most of our users are still running it.  Our existing customers would be angry and we’d lose business.

Edit:  By the way, PHP 6 is already out in developer versions.  By all accounts, it’s going to become what PHP 5 should have been, so it’s quite possible we might never see widespread php 5 adoption, as hosts jump straight to version 6.  The issues of backward compatibility will still remain, though.

I would like to post my take, and actually Rick covered some of this already but I figured I would not rewrite my message 😊

Keep in mind its not always the hosting company’s fault.  In many cases the off-the-shelf control panel systems were still only bundling php 4 for a number of years after php 5 was released and php 5 would be something they would have to add/maintain themselves.  You can still ask the same thing in a different context, why do a lot of hosting control panel systems still by default ship with apache 1.3.x when apache 2.2 has been out for what at least 2 or 3 years now? (Sorry did not originally finish this though) Its because certain ways of doing things changed between Apache 1.x to 2.x and required both apache config file changes, and could break things in .htaccess files.  Fun huh.

In our case to keep things stable and secure, and not throw surprises at clients (ie: hey we upgraded from php 4.3.x to 4.4.0 and broke random sites overnight, hope you don’t mind), we chose long ago to base our servers on a fully supported commercial OS, Redhat Enterprise.  Redhat does not change major versions of software they include with a release.  So current release version of Redhat Enterprise is v5.  Version 5 has a base code version of php of 5.1.6.  This version will not change for the life of Redhat Enterprise v5, which Redhat provides support for 7 years after release date.  They release new Enterprise versions about every 18 months, and even Redhat Enterprise v3 still has a few years left in support and its base php version is 4.1.2.

If we were to compile php 5.2.x and place it on our Redhat Enterprise v5 servers we will then lose support from Redhat, and code stability, neither of which are ideal for us, or our clients.

Just because the base version # does not change ie: 5.1.6, Redhat backports bug and security fixes into their code base, they simply don’t add new features/functions or change the way functions work within the application.  Hence when the security fix that was released for php 4.3.9 in the 4.4.0 release, along with how a few things by default worked in php there were many people that woke up on the net to broken web sites if your web host had to patch by upgrading, rather than patch how we did.

We do have clients and software developers that have contacted us, even very recently, asking either for us to hold off upgrading their hosting accounts from our Redhat Enterprise v4 clusters (php 4.3.9 base code) for a few months, or tell them its not possible but to give them at least 1 to 2 months to certify their code on php 5.

There are always multiple sides to any story, and usually in this case the web hosting companies are painted as the bad guys, when in reality the “delay” in upgrading may have very little to do with what people assume is simply a lazy web hosting company, and as Rick pointed out, very viable business reasons to do so.

Derek Jones:

Ofcourse my point is exaggerated, but the reasoning remains the same: If the people responsible for keeping things up to date, like if you are an IT-admin in a large company who might be a wiz at putting together the network and monitoring it, but don’t know that something as a webbrowser could harm company security (hacking, using exploits in the old browsers code they have cracked etc.), who is to blame? It’s a little of both, ofcourse, but my point is, even if the admin is somehow not up to date on the security flaws in IE6 and everything seems to be working fine and IE6 is rendering pages beautifully, just because web developers go to great lenghts to support it, why run an update to IE7? Why not make a site with IE6 hacks, but have a notice for IE6 users (like the http://www.savethedevelopers.org/ one) so they become aware?

Same goes with webhosts and such. I’m not saying it’s wrong to support php4, what I’m saying is that if everyone who writes php5 applications also go through great lenghts to support php4, how would webhosts or the users of the applications that php5 existed? You can do it with quite simple steps. Include a notice in the readme or admin panel or something saying: “We see you are using php4. We support it, but we recommend you ask your webhost to support php5 as well. See reasons why here: (link to website explaining the benefits of php5)”. That shouldn’t be hard for a developer, right? People become aware, they get to know the benefits and can notify the webhost.

Ofcourse its a dreamworld, but its a step in the right direction.

Rick Ellis:

If I was a hosting provider for tens of thousands, I’d atleast have the decency to find a solution for the customers who need php5 to run php5 applications. They have no excuse for not doing a simple google search, like I just did. To quote: “You can run php4 and php5 as a cgi binary, or php4 as cgi binary and php5 as an apache module (or the other way around)”.

That’s pretty much just updating your httpd.conf, tell your customers there will be a quick restart, or they’d run in an environment where they have parallell servers so they can restart and upgrade without the clients experiencing trouble. Or even so, you could still offer two types or servers, one with php4 and one with php5.

Thus, you can keep offering your clients both php4 and php5, and probably double your success. Like you say, from a hosting business strategy it should make sense. But how would they know, if no users ever tell them they would be better off with php5 for new features and such, and they have apps that support php5? Most of they time, they just install it, it works, horray happy day, continue life.

Don’t take my exaggerated points too seriously, like I say, I understand why you’d want to support both versions, and that it all depends on many more variables than this. My point is, if nobody knows solutions/upgrades exist, why fix the old, working stuff?

It’s that fundamental problem I see, when the middle man patches things up, but leaves the end user clueless of it. Thus, the end user lives a happy life, while you live a life consists of 08:00 - 16:00 + overtime + extra days to patch up + supporting potensial problems in the patches :p.. not to mention company loosing money because of extra dev time + paying for people who might know how to do proper patches and immitate new features in the old software + support if some patch isn’t correct/done poorly etc., which might be greater costs than the income of the company thus you loose your job. (exaggerated, if your didn’t get that yet :p)

At one point, you need to make people aware, if not you can add +coding in and recoding patches and testing and whatnot for every old system you can think of that most users still use even thought v6, v7 and v8 came out a long time ago because they still run v3, v4 and v5 :p

what I’m saying is that if everyone who writes php5 applications also go through great lenghts to support php4,

Your argument falls flat here, because one does not have to go to great lengths to support php 4.  One simply must avoid a few language constructs and functions that are specific to php 5.  It’s quite simple, really.  In fact, it costs us zero additional development time.

Anyway, cheers!

Well, that might be because I don’t really know much about php :p

I’ve mostly meddled with some script language that is a variation of C/assembly for PIC processors for a summer job (educated in electronics and space technology at school). One of our early programs had a pretty horrible scripting language, took us ages to write simple scripts because of all the code you had to write to get things working.

A couple of versions later, the company that made the program touched up on the scripting language, streamlining alot of the things that took us ages to do, but breaking the syntax from the previous one. On average, we could write a fairly simple program in 2-3 days in the old one, and make the same program in around a day with the new one. We still had to support the old PIC processors that we couldn’t flash because they weren’t supported in the new updates, so that ment we had to write the same code twice. I’m not complaining, I got paid well to sit there and code with my friends :p