People are getting increasingly worried about PHP5's adoption rate. And rightly so. PHP5 has been released more than two years ago. If you look at the adoption rate in the graph below, you see that after more than two years, PHP5 commands for less than 20% of PHP's install base. With the current adoption rate (even if it is assumed to be exponential), PHP6 is dead before it is even born.

Php5 adoption rate
PHP5's adoption rate based on data from Nexen.
Php5 naive forecast
A naive forecast of PHP5's adoption rate. As the major Linux distributions (RedHat, Debian and Ubuntu) started shipping PHP5 recently, I was optimistic and assumed PHP5's growth to be exponential. Based on data from Nexen.

As Nick Lewis pointed out: PHP is dying, and if we don't migrate to PHP5, the Drupal project will die along with the PHP project. It won't happen overnight, but it might happen several years down the road ... The point? Drupal's success depends on that of PHP.

Part of the problem is that the PHP team has their target audience wrong. If they want to drive PHP5's adoption, they need to make PHP5 attractive to ISPs and end-users, and focus less on application developers.

Many websites use a content management system, a forum or a blog tool and these systems work with both PHP4 and PHP5. And for a long time, they've 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 Drupal works well.

Isn't the Drupal team interested in using PHP5's new functionality? Sure we are. We'd love nothing more than to drop PHP4 support and to use PHP5's new functions. Unfortunately, we are dependent on our users too, and these users don't care about better OOP support, SimpleXML, PDO, DOM, etc. The only things they care about are performance, stability, compatibility and security.

If the PHP team would show that existing applications run faster by upgrading from PHP4 to PHP5, ISPs and end-users would have a strong incentive to upgrade. However, last time I checked, PHP5 was slower than PHP4. For anonymous users, Drupal is 13% slower with PHP5 than with PHP4. For authenticated users, this difference is only 4%. In other words, this gives them a good reason not to upgrade to PHP5.

If the PHP team would show that PHP5 is more stable than PHP4, people might start to care. Unfortunately, PHP 5.0 was rather buggy and less compatible than hoped for. Even today, PHP5.x+APC feels less stable than PHP4.4+APC.

Anyway, it is all about targeting the right users, and giving them a compelling reason to upgrade. Convince the ISPs and the applications' users to upgrade, not only the application developers. It would help us break out of this chicken-and-egg problem.

That said, the Drupal project can't just stand here and watch. Drupal's success depends on that of PHP, and PHP5's slow adoption rate is becoming annoying. So let us help the PHP project by giving Drupal users a compelling reason to upgrade to PHP5:

With every Drupal release, let us make some of the new (non-critical) features PHP5-only, and gradually drop support for PHP4.

For example, let us start with making the module update notification feature, scheduled for inclusion in Drupal 6, depend on PHP5's SimpleXML parser. It is likely to upset some of our users and developers, but by giving back to the PHP project we help serve a bigger cause. After all, we really want PHP to shine.

And if projects like Wordpress, Joomla!, Typo3, phpBB, Gallery and phpMyAdmin would do the same (if not already), we can help drive PHP5's adoption before it might be too late ...


ben_ (not verified):

As mentioned in the Drupal-Forum: our brand new Drupal Installation runs under PHP5.1 without any problems. And as our Main-CMS is extremely XML-centered, we even developed a Module using SimpleXML and thus only running under PHP5.

Gerhard Killesreiter (not verified):

I agree with introducing small features that are php5-only, but I disagree doing this for the "module update" security function.

Chris Johnson (not verified):

I am in agreement with Gerhard on this issue.

Mohammed Sameer (not verified):

Well, I'm using php4 because I'm running my own VPS powered by Debian stable. I won't think about moving to php5 before Debian drops 4 from stable.

I care about speed. I'll serve more requests with my limited VPS resources if the application runs faster.

I also use Drupal because it doesn't consume a lot of resources.

Now consider a large website serving more requests. 11% will really affect it.

Let me say it, php is crap. I'm only running php because I trust the guys behind Drupal, it has a good security record, it doesn't consume a lot of resources and because it makes my life easier when it comes to customization.

What will I do if you start making optional features dependent on php5? I'll simply ignore them or write php4 compatible modules implementing these feature if I really care about them.

What will I do if you start making core features depending on php5 ? I don't know. I might decide to upgrade but I might also search for a Drupal alternative (I hate that but I can't afford a better VPS and I don't like shared hosting). It just depends on the performance.

Why don't I upgrade to php5? I don't know. php4 is playing fine.

I'm not ranting. I'm just stating my point of view which might be the same for a lot of users. I don't know. :)


Gábor Hojtsy (not verified):

It might be misleading in this context, that Dries compared Drupal *as-is* on PHP 4 and PHP 5, and the later was found slower. Seems like Drupal unchanged runs slower on PHP 5. The point of going forward with PHP 5 is to use more built-in features of the system (eg. PDO), which we need to implement ourselfs now. So while Drupal might be slower on PHP 5 now, the goal as far as I see is to make use of new areas in PHP 5, so we can make Drupal more performant (and as a side effect even more pleasurable to develop with) at the end.

Mohammed Sameer (not verified):

If Drupal unchanged runs slower then php5 has problems.

The speed should be the same because it's the same code. Using more php5 built-in functions will make it faster but still, will it be faster than php4?

I'm not saying that we should stick to php4 but I still don't know what should be done!

Maybe we can use some php5 built-ins but keep the current php4 code? Just like what we did with the mbstring extension? Use it if it's there otherwise use pure php code.

Itkovian (not verified):

I think you are making some good points. However, if Drupal's (and other PHP-based platforms') survival depends on PHP, I can think of two issues with driving towards PHP5.

First of all, what if the users decide not to follow suit? If they really want to stick with PHP4, they will miss out on new Drupal versions. Perhaps the users will not be at fault here, but the ISPs could be, if they refuse to deploy PHP5. Or perhaps PHP6 after that? I think that including PHPx-only can be a gamble. Can it not be that PHP4 is mature enough? I think that the more mature a language, the longer the development cycle will take to get to the next level.

Second, what if PHP development stops? Will you let Drupal die because of that, or will you move it to another language or keep developing on older PHP versions? After all, a language is nothing but a tool, a means to an end. Obviously, changing this tool is not easy, ever. But if it needs to be done, it can be done.

Anonymous (not verified):

I think it would also be worthwhile to compile a list of popular web hosts that offer PHP5 or how to get PHP5 on those popular hosts.

I know Dreamhost already offers PHP 5. A wiki somewhere would be a nice start.

michael schurter (not verified):

Any chance of porting Drupal to Python? ;)

In all seriousness Drupal is the only reason I touch PHP anymore. I'm picking up Python for future projects, but there's still no replacing Drupal.

My guess is that PHP pretty much owes its continued popularity to the few exceedingly popular apps that use it: Drupal, WordPress, phpMySQL, etc. People use the apps and end up learning PHP when customizing/theming them. To my knowledge no popular PHP app requires PHP5, so new PHP users probably aren't even aware of 5 or the differences. New users are constantly being introduced to deprecated technology.

Khalid -- 2bits (not verified):

Any chance of porting Drupal to Python? ;)

I know you are kidding, but this is an idea that I have been thinking about more and more for a couple of months. Even talked to a few people about it.

I am sick of the attacks on PHP, the versions of PHP, ...etc. Personally, I have no serious issues with PHP. It is a flexible language, geared for the web, but not among the best designed ones.

Drupal is a great framework and CMS. If it is was to be decoupled from PHP, it will go to other levels (the stigma of PHP, command line execution, possibly better performance, attractive to Python folk, ...etc.), but also will face challenges (dearth of hosting, limited to VPS and dedicated, no contrib modules, no themes, ...etc.).

It is a lot of work, maybe impossible. But one will not know until one tries. Starting with perhaps the node system only as a proof of concept/prototype.

David Rubin (not verified):

It seems the grass is always greener...

PHP/mod_PHP was built for the web and to a large degree that is the reason for it's success. Python (my first love) has always had "problems" with the web. Python has a number of great web frameworks and does not need another IMHO. It think if there is anything I'd like to port to Python it is the awesome Drupal community, but a lot of Drupal success can be attributed to the accessibility of PHP platform, you see how this is going...

I would recommend Ian Bicking's - Why Web Programming Matters Most, for more on this topic:

Mohammed Sameer (not verified):

One of the advantages of PHP IMHO is that it's easy to learn and I guess finding a PHP guy is easier than finding a python guy but finding a good PHP guy might be harder than a good python guy.

The Drupal patch system is somehow working around this limitation by reviewing patches.

The question would be: will the community follow a Python port or will they drop Drupal completely?

Itkovian (not verified):

I've talked to some Haskell folks in the past, and at least one person thought it was feasible to recode Drupal in Haskell. I'm not sure if he ever made an attempt, but from what I know, if that person deemed it possible, it actually can be done.

I think it would be a fun project to get the basics working on another language, but if any real effort was to be made (it could be assigned to some students as a project?), it would need support from the community. And that would mean the community needs to support two systems. I don't think this would be a good thing. Plus, as we all know, it is all too easy to drop down to the level of language flamewars.

Gerhard Killesreiter (not verified):

Well, I'd definitely be interested in a Haskell port. Mainly because it was my standard suggestion when somebody suggested to recode Drupal in OO-PHP. I don't have any clue about Haskell (yet).

Michael Schurter (not verified):

I think CherryPy would be perfect foundation for a Pythonic Drupal.

Genshi might work well for themes/templating as you can insert variables easily like Drupal/PHP, and you can even go nuts by inserting blocks of Python code which should make PHP refugees happy.

My big question would you attempt the insane task of making PyDrupal compatible with PHPDrupal's database? Migration would be much easier that way, but it may be an insurmountable amount of work.

To the poster who said Python doesn't need another web framework: You're absolutely right, but it desperately needs a CMS! And Drupal is the best. ;)

If anyone's serious about this, e-mail me.

sime (not verified):

Some file based caching, or memcache, in core?

A large proportion of shared server users would benefit from this feature, since mysql is often the bottle-neck for sites on shared servers. Users would then apply bottom-up pressure to hosting companies. Many hosting companies (like mine) allow moves to php5 servers because many are running WHM and it's a no-brainer really.

The performance loss of php5 would offset the performance gain of more flexible caching (or at least this is what I've gathered reading about projects like memcache and boost).

I guess you'd have to use some php5-only functions to make it php5 only (sounds a bit dodgy I admit).

Titanas (not verified):

Lots of hosts run their VPS and shared solutions on PHP4. In VPS stable CentOS solutions run on PHP4 and on shared solutions PHP4 updates are not an option for users. I guess providers look for stability instead of evolution and cutting edge features.

sime (not verified):

In WHM, CentOS, I go to the software page and I can upgrade and downgrade php from 4 to 5 with a few clicks.

The same host's shared package (low cost btw) offers free transfers under most conditions to a new server if you need php5. Once again, WHM offers a tool to transfer accounts at the click of a button.

I'm willing to accept your statement because I don't know the stats, but anecdotally I believe it's easy for well organised hosts to move to PHP5.

Nick Lewis (not verified):

I don't think its as simple as that. A platform's ability to provide a good experience (I assume this is what you mean by "time") depends entirely on the developers.

If we were talking about fishing instead of open source development, your argument as I understand it is: "Fish are infinitely more important than fisherman."

That kind of statement strikes me as frankly question begging.

Matt (not verified):

We're not talking about fishing.

I'm a single developer, my software is used by more people than I could possibly meet in one lifetime. It may take me a day, or even a week, longer to do something and make it backward compatible or work with older versions of browsers or PHP, however that's going to save the time of hundreds of thousands of people who don't know, understand, or care about those things. It's additional friction, and most people have a very low threshold. Some prima donna developers might go work on academic projects in haskell, but that's offset by increased popularity, which brings in more contributors.

Interestingly, 99% of my PHP annoyances lately have been things they've broken in newer versions of PHP, particularly 5.2, such as the arbitrary 100,000 PCRE backtrace limit, messing up output buffering, changing object destruction, and so on.

I see people suggesting caching and such to offset performance problems, but many large scale sites and services have already done that. Even if there is just a 5% slowdown, that means I have to order 10-15 more boxes to serve the same amount of traffic, costing 15-25k a year, not to mention increased costs going forward. It adds up.

mauror (not verified):

Well, how do you (the Drupal core developers) feel toward PHP5? The history of Drupal itself shows that when the core developers made the most elegant decision, in the end all turned out well...

Maybe you (the Drupal core developers) should do the same now...

Just a proposal: instead of relying on third-party surveys, why not a poll on People interested, and only people interested, could give a feedback ...

Drupal has been created for the sake of the Drupal community, so what is the-right-thing-to-do for the Drupal community?

Although this is not a simple question (and according to me you should pick up what is best for Drupal itself), you (Dries) are considered (even by Wikipedia) a BDFL, so you are credited with knowing which is the right-thing-to-do. Think well and do the right thing. The community will follow you...

dgtlmoon (not verified):

Zend needs to (or should be pushed) to work closer with ISPs and larger projects like Wordpress, Joomla!, Typo3, phpBB, Gallery, phpMyAdmin, Drupal etc I guess.

theborg (not verified):

The power of Drupal relies on its concept (node-centric construction) and very efficient implementation of a good structure.

The PHP language helps building a community over Drupal and this helps people make it even bigger and better.

If the solution is porting, I don't care learning a new language, if we have to move our sites to a new php5 server we will do it.


Benjamin Melançon (not verified):

Worst possible compromise, but I thought I'd throw it out here anyway...

CiviCRM has a PHP5 version and a PHP4 version (a total of four download options in fact, since they have both versions for Drupal and Joomla).

Could/should/would Drupal core, and modules that choose to, be developed in both in this way? (Does SVN, which CiviCRM uses, make this easier than CVS does?)

Then performance benefits of using PHP5-only functions could be pushed and tested, or even if many changes weren't made at first everyone who went to the download page would be thinking "my host should support the larger number!" ;-)

dude (not verified):

IMO, change for the sake of change is a bad thing. PHP4 is a great platform and coupled with APC, is the fastest and most stable, even outperforming Further, it's the easiest web development language and the one with the greatest market share on the web. I find all the FUD that its dying rather amusing. You only have to look at the XHTML's and XML's failure to see why it makes no sense to predict that PHP is dying or that PHP5 is better than PHP4.

For Drupal, there is really no need to move to PHP5. Drupal, thank god, doesn't use OOP, it doesn't need XML and I'm not sure what those other things in PHP5 are for, but I don't think they'll bring much difference to Drupal. Why do people wonder that PHP5 is still not used out there? PHP5 is slower, harder to learn and is less stable than PHP4. No surprise that ISPs stay away from it. PHP4 works, and admirably well.

I understand that as Drupal's core developers you have the final say in this matter, but I think that porting Drupal to PHP5 would be the real end for Drupal. Forcing users to upgrade for the sake of upgrading is wrong and doesn't work unless you have monopoly. Users will just use the old Drupal versions or move to Joomla. Drupal is the fastest growing PHP CMS out there so making such changes will be counter productive.

Instead of moving to PHP5, or even worse moving to Python (Python is slow and hard to learn, Plone anyone?) or other exotic languages, Drupal should concentrate on security, stability, performance and user friendliness.

Larry Garfield (not verified):

@dude: Drupal doesn't use OOP right now because PHP 4 OOP sucks. There's a lot that PHP 5 could offer, though, if we were able to use it.

* PDO. I'm working on this. :-) All of the SQL injection escaping happens for you automatically. That's good for security, and should be good for performance.

* SPL. SPL lets you do a lot of really cool stuff with OOP that is simply not possible in PHP 4. The rendering of the nested lists of menus, for instance, is currently all kinds ugly and unseparated. SPL would allow a small but very flexible way to separate the structural and presentational logic and make it more themable. It would make file handling much cleaner, etc.

* More array handling. Let's face it, Drupal lives and dies by PHP arrays these days. PHP 5 adds over a half dozen additional array manipulation functions, some of which Drupal has already reimplemented to some extent because they're so useful. Better array handling == good.

* XML handling. If you do anything with web services, you're doing XML. And if you're doing XML, you want PHP 5. Full stop, do not pass go, do not collect $200. PHP 4's XML handling is horrid, while PHP 5's is very simple and elegant.

Saying that Drupal doesn't use any PHP 5 features now and therefore doesn't need to move to PHP 5 is circular logic. We want to use PHP 5 features. Please let us use PHP 5 features! PHP 5 is, supposedly, faster when using PHP 5-centric functionality (particularly OO). We won't be able to leverage that until we make the switch.

I have posted other thoughts, too, although the Planet doesn't seem to have picked them up for some reason.

dude (not verified):


The reason I'm saying that Drupal shouldn't move to PHP5 is because right now, for whatever reasons, PHP4 is a better platform than PHP5. PHP4 is faster, more stable, uses less resources, is better documented and has thousands of free scripts written for it. Sure, PHP5 might be more secure, but any good programmer who is aware of security pitfalls in PHP4 can make sure that an application avoids these. Further, Zend continues to update and fix potential security holes in PHP4.

From the other benefits you mentioned the only interesting one, at least to me, is PDO. However, from your own tests it performs slightly faster than the wrapped db functions and I don't think many would want to run Drupal with the MSSQL server. They'd be better of using in that case.

All the other benefits you listed, can be replicated by a free script or already exist as free functions. Sure, it might be a bit faster to use these from C, but I suspect the difference will be negligible. SimpleXML is nice but does Drupal really need XML web services? And is anyone wants to add these, they can create a PHP5 only module.

In regards to SPL, there are no tangible benefits in using OOP for Drupal. The SPL example you brought doesn't justify intoducing OOP for it. For instance, Admin_menu module is written without using OOP, and works great and is very easy to modify using any syntax highlighting editor. OOP is inherently slower than procedural programming (which would be a problem since Drupal is not the fastest CMS right now), is harder to learn and maintain. The itch to OOP everything seems strange to me. Perhaps CS education doctrine is to blame but that's another story. One might argue that OOP offers separate namespaces, but if module developers stick to Drupal's naming conventions there won't be any problems. Also, PHP 5 does not support namespaces yet.

Saying that Drupal doesn't use any PHP 5 features now and therefore doesn't need to move to PHP 5 is circular logic.

I haven't said that and it's certainly not a circular logic. If a person isn't using his laptop's DVD drive, should he upgrade to Blu-Ray? Common sense would say no.

As Drupal today is the fastest growing OSS CMS out there and one regarded as the best CMS, there is no need for such dire measures. It's better to wait till Zend releases PHP6. If it's faster, more secure than PHP4 and has worthwile features that can't be replicated with code, you'll quickly find that your users demand PHP6 features.

Steven Wittens (not verified):

For me, PHP6 is actually quite different from PHP5, as it will include full Unicode support, with a whole library of localization/internationalization APIs. I already anticipated some of this with in Drupal, so it should be relatively easy to make Drupal on PHP6 significantly more powerful and/or faster as far as Unicode and locales go.

This opens the door to better DST handling, language detection, automatic support of bidirectional text, etc. It abstracts away a lot of annoying things into nice little APIs.

The only downside is that doing i18n properly is hard work, but we should not underestimate the market for products that boast complete i18n support with sugar on top. Large international organizations often have strict requirements for this.

I will certainly be writing patches for PHP6 compatibility as soon as it arrives, and I think the situation with that version could be quite different.

Mauwolf (not verified):

If we will go ahead, we must abandon the old stuff: cease totally the use of PHP 4, and use only PHP 5 and then PHP 6!!

People ho like vintage software don't need new versions of Drupal: they can use older versions of Drupal without any problem.

David Latapie (not verified):

“And if projects like Wordpress, Joomla!, Typo3, phpBB, Gallery and phpMyAdmin would do the same (if not already), we can help drive PHP5's adoption before it might be too late…”

Dotclear 2 and Habari teams decided to require PHP5. A step in the good direction (the former is commonly used in France, the latter is still at alpha stage

Stacy (not verified):

After reading the comments and completely convinced that quite a few of you missed the mark. The reason that this is important has very little to do with PHP specifically. It has to do with an ability for Drupal to continue to grow as a platform. If we limit ourselves to PHP4 then we are also limited by what it doesn't have. This becomes even more apparent when others are utilizing what PHP5 does offer and we are not.

Firstly the main key here is that if we started to use native PHP5 functions we would speed the system up. I don't know if it would be the same as it is today using PHP4, but nonetheless you can look at the fact that it is slower right now and just say it is an apples to apples comparison. The newly added functionality could very well increase the speed of the entire architecture.

Secondly by taking the bull by the horns now we set the tone that Drupal is always considering the future of what it need to continue to be successful. The thing about the web is that it is much bigger then us, and hopefully bigger then Microsoft or Google. If we don't help our choosen a platform to be successful, and it dies, we die with it. ( or at least for a time until it is ported)

Lastly I agree that PHP4 has a much easier learning curve, but the reason for moving to OOP isn't about easy or speed really. It has more to do with structure. Drupal has a very good file structure, but could use the ability of segmenting with Private and Public amongst other niceties

Just my thoughts..


Brian K (not verified):

I am not a developer, can't write PHP, but I am not worried as I know someone will write a module that is so cool, and needs PHP5, and everyone will want it, etc etc etc.

Is this too simple of a scenario?


Dewi Morgan (not verified):

Hopefully the project should fix this: new versions of Drupal and many more applications will no longer be PHP4 compatible after Feb 5 2008.

That plus the announced EoL of PHP4: there'll be no PHP4 updates after 1/1/08 and no security updates after 8/8/08.

This should be the last year we have to worry about backwards compatibility with the PHP4 dead horse.

Christophe D (not verified):

The same thing happened to ColdFusion.

Cold Fusion was fast and lean up to version 5. Then Allaire was purchased (read: sold out) by Macromedia (then purchased by Adobe). They then decided to target the "enterprise market", where the real money is. F500 companies routinely spend x to xxx millions on a single IT project, mostly on consulting services. CF became slow, memory hungry. Today the "ColdFusion Server" is mainly a Java Enterprise Server with support for the ColdFusion syntax ... it's pityfull.

I was en early adopter of ColdFusion and this process was long and painful. ;-)

This is the problem of "successful products". When the lur of big money appears, everyone forgets how and why it all started...

I sincerely hope, we will not see this happen to PHP.

Adam (not verified):

There we go - that's what we like to see! PHP been adopted by many individuals and organisations across the globe. PHP does still have a lot of teething issues such as function naming inconsistencies and a lack of namespaces - 2 which I highly doubt they'll fix for version PHP6 due to the fact they're afraid that changing it so much will have adverse effects on its popularity.

Your friends at!

darko (not verified):

Just thought I'd add my two cents about PHP upgrades. Just installed Debian on a dev box and did an apt-get upgrade, which installed PHP5.2. Installed Drupal 5.x. Everything works great, except I can't log in to the admin. That just shouldn't happen. Reverting to PHP5.1 works fine.

Why are we bent on injecting the instability of the PHP project into the stable environment of Drupal? Yes, yes, Drupal is built on PHP, but it's like swapping out an entire car engine for a slower one that can go as fast, but only if you fill it with premium gas.

Tom (not verified):

Don't have such a grim outlook on PHP5. I mean earlier maybe but you posted this May 2007... Maybe a re-post, but PHP is not in danger by any stretch of the imagination. If you feel that it is - just move Drupal to another language. Furthermore, if you insist on working against the language and it's provisions for OOP with Drupal...again, switch to another language.

PHP IS good and I don't think it's going anywhere anytime soon. More hosts have PHP5 than Ruby or Java...especially SHARED hosts where MOST of the users of Drupal, WordPress, etc. are. Which I'm sure is why you are sticking with PHP...don't be so paranoid.

Robert Douglass (not verified):

The project ended up recruiting over 100 software projects and 200 web hosts to move forward, as of today (February 5, 2008), using PHP 5.2.x as their main PHP. This is very encouraging and I look forward to seeing the Nexen stats for PHP adoption in this time. Hopefully we did our part in accelerating things.