Why are you not using PHP 5?

Andi Gutmans on :

Hi Ilia,

I think the statistics are off because if I'm not mistaken they look at the installed base of applications and not at what PHP developers are writing new functionality and apps in.
Based on our customer base we see that over 70% are actually using PHP. So I think it's fair to say that the majority of development today is on PHP 5.

Cheers,

Andi

Ilia Alshanetsky on :

Statistics are based from the Powered-By and Server headers as reported by the web server. So in terms of the overall PHP community I think it is a fairly good representation of the data.

That said you are right, people developing new applications are choosing PHP 5 more often then 4, but I am curious about the existing install base as well. For example people writing distributable apps may end up alienating much of their user base because 87+% of servers are PHP4 based and their software requires PHP5. So, those developers still end up writing PHP4 code.

Shahar on :

I wonder how the statistics are gathered. I don't read French very well - so I wonder if they are counting domain names or IP addresses.

I would guess that a vast majority of the shared hosting provides (= many domain names on few IP addresses) are slower to upgrade to PHP5.

I wonder what would be the difference between no. of IP addresses and no. of domain names.

Ilia Alshanetsky on :

The stats are based on scanning of IPs and Domain names and checking the Server and X-Powered-By headers returned in response. I believe that IPs with >X (you'll need to ask Damien for the X) are thrown out to offset the effect of hosting companies. So those would still be counted as 1.

Damien Seguy on :

IP with over 500 domains on it are removed. Access providers are also removed from the stats.

That removes shared hosting, domain parking and domain collect-all from the stats, which have no interest. It explains why recent goDaddy (and the likes) moves from Linux to Windows didn't make a dent in the stats.

I'm extracting the IP stats ATM.

Ilia Alshanetsky on :

Damien seems to be having issues posting (captcha not liking him), but he finished the IP stats recently, which I am posting on his behalf:

Using IP, we have :
30,88% displaying PHP only.
64,25% displaying no PHP at all.
4,87% displaying a mix of PHP and non-PHP technologies.

Also, on IP that display at least one PHP configuration,
PHP 3 is available on 0,83% of them
PHP 4 is available on 85,24%
PHP 5 is available on 14,93%
(figures doesn't add up to 100%, since some architecture displays several PHP versions).

Less than 1% of architectures are displaying both PHP 4 and PHP 5.

All in all, figures by IP are close to the figures by domains, tough slightly better for PHP 5.

From the stats, PHP is available on 34,72% of "large domains" (a large domain is a zone that is spread on 2 to 100 distinct IP). PHP is better on large domain than in general.

Damien also intends to include with the general stats starting next month.

Ivo Jansch on :

Andi,

I think having 70% of the Zend userbase use PHP5 tells us a few things:

- A lot of users using Zend products, are actual developers, and actual current new development is indeed often done in PHP5
- All Zend products promote the use of PHP5, which also means that the percentage of php5 users among Zenders will be higher than among the rest.

In my opinion the only interesting 4 vs 5 stats are the ones that look at actual development. If you look at what existing domains are currently running, you have to take the following into account:

- hosting companies running many sites on shared hosting (which is common in smaller countries such as the netherlands) will not upgrade because they cannot guarantee that all hosted apps will still work, and they will not pay for the migration themselves
- many customers running their site on these hosting environments, don't care and often don't even know. Their site was once built for them and it works, and if there's not a development company pushing them to actually improve their site, there's no chance they will move to PHP5.

As a company, we've been on all sides of this debate. We do hosting, and we cannot upgrade everything to php5 because of the amount of legacy apps out there. We do development, and new development is indeed done in PHP5. We maintain old sites and applications, and these will remain on PHP4 because nobody is going to pay for the migration.

So I think we can safely say that amongst 'what's out there', php4 will continue to be used. And as long as most new development is done with php5 (and the zend userbase stats support that), we will be fine.

Richard Thomas on :

http://www.cyberlot.net/whynotphp5

Richard Thomas on :

Sorry bad link and posted before I added my note Why not php 5

It all comes down to the Distros, PHP5 is not in the "stable" or enterprise version of some of the major distros like RHEL, Centos, Debian. Until it is the install base will be held back.

Dave Hodder on :

Happily, Debian "Etch" was officially frozen today, and it includes PHP 5.2. Alongside the imminent RHEL 5, this should give PHP some real traction.

Scott MacVicar on :

FUD about stability and speed that grabbed hold when 5.0 was coming out.

There is also the fact that hosting control panels such as cPanel have no timeline for making PHP5 the default.

We also have server admins with some legacy application that re-assigns this, returns variables by reference etc who take the opinion that if it's not broke don't fix it.

Finally developers writing applications for the masses try to pick a minimum version based on what most customers have. Customers don't upgrade to 5.x because nothing they use requires it. Because the customer doesn't upgrade the developer has to write applications... recursion proceeds.

In all honesty I think providing a way for hosts to run mod_php4 and mod_php5 at the same time will do wonders, running one fcgi and one as an apache module isn't really an option for those giant hosts. If we give them the ability to use both then developers can write solely for PHP 5 in the comfort that there is the ability to easily run both PHP 4 and PHP 5.

Scott

Ilia Alshanetsky on :

In all honesty 5.0 was both slower and less stable then PHP 4 and only starting with the 5.1 series did these problems begin to be resolved.

The reference issue you are referring to was the cause for 4.4, so the BC issue there is identical to 5.X and based on Damien's stats we can see that 4.4 overtook all other releases few month back.

As far as running PHP4 and PHP5 in parallel, I think fastcgi is a great solution. It gives you nearly the same speed as apache module and generally offers much better security.

Scott MacVicar on :

I completely agree with you, there is no reasonable reason for why hosts have yet to upgrade. I think most developers will be of a similar mindset.

Maybe a few emails to those giant hosts like godaddy, 1 & 1 and Yahoo to find out why they are using PHP 4 might shed more light than us all speculating.

An email to cPanel, Ensim and Plesk might also be appropriate.

I've had contact with the cPanel staff before but never enquired into the reasons for not setting PHP 5 to the default.

Bill Karwin on :

I assume that large hosting environments are holding back the adoption of PHP 5.

The compatibility of PHP 4 scripts running under PHP 5 might be as high as 99.9%. It cannot be guaranteed to be 100% perfect for all PHP apps.

But the staff at hosting companies can't afford to test thousands of PHP 4 applications, to figure out which users would be among those affected by the remaining 0.1% incompatibility with PHP 5.

The technical staff at hosting companies are probably spending their time on higher priorities, like fighting the flood of spam.

I agree that one solution is to create compelling PHP 5 solutions, and the market of PHP users will naturally adopt it. More hosting environments will maintain legacy PHP 4 servers, while moving new users to the PHP 5 servers.

Then they can charge the old PHP 4 customers progressively higher rates as they become more rare.

Alan Knowles on :

Scott hit this right on the head:
running mod_php4 & mod_php5 on the same box / same apached etc. is the only real fix. - no kludges / reverse proxies etc. and no fastcgi (as it does not work exactly the same..)

Without this the barriers to migration are "It's a big job - let's put it off till later.." (eg. setting up some weird combo/ or testing 20+ custom applications with PHP5)

Some one has to pay for the migration testing or setup, and is not really motivated by "It's alot better than our current version" - they see 'This will cost x man hours & $xx, or nothing if we leave it as is..".. Until the IT department/staff come back and say "It'll be 1 hour, and we can update our old applications at will.." nothing much will happen.

Ilia Alshanetsky on :

I am curious in hearing about what in FastCGI does not work quite the same as it does in mod_php?

Scott MacVicar on :

1. Lack of control with .htaccess
2. There is no fastcgi support for Apache 2.2 at the moment, we're having to use lighttpd + mod_proxy at the moment.
3. It's simply not as easy to setup as mod_php

The last part is to do with education, there isn't enough tutorials around to show people how to easily run PHP as a FastCGI.

Users need to be able to run PHP 4 and PHP 5 concurrently with minimal hassle, if mod_php4 and PHP5-fcgi is the only way then they need to have their hand held.

Its easy to ask developers but maybe we're not the right people to give the answer.

symbix on :

1)mod_fcgid is fine with apache 2.2.
2)you can use pecl htscanner to handle php_flag/php_value in .htaccess. well, it also requires a stub mod_php5 which does the only thing - accepts php_value/php_flag directives and ignores them - but it's just a few minutes of work

Scott MacVicar on :

I forgot about the cost to upgrade when I thought about this earlier, developer time is not cheap to sit and track errors in potentially hundreds of scripts.

I have a patch for running mod_php4 and mod_php5 on the same box, it involved changing the mime type of PHP 5 and the other Apache variables that get exported like php_flag. Didn't seem too stable though.

I think there is a more prudent need to evangelise hosting companies than developers.

Luca Longinotti on :

Running mod_php4 and mod_php5 concurrently on the same Apache2.0/2.2 instance is possible, we for example have patches to support this in Gentoos PHP Packages (concurrentmodphp USE flag). It involves renaming the mime-types and also versioning all the symbols of libphp4.so and libphp5.so correctly, as well as those of all loaded extensions, and then using dlvsym() instead of dlsym() to load the symbols of the extensions (dlvsym() is a GNU extension to glibc). It's fairly complicated and error-prone if you don't know what you're doing, and it relies on a GNU glibc, so we don't really expect this to ever make it upstream into PHP, but it's possible thanks to Gentoos package manager that handles all the build instructions and stuff gracefully in this case.
Just to tell that it is possible and works very well, and, in my tests, in a stable manner, also providing the ability to load extensions for PHP4 and PHP5 (fex. Suhosin).
Best regards, CHTEKK.

elias on :

expirience:
people remind bad things longer than good things. I.e. if you develop an application with PDO and have to live with hard to find segfaults, then enthusiasm turns into great care. if the bug left open for weeks, great care tunrns into frustration.

well, i still prefer newest versions

speculation:
many php 'developers' simply don't need php5 features. why pdo if mysql_* works? why more oo features if i don't use them? ...

don't get me wrong, i need/want all the new features

thanks anyway for php core development!

Emil Hernvall on :

I think it's about awarness.

- The most common applications like phpBB doesn't require php 5.
- The majority of the hobby/semi-pro users don't use the new features and since they, despite everything, is the by far largest customer group for web hosts the hosts don't bother upgrading.

The only absolute way would probably be to discontinue the 4-series while the 5-series are still active and bc enough (Otherwise you'd have to maintain 99% bc into the 6-series as well) and announce it a year in advance so people have time to prepare. You'd probably lose a few people by doing so, but the important parts of the community would probably support such a move and help educate people.

Question: Php 3 is almost gone now. How long did it take to migrate the entire user base to php 4 back then?

Ilia Alshanetsky on :

I think 3 > 4 transition was pretty quick about 1-1.5 years, but it was driven by massive performance improvement. So the ISPs largely responsible for paving the way to the upgrades.

But there were no accurate stats like we have now... so its all guesstimates.

Charles on :

Why not? Well, I am now, but I had to jump through hoops.

My site was on a shared provider that is highly technically competent, and was running massively customized Linux kernels and versions of various apps. They had no timeline for moving to PHP5 because moving to it would break their custom patches.

I moved to a VPS setup, with a web hosting control panel feature. However, the vendor of the software had no timeline for adopting PHP5, and I ended up asking the web host to perform the upgrade for me (as they knew the internals of the control panel better than I did).

In other words, the bottleneck isn't on user adoption, but on adoption by both shared web hosting providers and solution providers.

Dries Buytaert on :

Simple. You have to provide users a compelling reason to upgrade.

Many websites use a CMS, forum or blog tool and these systems work with both PHP4 and PHP5. And for a long time, they worked better with PHP4 than with PHP5.

I can only talk about Drupal, but from what I've seen, very few Drupal users show incentive to upgrade from PHP4 to PHP5. They are pretty much ignorant to what version of PHP they use, as long it works. Similarly, the hosting companies I've talked with, don't really care either.

If you think of your users as the average website owners (and not developers), the problem is that PHP5 does not offer a critical differentiator compared to PHP4. What is in it for these people? If you want people to upgrade, give them (and their hosting providers) a good reason to. For example, if you can show that PHP5 is 10-20% faster than PHP4 people will start to care. Show me that Drupal runs 10-20% faster on PHP5 compared to PHP4, and I get half the Drupal community to upgrade -- as well as spread the word about PHP5 being a lot better than PHP4.

So why should the average website owner care about PHP? (And don't tell us about the OO improvements.

)

Ilia Alshanetsky on :

Well, let's see...

1) You will get 10-15% speed improvement on PHP 5.2 over PHP 4.4.x in most apps, especially so if your application uses objects.

2) Aside from OO PHP 5.2 offers a lot more native functions & extensions, such as json, hash, SimpleXML, DOM, and many more.

3) You get a date extension that offers a universal timezone support, not reliant on the OS availability of proper timezone data, which is often lacking.

4) A much more extensive and robust streams support, allowing you to do nearly every socket operation, including creation of servers from PHP without any external dependencies.

5) Over 100+ (conservative estimate) bug fixes over the code found in 4.4

6) Many more things I've probably missed.

Dries Buytaert on :

My point was that people who need to upgrade don't care about reasons 2 to 5. These people are not developers but website owners. The only reason that appeals to website owners is reason #1 (improved performance). Any other reasons that might appeal to them?

I did a PHP4 vs PHP5 comparison a while ago (http://buytaert.net/drupal-webserver-configurations-compared) and found that PHP4 was faster than PHP5. I'll benchmark Drupal with the latest version of PHP4 and the latest version of PHP5 to find out if that changed. If PHP5 is faster than PHP4, I have case to convince people to make the switch.

If it is not, website owners still have no reason to upgrade. Make sure to target the right users. The answers you provided missed my point almost entirely.

Ilia Alshanetsky on :

Well, what do ISPs care about?

In my experience, its the 3 S, Speed, Security and Stability. And PHP 5.2 is better then 4.X in Speed and Stability aspects.

Arnaud on :

Wouldn't Drupal developers (and not websites owners) be interested in all those features ?

Larry Garfield on :

Sure we would. I'd love to be able to use PHP 5's new functions, or integrate a query builder into Drupal that uses PHP 5's OO features. But the web host I use has PHP 4.3. The web host we use at work is so old that they're still on PHP 4.3 and MySQL 4.0 (RH 9). Until that changes, I can't do that or I wouldn't be able to run Drupal anywhere but my home server.

The bright side is that the boss said at a meeting recently that if our host doesn't move to PHP 5 soon, we're dumping them. I'm overjoyed at that idea, personally.

But not many companies are saying that, so there's no pressure on shared hosts to upgrade, so they don't.

Ilia Alshanetsky on :

If your host is still using PHP 4.3 you need to encourage them to upgrade asap, as this version has countless security holes many of which are over a year old. By running such an antiquated version of PHP the host is putting your site/app at risk.

IMO any hoster running anything less then 4.4.0 is doing a disservice to their users.

Rob... on :

Which begs the question:

why aren't these points plastered all over the PHP.net home page?

I bet 90% of all PHP4 users still believe that PHP 5.2 is no different from 5.0 and think that PHP5 is slow and impossible to migrate to without a rewrite.

Regards,

Rob...

Ilia Alshanetsky on :

They are posted in the release announcement linked from the front page

Rob... on :

The 5.2.0 release announcement really isn't what I'd call a "sales pitch" for php4 users

Regards,

Rob..

David on :

Completely agree with this post, I personally have not moved towards PHP5 because I see no benefit to do so with the current apps that I write. If there was a substantial gain from upgrading as there was with 3 to 4 then I would definitely consider it but I think a majority of PHP coders see PHP5 as just a new version with a few bells and whistles but nothing really much to make you want to recode all your current apps to 5. If it isn't broke don't fix it.

Jan on :

The Job has a large codebase written for PHP 3 and 4 and we simply do not have the resources to migrate to PHP 5. Frankly, we just have no need to do so.

For my projects I use PHP 5 quite exclusively because a lot of the common stuff is easier (e.g. why has file_put_contents() not been backported (despite the bugfix-only policy)).

Still, thanks to everybody involved for maintaining and improving PHP!

Best,
Jan
--

Ilia Alshanetsky on :

PHP 4 is basically in low maintenance mode with very few developers even looking at it. The only things going into it are security fixes are critical bug fixes. Even that may go away once the current maintainer Derick Rethans loses interest

Tim Stiles on :

As co-organizer of a local user group, I'd say it was largely fear. Most of our members are part-time or hobbyist, and most of them actually believed that PHP5 would require a complete rewrite of their code. They were wrong about that, but the available literature and articles all talked about what was new and exciting, and most of it was very alien to them. Compatibility got one or two sentences. They didn't get past that until about 5.1. Most run a linux install of their own for development while actually hosting sites on large services, so they were limited by both what the hosting provider served and by what came with their linux distro. These are not guys who roll their own PHP. They use what came on the machine/build and change it only when they have to. Again, largely out of fear.

After constantly demonstrating PHP5 to them in meetings, most are interested. We're trying to teach them that if they write for PHP5, they'll be in good shape for PHP6. If they write for PHP4, they're probably good for PHP5, but at PHP6 they may find themselves up the creek.

At this point, it's not fear of the changes in PHP, it's fear of changing their currently stable environment.

The massive change in development philosophy of PHP5 was a surprise to these folks. OOP is exotic to them. They don't follow the dev lists, and most have never actually seen any of the PHP print publications. Good presentation of future goals and plans is one of the things that has impressed me most about the Zend Framework development. Steal that idea. Set up a PHP6 introduction site NOW. Mission statement, FAQ, some interaction, played down emphasis on new features this early in the game (You don't want people to hold out for PHP6). Keep the site current with the development. Post the dev lists in an archive for those who are interested. Get all of your talking points about the goals and purposes of the PHP6 upgrade ready now and shout it to the heavens. And make it absolutely clear that PHP5 is the bridge to get to PHP6.

The PHP4 to PHP5 changeover has been a labor dispute. PHP5 to PHP6 should be much the same. But a PHP4 to PHP6 changeover is gonna be a holy war if you don't manage the fear.

jim on :

PHP5.2 is faster than PHP4 , but what is the result about (PHP5.2 + ??) vs. (PHP4 + eAccelerator) ?

Ilia Alshanetsky on :

Why not compare apples to apples, such as PHP 5.2 with eacclerator vs PHP 4 with eaccelerator. Or you can use APC cache with PHP 5.

Edin Kadribasic on :

Because APC is nowhere near as stable as mmcache was for php4?

Ilia Alshanetsky on :

Heh, I guess it depends on the code, APC (unfortunately) is rather picky about the kind of code it likes to work with. But that pickyness comes at a cost to stability.
That said, latest CVS version seem to work fairly consistently.

Mike Willbanks on :

Essentially many people are not upgrading because they are on RPM versions of the PHP version that comes from their *nix distribution.

I think this is most of the reason why. One of the reasons that the firm I was working at waited so long was that we couldn't put 100+ websites at risk and didn't have the time to check each one on a different server and then make the move due to possible losses in our current production schedule.

However that all changed when they had a server crash... However, 4 or 5 sites out of 110 didn't come back up and it was simple things such as rewriting some XML parsers and fixing a broken script that redefined variables.

Gary Cornelisse on :

In 1992 I worked for a Fortune 500 company that were putting a new IBM PC w/ OS/2 at everyone's desk and removing the old green-screen terminals. I was in charge of a portion of the mid-town Manhattan office, and it was my responsibility to welcome the employees back on Monday morning with their new high-tech PC's. I've never seen so much panic and anger over someone putting the latest and greatest in front of them. I had one older gentleman that was on the verge of profanity, and had some not so kind words for me. He claimed he had no idea how was going to be able to do his work no matter how many times I showed him how to get his terminal screen back.

I suspect the same reaction is in some way similar to the PHP4 to PHP5 debate. Many feel if it ain’t broken, don’t fix it. It’s a tool, an instrument for doing business. And, if you mess that ability to earn the almighty dollar, better watch out.

Having said that, I really enjoy the features of PHP5. My company has been releasing all of its’ web applications on PHP5 since the first point release. We didn’t have any upgrade issues at all. As a web developer, I believe I can do things in a way that is more elegant and efficient than before. Particularly with the new OO. I can’t wait until PHP6. We had a similar debate on my blog, with many of the same responses.

Robert Mibus on :

We run a mixture. PHP5 runs on the most loaded servers, since they're running external PHP5-capable code, or newer code that we've tested thoroughly on PHP5.

The PHP4 servers we haven't upgraded because we have a lot of legacy scripts we haven't tested, and just don't have time to. Some of the stuff I've tested I know has issues - mostly just the pass-by-value/reference change.

I'll be happy when we move to PHP5, but I need quite some free time to test everything satisfactorily (given how much of the older code deals with e-commerce payments!)

David Arthur on :

Personally, Red Hat only support PHP 4, when Red Hat 5 is released in the next few months we'll have an enterprise version of linux supporting PHP 5.1. Same goes with CentOS obviously...

Ilia Alshanetsky on :

I think Redhat should definitely consider 5.2.0 or 5.2.1 (which should be out by then). Using 5.1 will really be a disservice to your users given a much more stable & secure release is available.

Nico on :

By the time PHP 4.2 came out many hosters still required you to write .php4 to use PHP 4 - .php was used for PHP 3.

Now here's the problem. It's not that easy to run PHP 4 and 5 with the same server or admins don't know enough about it. Maybe a different mime-type for each new major version would help adoption, because it doesn't make you think how to run both modules at the same time with the same webserver.

Chris on :

The lack of a compelling reason to upgrade for distributable apps.

What I mean is there is nothing in PHP v5 that makes major applications like phpbb, vbulletin, lots of CMS etc decide they want to go PHP 5 only. Thus they continue to make their code work on PHP4.

This follows through to hosting providers who do not upgrade to PHP 5 because it will a) break some things and b) the major distributable apps work on PHP 4 anyway.

If you want to get a new version of PHP adopted, there needs to be a reason for distributable apps to break backwards compatability with older versions. Unicode may well do this in PHP 6, but PHP 5 didn't really have any necessary feature even if it has lots of great features.

There is an element of chicken/egg here and of course for sites starting from fresh or using in house code, PHP 5 is a no brainer - but it seems rather clear to me why PHP 4 is still so much more prevalent.

Ilia Alshanetsky on :

As an author of a fairly big & popular distributable app, FUDforum, written in PHP I can tell you that there are a number of advantages to upgrading.

One of which is that PHP 5 includes many functions that can eliminate whole chunks of PHP code, making applications faster and simpler. Another is the number of bug fixes which you had to write work-arounds in earlier versions.

John on :

I'm still using PHP 4 and don't have any great desire to upgrade. I'm an intermediate level PHP programmer and it concerns me that after upgrading I might have to go and try to fix a bunch of scripts.

I also manage several Linux servers and have 18 customers that host their websites with me. I don't have the time to help these people fix problems that might arise with the upgrade.

I guess it's just easier and safer to stick with what works. Unless I'm assured that my code will continue to work or there is a huge security risk and upgrading to 5 is the only way to plug the security hole, I think I'm sticking with what I know best. It's comfortable.

Anonymous on :

PHP5 is not as PHP4 compatible as claimed.

Among the gothchas encountered are the array functions.

Ilia Alshanetsky on :

Can you be more specific?

Aaron Wormus on :

I've upgraded a fair amount of systems and array_merge() not taking a string as the first parameter can be a bit annoying.

Elliot Anderson on :

It really isn't that hard to fix. I got a large e-commerce app written in PHP 3 and 4 working on a PHP5 dev box in under 20 minutes, mostly changing array functions to cast the input before use like so:

array_merge ( $source, (array) $addition );

Ilia Alshanetsky on :

I really don't think the issue as as serious as you make it to be. First of all you are relying on un-intended behavior, secondly array_merge() rather uncommonly used function. If we take Google's code search results as a baseline, only 400 results are found. In contrast array array function sort() is found 22,000 times.

Anonymous on :

array_merge() is a rather uncommonly used function? This cannot be right. I think it is probably one of the most used array functions.

Ivo Jansch on :

I concur; I also had to fix several array_merge issues during migrations.

Taras on :

We develop our software using PHP4 because of it used by hosting providers and must work correctly on all versions of PHP. So it will be great that providers migrate to PHP5. In my projects (not for work) I always use PHP5.

Jim Plush on :

array_merge used to take strings, now chokes if both values are not arrays. That's a big one off the top of the head.

anyway, bottom line is if you're developer you're using php5, if you're a scripter you could care less. If applicants can't answer php5 questions I cannot take them seriously.

Edward W on :

Who is kidding whom, here?

Python and Java were performing and stable well before PHP was a candle, let alone a star. PHP is and has always been a scripting language. Programmers (what you consider 'developers') use programming languages. If you call yourself a programmer and use PHP 4 or 5, you are a hack and I cannot respect scripters who cannot live in reality.

Those, such as myself, who have not upgraded to PHP5 do so for the exact reason so many PHP5 users say "PHP 5.2 was the first truly fast and stable release". IN THREE YEARS a stable and 'as fast' PHP5 finally emerges and you consider those who adopted PHP5 years ago the cream of the crop? That, my blind friend, is why they call new releases 'bleeding edge'. Using it only creates problems.

Install PHP 5.0 on an extreme traffic site and see what happens. And you wonder why the adoption has been so slow?

Maybe you should start asking MS Vista specific questions to your interviewees. After all, so many large companies are just lining up for bleeding edge technology. *shakes head*

Aaron Wormus on :

Here's a big one:

Cpanel doesn't support it yet.

I've got 2 Cpanel servers, one running the standard build (PHP4.4.x/MySQL4.1) and the other running the alpha build (PHP5, MySQL5, Apache2.2) and the PHP5 server is far from stable enough to be put out as a standard release.

Now I know that you can configure cPanel to run PHP5, but most hosts just run with the standard builds and upgrades.

If we could get php5 into a standard cPanel build (or at least make it simple for the end user to choose), then I'm sure we'll see a nice jump in the stats.

Why do I keep a PHP4 server around? It works, it's supported, I've got a crapload of old/client code which I'm not likely to look at again. If I have to do any non-trivial work on old code I move it over to a PHP5 machine, but there is a lot of code which I doubt will ever see PHP5.

Ilia Alshanetsky on :

Does cPanel break if you replace libphp4.so with libphp5.so (even faking the filename via a symlink) ?

Aaron Wormus on :

I know you can make PHP5 work with cpanel.

The thing is, hosts who are into tweaking configurations are probably not using cPanel, it's just the ones who are rolling out a ton on easily managed servers or virtual hosting. Which probably doesn't make for that many servers, but makes for a HUGE number of individual sites which are hosted at low cost hosting places.

Tom Sommer on :

Let's see, I run a server park with around 30 linux servers, and there is one single reason why I don't upgrade my old PHP4 servers... compatibility.

If I break just 5% of my customer's websites, I'm gonna have a support nightmare on my hands. These are customers who might just have downloaded osCommerce, phpBB, a simple CMS system, made their own website with shitty code that "just works" - if that breaks, what do I tell them? "Yea, we had to upgrade, so you have to fix your site, have fun"... Doesn't work.

All new servers are installed with PHP5 though - upgrading to PHP6? No chance in hell with the major BC breaks in that.

Scott MacVicar on :

What about running PHP 5 and PHP 4 in parallel so you can provide users with the ability to use both on a per virtualhost / directory basis?

I really thing that running both is a solution and would encourage more people to make the switch.

Tom Sommer on :

I would, but I'd need some decent documentation, and I'm a bit scared about running two PHP modules at the same time, past experiences haven't been good in performance and setup.

That said, I would still have to run PHP4, and my customers would still use PHP4 - so what's the point?

Scott MacVicar on :

They don't even have the option at all just now so they'll never make the upgrade until they're forced to.

I know a hosting company that runs both based on extensions, .php5 and .php4 respectively. .php is set on a per virtual host basis so you can pick your default version.

If that was the case the developers could write new code for PHP 5 in the safety that they'll be able to run it on the majority of hosts since they support both versions.

Ilia Alshanetsky on :

FastCGI is the answer, if you say it is complex in Apache (something I am somewhat inclined to agree with) consider lighttpd, which is better in many ways.

It is faster (always good for hosters), easy to configure (even with fastcgi) and can scale like Apache does not even dream to.

Tom Sommer on :

Sure, but that still doesn't solve the fact that the core of the problem is compatibility

Cristian Rodriguez on :

Yes, the real problem is backward compatibility, according to my experience, there is no such thing as 99% of compatibilty.

Arg on :

I think one of the reasons that many ISP use PHP4 instead of PHP5 is also the quality of the PHP 5.0 series. Everybody knew that it lacks of quality and was more a public beta then a application for productional use.

Of course this changed with 5.1 and with 5.2 but the people remember the 5.0 series and may wait until other use PHP 5 and the image of the PHP 5 will grow. So most people still believe PHP 4 is more "stable" than PHP 5.x as a result of the release management for 5.0

Ilia Alshanetsky on :

Yes, that is an unfortunate stigma for PHP 5, which IMO only became usable in 5.1 and production quality by 5.1.2 or so.

That said 4.4.X is a dead-end branch it is maintained for now, but releases are far and few in between. I very much doubt you'll see support of this branch past 2007. So, regardless of the upgrade pains people need to start thinking about upgrading.

Damien Seguy on :

For those of you who do not understand French, the articles are translated :

http://www.nexen.net/chiffres_cles/phpversion/php_stats_evolution_for_november_2006.php

http://www.nexen.net/chiffres_cles/phpversion/php_statistics_for_novembre_2006.php

Quelquun on :

Because the official mirrors Debian does not propose the extensions special of php5 (php-pdo-mysql for example).
Why use PHP5 without innovations ?

Create applications to use the latest technology of PHP5, but can will have the extensions. => only develop for PHP4, without extensions. PHP4 is enough.

I like more pre-compiled extensions for PHP5, for Debian, Ubuntu and others.

Much like me, prefers to use apt-get install php5 (and extensions), for easy maintenance.

Robert on :

I can assure you when RHEL supports PHP 5 we will be there, enjoying the convenience of outsourcing security upgrades and bugfixes for us in our enterprise at a nominal cost so we can focus on development, not recompiling PHP. I am amazed that this single factor has, like a white elephant in the middle of the room, been ignored as the driver for lack of adoption. Perhaps the PHP community is comprised of too many well-intentioned developers and too few software salesmen to realize that market forces like these vastly outweigh how good or bad a language might have matured into being. It's about distribution, silly. Just like in the print publishing world. No-one will read your book without good distribution channels, no matter how well you wrote it.

Alexander on :

I have been playing with the idea to upgrade my Debian 3.1 based-systems with PHP 5.2 (using the dotdeb distribution).

One thing I like to see before I upgrade from 4.4x to 5.2x is a comparison in MEMORY USAGE. Most of the sites I host are PHP-based - so I am afraid that upgrading to the 5.2-branch will introduce a considerable increase in required memory for me.

Please prove me wrong

Ilia Alshanetsky on :

The reason you see an increase in the memory usage is because 5.2 memory manager does not forget to count certain allocations. Therefor the memory usage shown in PHP is higher, although if you look at the system stats the amount of physical memory used is less.

Alexander on :

Thanks for your thorough explanation, Ilia. So in other words, upgrading to 5.2x does not necessarily mean I have to upgrade memory... this is good news for me!

Ilia Alshanetsky on :

That is correct, you may need to increase the default memory in PHP a bit, but in terms of physical memory utilization you'll be using less.

zhaiduo on :

I know PHP5 have many new great features, but currently my PHP4 functions and classes are good enough to handle all my works. Another way, upgrade server is out of my control.

Anonymous on :

Zend has to keep putting out stuff like Zend Core with all extensions on all OSes, that'll speed adoption. Please include FreeTDS mssqlserver extension and ODBC extensions.

Zend Framework (supposed to be a PHP5 magnet) has to be more compelling. It would have to be as flexible and powerful enough generate business forms like Achievo toolkit. It also needs compelling ajax capability that's integrated with the data binding.

Therefore ZF needs to integrate ATK and Dojo. Lucene is good, improve it. Why did ZF put out a problematic release like 0.2?

ZF not focused on things that matter. Like, enough with the controller already, enough about rails, can it generate my business forms with 200 widgets etc?

That said, clearly say in ZF what features of PHP5 make it require PHP5? What can you do in ZF because of PHP5?

Isn't there some security points about PHP5 you can make?

The sooner PHP5 succeeds in the enterprise the sooner I am no longer downstream from java programmers.

Matthew Ratzloff on :

Zend Framework is a pre-alpha release. It's not going to be feature complete until 1.0, and even then, there will be plenty of room for improvement.

Until core components like the MVC architecture (0.6, coming this month), localization (0.7), and database access (0.

are complete, form generation and Ajax should not be the focus. However, those are the flashy things that will attract developers, and they definitely have a place after the foundation is laid with 1.0. However, there is nothing preventing you from using Dojo, Script.aculo.us, YUI, etc. as is.

The stated purpose of Zend Framework is to drive the enterprise to PHP 5 by creating a compelling reason to switch. Saying it should be backwards-compatible with an outdated version of PHP is getting away from the entire point of the project.

Finally, there are plenty of security improvements in PHP 5--look at php.net. Even PHP 5.2 is recommended over 5.1.4 due to a critical security issue in previous versions.

Olaf Lederer on :

Hello,

I'm still writing classes with the spare class features of PHP4

But since more then a year I develop them on a PHP5 server to take the next step.

People are using PHP because its very easy to learn (maybe to easy

), but the new (and better) way to use classes in PHP5 is much more complicated for the users of PHP4.

Before new project I plan to use the class features of PHP5 but at the project begin there is not enough time to use something new. I think that's the reason why a lot of people still using PHP4. But I think there is no problem to develop applications for version 4 on a PHP5 machine.

On the other site there are a lot of shared hosting companies which doesn't offer the latest PHP version (yesterday I tried to run an application on the shared account from a customer with php 4.12 and mysql 3.23.58)

Mike Y on :

I started developing websites a couple of years ago, so I therefore decided to adopt PHP5. However this turned out to be a nightmare because there were hardly any choices to decent PHP5 hosts.

I have recently ported to a hosting company that supports php5 using the line
AddType application/x-httpd-php5cgi .php
in the .htaccess file.

However when I ported my PHP5 code over relative pathing for includes just dies. So I will have to go through and change ALL the includes.

My other choice is to port to PHP4 and not be able to use the autoload of PHP5 which has been a god send for not needing to use includes for objects.

In hindsight I wouldn't have touched PHP5 with a barge pole, even though I love it as a programming language, hosting companies that do PHP5 are often over-priced or useless.

The .htaccess PHP5 hack my latest host uses is dreadful, it has given me a nightmare of a port from 4 to 5!

Carlos Devia on :

Only now i'm thinking in the transfer of our servers, and it was only because me like developer and some customers are needing some features only available in PHP5. Of course i came to this post searching if the change would not affect the perfomance of the server. I just found that the latest version have good responses, the hard thing now is notify of the change to the customers and help them resolve posible problems with their web sites.

linen on :

Okay, I'm fully prepared to offer my reasoning for not switching. Some of my reasons make sense and some of them do not. I heard that PHP 5 has a lot of new features. While these features make things easier in the long run, I still have to take the time out of my already horrendously busy schedule to learn how to use those new features. How can you expect me to want to do that? Other than that, I'm just too busy to go through the whole upgrading process. Cost is another issue. I also just don't feel the need. I've learned to navigate around the bugs in PHP4 and now I'm comfortable with the program now. I can't even begin to describe how much I just don't want to migrate everything into a new program even if it's going to make things easier in the long run. I just don't have the time or the desire when there's so many things that could go wrong.

Mike on :

It's sad to see people still using PHP 4. PHP 5 has been out for a pure 3 years now, and im so glad the end of life of PHP4 is the end of this year.

The better support for objects, and the flexability and functionality of classes are what should appeal to all PHP programmers. It's the future. Now, i am using the SVN version of PHP 6. PHP4 is the way of the past, and people are just too lazy to either upgrade it, which just takes a second, or learn the new methods and all that PHP5 has to offer.

My host, Site 5 is dreadful. They use the horrible .htaccess hack to change the mime-type of the .php extension. This is sad. If anything, a hosting package with PHP5 should be cheaper, as it handles memory better, and it uses less resources, but is still faster.

This is going to force us true PHP Developers to code in only PHP5 to manually and forcefully migrate the industry to use PHP5, finally.

Adam on :

Does anyone have info on how to run both php 4 and php five in parallel on red hat? Also, after you do this, how do you refer one program back to use php 4? Is this done in the apache conf file? Again, how is this done.

Thank you much!

Adam

Framed Art paintings on :

Mike is right. Most people are just too lazy to update or switch to the latest. We can not blame these people. They are too busy to update. It might eat much of their time to switch to the latest version. Besides, most of the time when you are already used to something it will be hard for you to get used to using something new.

steve on :

I would agree that alot has to do with the PHP version that is running on shared hosting providers which are usually slower to upgrade.

iBlog - Ilia Alshanetsky

Monday, December 11. 2006

Why are you not using PHP 5?

ATK rules... on : PHP4 vs PHP5 - a summary