Go PHP 5!Drupal has long prided itself for staying ahead of the curve technologically. In order to be able to write the best quality Drupal software, Drupal developers need the best programming tools available. Today, the best PHP available is PHP 5.

PHP 5 has been deployed and tested in production environments for three years. Unfortunately, web hosts have been slow to adopt PHP 5, which has made it difficult for Drupal and many other PHP projects to fully embrace PHP 5's features.

Now a growing consortium of PHP projects have joined together and push for wider PHP 5 adoption. By all embracing PHP 5 together, the projects involved in the GoPHP 5 effort are sending a message to web hosts that it is time to embrace PHP's future.

Drupal is now part of that movement.

After much deliberation, the Drupal project is committed to the following path:

  • As of Drupal 7, changes to Drupal which use language features found exclusively in PHP 5.2 will be considered for acceptance into Drupal core.
  • This policy effectively means that Drupal 7 will be incompatible with PHP 4.

The Drupal developer community agrees that this change is best for the future of Drupal. We are excited by the potential that PHP 5 brings, and we look forward to building better software for the community.

Drupal 6 and PHP 4

The upcoming Drupal 6 and all current Drupal releases will remain PHP 4-compatible for as long as they are supported.

In Drupal 6, contributed Drupal modules and themes may declare their PHP version compatibility. Contributed modules can only be installed on systems that support the required PHP version. This change will allow developers to leverage PHP 5 features without breaking existing Drupal sites. This feature will let Drupal users evaluate the advantages of moving their sites to PHP 5.

The benefits and features of PHP 5.2

Benefits and features include the following:

  • Improved performance and a more accurate memory usage.
  • Better security through the filter extension.
  • ZIP extension for creating and editing zip files.
  • Hooks for tracking file upload progress were introduced (will let us write an accurate progress tracker for file uploads.)
  • DateTime and DateTimeZone objects with methods to manipulate date/time information.
  • SQLite has been bundled with PHP.
  • Vastly improved XML support (critical for many things, including feeds and aggregation.)
  • Real opportunities for object oriented programming.

Further reading

For more background and further reading, please see the following resources.
http://gophp5.org/
http://buytaert.net/php-is-dead-long-live-php
http://www.php.net/ChangeLog-5.php
http://lists.drupal.org/pipermail/development/2007-May/024073.html
http://lists.drupal.org/pipermail/development/2007-June/024432.html

Comments

Christefano-oldaccount’s picture

Thanks for the news, Robert.

JohnForsythe’s picture

Good news for developers, bad news for incompetent hosting companies. Yay :)

--
John Forsythe
Need reliable Drupal hosting?

derekwebb1’s picture

I know that PHP 5 is going to be much improved over the current standard so that is good, however doesn't anyone worry that rolling out new versions of Drupal so rapidly may suppress module development and what not? The thing is, it takes time to develop modules for new "Major" releases (typically) as there are new methods that have to be taken into account (For D5 it was new form systems). So, if one has a few modules that they support doesn't this kind of stuff up their time?

I am not against new developments but phasing out old platforms so rapidly would seem to stifle growth of contributed modules just a bit.

Is Drupal 6 and 7 going to be fairly compatible with Drupal 5 or are all the modules going to need a lot of patchwork?

Best regards, Derek Webb
http://makefunds.com
eCommerce made easy!

Need help? Want to help? Makefunds is there!

Post a contract offer to get competitive bids...
Post a contractor information page to get clients...
Or post your own eCommerce site software for all to use free!

mfer’s picture

Part of the drupal philosophy is no backwards compatibility. For each major new release modules need up upgrade and instructions are given as to the changes and how to upgrade.

Modules that people use or have an itch to scratch are upgraded at each major release. There is time.

Drupal does have a rather quick pace of development. To keep up on the edge of development it has to be fairly quick. New releases typically only come out every 9 months or so. This leaves time to update. And, the previous version of drupal is still supported (e.g., both drupal 4.7 and 5 are supported right now). So a drupal version is supported, typically, for a year and a half.

--
Matt
http://www.mattfarina.com

greggles’s picture

I don't see any slowdown in the rate of module development - if anything it seems to have grown. I maintain several modules and find bug-fixing and issue queue maintenance to be a bigger problem than the upgrades to a new version of Drupal.

Especially given that the excellent coder module will assist in the upgrade process for many modules, this is a non-issue in my opinion.

--
Knaddisons Denver Life | mmm Chipotle Log

--
CARD.com :)

eaton’s picture

One of the trends in Drupal development of late is a move away from 'monlithic' modules that provide lots and lots of functionality. Instead, more developers are writing very focused modules that do one or two tasks and tie into the APIs of centralized modules like Views, CCK, Panels, Actions, and so on. The result is that those central API modules need to get updated quickly, but the cloud of 'add-on' modules have less code and become easier to maintain and update...

It's a process, not a magic formula, but I think the community is evolving ways to deal with the pace of change and the large number of contrib modules.

--
Lullabot! | Eaton's blog | VotingAPI discussion

vph’s picture

If the Drupal team thinks that CCK, Views, Panels are extremely useful, these modules should be incorporated into the Core ASAP. The important reason to do that is for their documentation to get improved to be on par with the rest of the documentation of Drupal. As of now, the lack of documentation of these important modules makes it very difficult to develop add-ons for them (Views, CCK in particular).

eaton’s picture

If the Drupal team thinks that CCK, Views, Panels are extremely useful, these modules should be incorporated into the Core ASAP. The important reason to do that is for their documentation to get improved to be on par with the rest of the documentation of Drupal. As of now, the lack of documentation of these important modules makes it very difficult to develop add-ons for them (Views, CCK in particular).

That's pretty much the opposite of most of the core team's thinking. The idea is not to dump stuff into core in hopes that it will improve, but rather to work hard to improve those things until they're ready for core. :) The difficulty of adding something to core is not in copying a folder full of files and saying, 'Done!' but in building the fixes, improvements, and documentation that you currently note are missing. When those pieces are in place, it will be easier to develop plugins for them, AND they will be ready for core inclusion. :)

--
Lullabot! | Eaton's blog | VotingAPI discussion

greggles’s picture

Of course helping out to digg the story would be good:

--
Knaddisons Denver Life | mmm Chipotle Log

--
CARD.com :)

arthuran’s picture

+1
Good news ^^

-----------
arthuran.net

Bevan’s picture

litwol’s picture

Thank you for the great news! i know XML support in php5 will be a HUGE benefit to the drupal project.

Sometimes something interesting appears on http://litwol.com

harking’s picture

With the push for PHP 5.2, will the Drupal projected embrace Objects too?

Here is the dossier on the topic.

Crell’s picture

No decision has been made on which PHP 5 features Drupal will use and in what way. That will depend largely on what people go about writing. Now, however, we can at least give the concept serious consideration. There's a ton of fun stuff in PHP 5.2, though, that has nothing to do with going all-OOP. The list above is just the tip of the iceberg.

Exciting times. :-)

--
Larry Garfield
http://www.garfieldtech.com/blog
http://www.palantir.net

agentrickard’s picture

I pinged Larry first on this proposal because my MySQL admin wants to see native PDO support in Drupal, and Larry is researching it.

(Remember the Scalability seminar, Larry?)

I think Larry's being modest; he's done a ton of great work.

--
http://ken.blufftontoday.com/
http://new.savannahnow.com/user/2
Search first, ask good questions later.

Crell’s picture

Thanks Ken, but this was definitely a group effort. (And I think I pinged you to get a hold of Jonah, actually. Much pinging going on. :-) )

And I already have plans to try and move Drupal 7 to PDO, as there's a lot of advantages to doing so. Expect more on the subject when we're not all still busy with Drupal 6. :-)

--
Larry Garfield
http://www.garfieldtech.com/blog
http://www.palantir.net

apsivam’s picture

The day has come finally! hope other open source projects will also follow.

--
Cheers,
Sivanandhan, P. (a.k.a. apsivam)

Vaid-XXL’s picture

Eh, Drupal 6 isn't released yet.
The German language for your actual Drupal Release is a development snapshot.
And now you're allready in what PHP Version you're going to script Drupal 7?!

eaton’s picture

That's the whole point -- Drupal, and other OSS projects, want to make this public knowledge as early as possible. That way, hosting providers and users will have a reasonable margin of safety for upgrading, etc.

Announcing that *this* version will require PHP 5 would be a bit of a shock, and would leave quite a few users stranded or looking for a new hosting provider.

--
Lullabot! | Eaton's blog | VotingAPI discussion

agentrickard’s picture

It isn't so strange to make this declaration now. Some people wanted D6 to be PHP 5.

It is very important to have a roadmap for future development, and this declaration is a big step that was debated thoroughly.

Further, the GoPHP5 movement is trying to coordinate with other open source projects to move forward together. Doing so will have more influence over the future of PHP than simply declaring that Drupal is moving to PHP 5.

Remember, features that didn't get into D6 may go into D7, so development is continual. Knowing that the next target is PHP5 is a great help.
--
http://ken.blufftontoday.com/
http://new.savannahnow.com/user/2
Search first, ask good questions later.

kkaefer’s picture

Please keep in mind that translation work (as all other work involved with improving Drupal) is based on a purely voluntarily basis. Nobody gets paid for creation translations. And by the way, the German translation is at 100% (complete). If you are willing to review translations, please do so, the translation maintainers happily accept corrections and improvements.

hass’s picture

Only after you commit my latest patches... one very big string is missing and some strings needs work and love. look at the patches, please :-).

umonkey’s picture

Great news. Better late than never. ;)

james2vegas’s picture

but wouldn't a more worthy project be to remove the large number of MySQLisms in drupal modules so that using other database systems with modules other than -core is possible?

greggles’s picture

I'm not sure I see how you got there, but I do agree that this is a problem that should be addressed.

The right place to deal with this is to write issues for those modules and (hopefully) provide a patch that fixes the problem.

The big issue with database compatibility is that testing the queries on all the engines is quite hard...the more you help with that, the better it will get.

--
Knaddisons Denver Life | mmm Chipotle Log

--
CARD.com :)

hass’s picture

look at the schema api in D6... its the first step in the right direction...

Liam McDermott’s picture

I'm quite surprised by this move actually. I really love the way Drupal is written, it uses OOP concepts (even before the language supported them). Isn't changing the Drupal core and required modules--to pure PHP5 style OOP--going to take a lot of work?

We might be waiting a while for Drupal 7. I just hope it's worth the wait! In the meantime I'd better badger my hosts about upgrading. :)

Crell’s picture

Moving to PHP 5 doesn't require that Drupal be rewritten ground-up to be all-objects. That would be an insane amount of work, and we'd probably lose a lot in the process.

However, there's a lot to PHP 5 besides OO. A unified database API with formal prepared statements? Default-deny input filters on all data for greater security? XML handling that takes 5 lines of code instead of 5000? Tracking of file uploads for meaningful upload progress meters? Native support for sending JSON to the browser? Better handling of references? Date and timezone support that actually works?

Oh there is so much to look forward to that has nothing to do with objects. :-)

--
Larry Garfield
http://www.garfieldtech.com/blog
http://www.palantir.net

AdrianB’s picture

I'm quite surprised by this move actually. I really love the way Drupal is written, it uses OOP concepts (even before the language supported them). Isn't changing the Drupal core and required modules--to pure PHP5 style OOP--going to take a lot of work?

I'm quite surprised that you manage to come to that conclusion, since there is no mentioning of OOP at all in the post.

ubersoft’s picture

Real opportunities for object oriented programming.

Mind you, it's one line out of the entire post, but it's still there.

AdrianB’s picture

It is great to see this finally going public. I'll be watching the list grow, I'm expecting to see the other big ones like Gallery, WordPress and Joomla joining it.

Brook’s picture

Way to go! I'm all for pushing ahead, and am very pleased to see the senior team here make this decision!

I hope this means Drupal 7 will come quicker than expected :D

Nick Lewis’s picture

w00t! Drupal is now part of the solution!
--
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
--
Personal: http://www.nicklewis.org
Work: http://www.onnetworks.com

--
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
--
Personal: http://www.nicklewis.org
Work: http://www.zivtech.com

hanief84’s picture

I blog this and second this! Yay!
http://indiecom.net/node/909

"Hello from Malaysia! ^^ "
Website: www.indiecom.net
Skype: ga1984

Crell’s picture

Dude, that graphic is totally awesome!

--
Larry Garfield
http://www.garfieldtech.com/blog
http://www.palantir.net

xmacinfo’s picture

Hi!

It took me a micro second to switch to PHP 5.2 (from 4.4.4) on Site 5.

Open .htaccess and add the line:

AddHandler application/x-httpd-php5 .php

and save the changes.

My site is now running with PHP 5.2.

venkat-rk’s picture

I apologise for going OT, but is it really this simple? I have been paying Site5 through my nose for hosting a few 4.7 sites because my new host runs 5.2 and I just don't have the time to migrate them over to php 5. Going by this post, it would seem all that one needs to do is to copy the site over to the new host and make this small change?

Edit: Ah, you migrated to php 5.2 on Site 5. I suppose I could do the same and bring them over to the new host.

----
Previously user Ramdak.

xmacinfo’s picture

Exactly, I'm on Site 5 and I did not change a single line of PHP code. Site 5 offers PHP 5.2 in option for users who needs it.

The only caveat for my site is that I can't login, due to the fact that I'm still on 4.7.4. Drupal 4.7.6 will fix this.

So Site 5 users can upgrade in a fraction of a second.

venkat-rk’s picture

Thanks. I thought it best to continue the discussion here:
http://drupal.org/node/157276

----
Previously user Ramdak.

jsimonis’s picture

For the most part, this hasn't been an issue for me. But then we wanted to use CiviMail on a site, which of course requires PHP5.

So I made the small change, switched the CiviCRM files to the PHP 5 version, and everything worked.

--
Jenni S.
http://www.nu-look.net
Portland, OR metro area
Contact Me

alanburke’s picture

Hi All
This is good news.
But what about the elephant in the room, namely Joomla.
I've been following the discussion on the Drupal mailing list, and its been pretty active on the topic of gophp5.
Have Joomla been discussing this internally at all?
This search is a bit ominous
http://www.google.ie/search?q=gophp5+site%3Adev.joomla.org
but maybe their thoughts are documented elsewhere?

Similarly I can't find any thoughts from wordpress or Mambo developers.
from
http://lists.drupal.org/pipermail/development/2007-June/024616.html

Dries said
he talked to Matt and he's being stubborn, but we need to keep on it

That's about the total sum of Wordpress' involvement, that I can find.

While I believe that Drupal as a product will improve immensely by dropping php4 support,
Drupal the community could be left dangling if gophp5 doesn't garner the momentum required to make hosting companies switch en masse.

Lets hope they come on board, sooner rather than later.

Regards
Alan

agentrickard’s picture

Alan-

The Joomla folks are having their own internal discussion about how to best move forward. Jonah Braun actually made the same case that you did. See http://ken.therickards.com/2007/07/05/gophp5org/ for some background.

The GoPHP5 announcement was made a little earlier than I would have liked, because some people spilled the beans about discussions on the Drupal development list.

The whole point of GoPHP5 as a separate initiative from Drupal is to coordinate among different projects.

Note that PHPMyAdmin is on board, which is huge, because lots of hosts (including mine) tie that to their control panels.

--
http://ken.blufftontoday.com/
http://new.savannahnow.com/user/2
Search first, ask good questions later.

alanburke’s picture

pamphile’s picture

We might as well get a list of Drupal5 Compatible web hosts started.

Marcel
http://www.BlogPostsForSale.com
http://www.SponsoredThemes.com

jbc’s picture

My webhost offered me the following advice when I asked about their position on php5:

You can use different versions of PHP by changing the extension on the script in question. To use PHP4 with a script, leave its extension as .php. If you want to use PHP5 with a script, change the extension to .php5.

If you wish to default all .php scripts in your hosting space to use PHP5, but do not want to change the extension, place this line into a .htaccess file in your FTP space

SetEnv DEFAULT_PHP_VERSION 5

Is this good? It seems like the best of both worlds.

Crell’s picture

It's good that they offer both, and that should be sufficient to run any PHP 5-requiring programs. To be listed on GoPHP5.org, however, a host needs to offer 5.2 out of the box by default for new accounts. Offering a .htaccess toggle back to PHP 4 is fine, but 5.2 should not take any additional effort.

That does mean that the number of hosts you can use will be substantially larger than those listed on the site, but we are strongly pushing to make 5.2 the default as a sign of active support for future development.

--
Larry Garfield
http://www.garfieldtech.com/blog
http://www.palantir.net

underpressure’s picture

I'm hosted by them and noticed they are on the list of supporters.

http://cirtexhosting.com

peterx’s picture

Going to PHP 5 without Object Orientation will be difficult because PDO and some other good parts of PHP 5 return objects. The best approach is to keep those parts of the data as objects all the way through the system. Drupal 8 can then objectify the rest of the code.

petermoulding.com/web_architect

Crell’s picture

Again, this is not a formal policy statement, but my suspicion is that Drupal 7 will use "use OO where OO makes sense to use it". That's always been the de facto policy, but with PHP 4 it rarely made any sense. With PHP 5, it will make sense to use it in more places. Where exactly will be determined by code. Yes, PDO is a big one where it will make sense.

--
Larry Garfield
http://www.garfieldtech.com/blog
http://www.palantir.net

peterx’s picture

The change from MySQL 4 to MySQL 5 was harder than the change from PHP 4 to PHP 5 because of the change from mysql to mysqli. The change to PDO is the next logical step. While we are cleaning up the database part of Drupal, we could set a higher minimum level for MySQL so we can use SQL that is more compatible with PostgreSQL and Oracle. We could move from the SQL 1996 standard up to the SQL standard from 1999.

petermoulding.com/web_architect

peterx’s picture

Now that Drupal 7 is on the way, I started a Drupal 7 performance wish list in http://drupal.org/node/157350. If Drupal 7 brings changes to the database code, there are some spots where we can gain a performance advantage with little extra change to the code.

petermoulding.com/web_architect

webchick’s picture

The only way Drupal changes is if people roll up their sleeves and help change it themselves. So rather than stating what you'd like other people to work on, why not state what you are planning to put effort into? :)

Btw, even though code is frozen, performance patches are still accepted for 6.x at this point. If you have ideas, or even want to help out with existing important performance efforts, now's the time.

peterx’s picture

Hello Webchick,
I can understand you wanting people to test Drupal 6. I tested 4.6 to 4.7 and 4.7 to 5.0 but 6 is arriving at a time when I am working on several projects unrelated to Drupal. When I do get a chance to try something, it is on Drupal 5 using PHP 5 and MySQL 5. I do not have a PHP 4 system for compatibility testing.

I already have working code for Drupal 5 and PHP 5. I test the performance on sites with mixed activity. I am suggesting similar changes for release 7, when Drupal adopts PHP 5, and would like to discuss their possible use.

Forums are places for discussion.

I offered code improvements for menu in release 5 and someone replied saying they were already completely rewriting the menu system for release 6. Should I spend my time working on a change for obsolete code or move on to something more useful? Discussion of a prospective in a forum makes sense.

I know some people prefer Web phones, IRC and other forms of communication. I do that on projects where I am paid to work from 11:00pm to 6:00am talking with people on the other side of the world. For voluntary work on community software, I prefer forums where everyone can read and reply in their own time zone.

Performance changes vary in effectiveness and need testing on a wide range of sites. I made major improvements on one site but when the site moved to Solaris on Sparc, the site was slower. I use and test on Myisam tables and people get different results on Innodb tables. I prefer to propose changes and see where the discussion heads before pushing my changes.

petermoulding.com/web_architect

simplulo’s picture

I see that kind of response fairly frequently here, as though the entire drupal.org community were comprised of entirely of expert developers with time on their hands, freeloading. I don't know what the breakdown is, but at least some people here *cannot* contribute code, even though they may have been programmers a decade or two ago. You might have one or two project manager-types lurking about, or even potential customers. Some of those people may be able to contribute money, which might be particularly nice for developers in poorer countries. Those who can only bleat about missing functionality still contribute by conveying in aggregate what features are in demand. Even those who use Drupal silently but loyally broaden the user base and contribute to Drupal's appeal.

An example is i18n functionality, which some of the Drupal heavies were until recently skeptical about. I want it and I bleat about it, but I can't do it myself, so I make donations when Drupal makes significant i18n advances.

If I am mistaken, and the drupal.org discussion forum is intended only for active Drupal coders, please make a statement to that effect available for the newbies.

eaton’s picture

... "I am willing to thoroughly test and troubleshoot [x] functionality..." is a battle plan.

The difference between a 'wish list' and a 'battle plan' is really about priorities. Everyone has a huge list of things that they would LIKE, but the list of things they are willing to dedicate resources to (in the form of coding time, testing time, documentation-writing time, monetary sponsorship, etc.) is always smaller. Wish lists are rarely helpful to the community, while battle plans help everyone see what *will* be worked on... :)

Also, Webchick is one of the champions of the idea that *all kinds of contributors* are important, so please take her statement in the broadest way possible. :)

--
Lullabot! | Eaton's blog | VotingAPI discussion

sepeck’s picture

Battle plans are "I will do's" as in put work towards.
'wishlist' are "I want's", not I will do's. Feature requests are where wish lists belong. Not off topic random comments in a forum post. Those distract from the actual topic at hand.

You do have something wrong. Drupal 'heavies' were not skeptical about I8n in core. Local module has been in core for a long time so the provision for multiple language and such has been in core for quite a while.

I8n is not simple. It is complex. The general Internet knowledge about implementing sites for I8n has been evolving. Browser language detection has been evolving. There were two different approaches to I8n that evolved over time. Lessons were learned on them. Those folks got together and collaboratively refined experience and developed a path forward that would be sustainable for core. That is why more advanced I8n features got in core. Not because 'heavies' were skeptical of I8n, but because the earlier implementations were not broad enough to encompass a solid base solution.

Another possible solution that has worked is to actually fund targetted development. 'Bleating about' (your words) something does not necessarily make it a reality and is often not an effective way to gather support and build solid development paths. Donating after the fact is fine, but not nearly as effective.

Now before you savage me as yet another developer, I don't code php.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

pamphile’s picture

Wishlists arn't in Drupal's culture. I started a wishlist, and got a negative response.

A personal battle plan is better. A tiny tiny personal battle plan is better than a tiny tiny wishlist. When you win, everyone else also wins.

Marcel
http://www.blogpostsforsale.com
http://www.sponsoredthemes.com

idflorin’s picture

"Improved performance and a more accurate memory usage."

The best performance around. php 4 is dead.
_______________
seobanks

gmasky’s picture

We need to maintain a list of Web Hosting providers who are already offering PHP5, MySQL 5...

greggles’s picture

Something like this: http://gophp5.org/hosts ;)

I know it doesn't help for MySQL5, but that's less of a problem (so far).

--
Knaddisons Denver Life | mmm Chipotle Log

--
CARD.com :)

misty3’s picture

Will drupal 4.7.6 ( the downloadable tar currently available as of July 2007 ) be continue to work ( along with commom modules ) in the same way in php5 ... ??

If not is there any work arounds or issues to deal with to run 4.7.6 in php5 ?
( apart from options to shift to drupal 5 or 6 or 7 )

Best regards

Gábor Hojtsy’s picture

Go and read what the download page states.

misty3’s picture

I am sorry - the download page does not answer my questions :(

Any short answer ( yes / no ) will be much appreciated.
Best regards

tm’s picture

Frando’s picture

In which way does the download page not answer your question?

Note: Drupal 4.6/4.7/5.x are compatible with PHP 4, 5.0 and 5.1 versions. PHP 5.2 compatibility is only available from Drupal 4.6.11 / 4.7.5 / 5.x.

It's by all means the boldest text that can be found there..

misty3’s picture

So long I have been downloading drupal from the drupal home or first page and this http://drupal.org/drupal-5.1 - so I could not find it.

Now thanks a lot for clearing up the doubts.

Thanks again and with best regards

JStarcher’s picture

Good deal. It's time for PHP5 to shine!

webappl’s picture

From 'Object Aggregation' (http://www.php.net/manual/en/ref.objaggregation.php)
To 'runkit' (http://www.php.net/manual/en/ref.runkit.php).
This could be a OOP way for functions dynamic reimplementation (http://api.drupal.org/api/HEAD/file/developer/topics/oop.html).

gophp5, go!

kylehase’s picture

I'm a big fan of PHP5 but at the same time I can see why some providers are reluctant to offer it. For many companies it's simply a policy issue. If a distro comes with PHP4 (for instance RHEL4 and SLES9) then the Linux distro company may not provide support for PHP5.

If a hosting provider must abide by such policies then they should have some server farms running a newer version of the distribution with PHP5. Both RHEL5 and SLES10 now come with PHP5.

singlow’s picture

My hosting provider (pair.com) has recently upgraded most of its servers (FreeBSD) to use php5 for the default engine in Apache. They have had it available as a CGI script for a while.

vinayras’s picture

I have been trying to move to PHP 5.x since long. With drupal moving ahead on this platform - this is certainly a good news for me - being a Drupal based Developer.

Vinay Yadav
PHP Specialist
http://www.vinayras.com

Coupon Code Swap’s picture

Drupal 7!!! Yikes, it seems like only yesterday that Drupal 5 was released. Great to see this long term vision and relentless development. All of the hosting providers out there are going to have to catch up with Drupal.

What about mySQL 5 and stored procedures?

------------------------------------
Themebot - Open Source Web Design Templates and Free Web Layouts

jsimonis’s picture

I've been trying to move to Drupal 5.2, but keep running into any problems. And I have yet to be able to get any response on the site about what could be causing it. We're running Drupal 5.1, and we can't create new users and no one can register on the site.

I hope that support for people moving to Drupal 5.2 is going to improve between now and Drupal 7, especially since many of us have never used it before.

--
Jenni S.
http://www.nu-look.net
Portland, OR metro area
Contact Me

mfer’s picture

You're trying to move to drupal 5.2? How is that? 5.2 isn't released yet. Are you trying to move to drupal 5 dev?

Or, were you talking about php 5.2?

--
Matt
http://www.mattfarina.com

jsimonis’s picture

Sorry, doing too many things at once.

I meant PHP 5.2. We moved to it because PHP5 is required for CiviMail.

However, now the Drupal user registration system is broken.

--
Jenni S.
http://www.nu-look.net
Portland, OR metro area
Contact Me

jsimonis’s picture

I'm not hijacking. I'm just pointing out that as great as it is that we're moving to PHP 5 with Drupal 7, I certainly hope support for people improves. There are a lot of us out there who have never used PHP 5. And chances are, for at least a while a lot of us will be on servers where PHP 4 is still the default, and you have to switch to PHP 5 manually (the way Site5 does it).

I'm not expecting answers on my problem here. I've already posted one in the "issues" area. I'm just saying that we've got to improve support for people on using PHP5 with Drupal.

--
Jenni S.
http://www.nu-look.net
Portland, OR metro area
Contact Me

Coupon Code Swap’s picture

As mentioned, site5 has the option to switch to PHP5. I've also been looking into hosting providers that have PHP5 as default. Is there any advantage at this point to running Drupal 5.1 with PHP5? Or, has anyone run into compatibility problems with this configuration?

------------------------------------
Themebot - Open Source Web Design Templates and Free Web Layouts

jsimonis’s picture

We switched our Drupal 5.1 site on Site5 to use PHP 5.2, but like I said earlier, I've run into a problem. I've posted an issue about it.

That's the only configuration problem I've run into thus far.

The only other problem I've seen has been a memory issue. I think that may be due to CiviCRM/CiviMail, though. We've had our memory allocation over 80MB (with very few modules enabled), but still get an error when the cron job runs for cron.php.

The advantage is that some modules will only work with PHP5. So if you want to use them, you'll need to make the switch.

I'm really hoping Site5 will get tired of us complaining and bugging them and will offer some servers that run PHP5 by default. I think we're going to see more and more developers coding modules to only work on PHP5 since you apparently can do more - plus it's going to be the standard before long.

--
Jenni S.
http://www.nu-look.net
Portland, OR metro area
Contact Me

mfer’s picture

Drupal core runs fine on PHP 5.2 and I have a number of sites running php5 (in fact every php site I run).

Some contributed modules may have problems. But, it's a matter of troubleshooting and dealing with the bugs. This thread is not the appropriate place to deal with bugs.

If your problem is with civicrm than the drupal site is not the right place for this. See the civicrm site.

--
Matt
http://www.mattfarina.com

jsimonis’s picture

I know it's a matter of troubleshooting and that this isn't the place. That's why I said several times I"m not looking for a solution here - I posted an issue for that. I'm responding to people who talk about how Drupal will work in PHP 5.2 now, or those who ask what problems you'll run into if you go to PHP 5.2. now. Those are both legitimate topics on a posting about Drupal and PHP 5.

The problems related to CiviCRM have been posted over at their site already, and we're working through them. Which is why I didn't detail it here. I just showed the kind of problems you can run into right now if you use PHP 5 right now. It's not something that is that widely discussed on this site - I searched for hours and found very little.

--
Jenni S.
http://www.nu-look.net
Portland, OR metro area
Contact Me

mfer’s picture

Just for the record drupal works without a problem on PHP 5.2.

The issues here are not typical. There is something messed up that's an issue. Either there is something wacky with drupal or civicrm (meaning they aren't the default ones) or there is something wrong with the server setup. In either case, a good server setup, drupal, and civicrm will work in a PHP 5.2 environment.

I've set it up and so have others.

--
Matt
http://www.mattfarina.com

Coupon Code Swap’s picture

Besides the memory issue, have you noticed any performance increases or reduction in use of system resources? I know it's hard to gauge, but I'm wondering if there is any compelling reason to go with a host that has PHP5 as default if none of the modules i'm using require it. I've started compiling a list of providers that have PHP5, and I've been asking their tech support other questions, like whether or not the database is on the same server etc. I'm getting ready to launch a new Drupal site soon and would like to find a host that I can start shared with PHP5 as default and have the option to upgrade to VPS or dedicated if necessary.

jsimonis’s picture

I'm not sure yet. The one problem I did have with a module (CiviCRM) has been corrected, so now everything works fine. I increased the memory allowed in my php.ini to 100MB, and now I have no problems.

And even that problem should go away soon, since we're going to be moving to a hosted CRM and bulk e-mail system somewhere else. It appears that CiviMail is the memory hog, and that we should be fine as soon as it's turned off.

We've only been on PHP5 for a few days, but I may be able to give more details regarding performance and system resources once it runs for a little while longer.

I'm fine with my provider not having PHP5 as the default now - but I'm encouraging them to do so soon. Especially with PHP4 now at an end. Being able to manually switch to PHP5 is ok, as long as they give you the support needed to fully switch. I found on Site5 it's more than just a htaccess call - the cron jobs to php files that need to be run through PHP5 wouldn't work properly.

--
Jenni S.
http://www.nu-look.net
Portland, OR metro area
Contact Me

xmacinfo’s picture

I can assure all readers that cron jobs are working correctly with Drupal 5.1 using PHP 5.2.0 enabled through .htaccess on Site 5.

I have both Drupal 4.7.6 and 5.1 sites running at Site 5 and they are now all running perfectly on PHP 5.2.0.

jsimonis’s picture

They work fine as long as you make a call to php5 in your cron job. Ours were not working properly when calling php5 files, such as those in the php5 version of CiviCRM. Calling cron.php and such worked fine, since they're not made for php5. No changes were necessary for them.

I contacted Site 5, and learned there was a change that had to be made to the cron job (specifically calling php5) to make it work properly with the php5 specific files. Once I made the change, everything worked fine.

--
Jenni S.
http://www.nu-look.net
Portland, OR metro area
Contact Me

reikiman’s picture

You would think if moving to PHP5 were a high priority for the PHP community, then the PHP.NET documentation would discuss installing PHP5. But the online docs for PHP discuss how to install PHP4:

http://www.php.net/manual/en/install.unix.apache2.php

I agree it's a kind of strange migration lock-out...

- David Herron - http://7gen.com/

koshea’s picture

I think maybe you should read your own link a little further, those instructions are for both PHP4 and PHP5.

--kevin

saidi’s picture

That's what i call a GOOD a VERY VERY GOOD news ! Thanks

BryanSD’s picture

PHP.net just announced the End of Life for PHP4. Only security updates on a case-by-case basis starting in 2008...and dead in August 2008.

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

Link to Announcement: http://www.php.net/archive/2007.php#2007-07-13-1

-Bryan
CMSReport

jsimonis’s picture

Hopefully this will help us to be able to push hosting companies even harder to use PHP 5 as their default.

--
Jenni S.
http://www.nu-look.net
Portland, OR metro area
Contact Me

rainer_f’s picture

After I read this post, I decided to move my second biggest drupal project to PHP5. It was easy (thanks to my hoster), and I received overall gains in performance!
That experiment convinced me, that PHP5 is ready for production now and so I also switched some wordpress and b2evolution projects.

GoPHP5!

AdrianB’s picture

Well, I think we can safely assume WordPress won't be joining the effort:

Some app makers felt sorry for PHP 5 and decided to create the world’s ugliest advocacy site and turn their apps in to protest pieces at the expense of their users.

Matthew Mullenweg: On PHP

webchick’s picture

I don't understand in what way he draws the conclusion that this is a 'political' move... rather, it's about the viability of the platform we're all using to develop our software (PHP).

Rasmus (the creator of PHP) made a very strong case at OSCMS this year (where WordPress presence was notably absent :\). The developers building the PHP platform itself are like any other developers out there. If they don't get to innovate and work on new, cool stuff from time-to-time, they're going to move on to other, more exciting projects. Development of the PHP platform is hamstrung to a large extent because of how many people are still clinging to PHP 4. It's going to take movement en masse to PHP 5 in order for PHP 6 to ever see the light of day. Hosting providers won't move on their own, and the PHP developers can't force hosting providers to move either. Rasmus's view is that it's up to the application developers (Drupal, PHPMyAdmin...) to make the first move.

Further, PHP 5 has a variety of better tools to help us build better software for, guess who? Our users. :) This is very much a user-centred move. As a user of Drupal, I 100% support this decision, and applaud our community for being one of the projects to take this important first step.

underpressure’s picture

As a user of Drupal, I 100% support this decision, and applaud our community for being one of the projects to take this important first step.

Seconded

sepeck’s picture

I particularly enjoyed that he spent more time critiquing the site theme and blaming everyone else then addressing the very real concerns and benefits this brings.

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

AdrianB’s picture

OsterD’s picture

For the past 2 days I have lost my sleep using from CodeGear(Borland, qadram joint venture) Delphi for PHP.
Since I am a fanatic user of Borland's IDEs' this product seems very familiar to me.
The RAD approach to PHP sounds like a very interesting feature.
The produced code is pretty small and runs quite fast.
Saying that though, since it is based on VCL for PHP GPL framework even for a single button a mere of about 8 inherited classes is in use.
The question is if the core development team of Drupal is thinking to develop-provide a framework that can be used within D4PHP in order to produce modules using Delphi for PHP.
That would greatly enhance the module development.
Just making a question/suggestion here. I don't even know if this is possible.
Any insight on this?

David Oster aka George Pasparakis
P.S. I think VCL for PHP is using version 5 of PHP, does this means that the above needs to be considered for Drupal 7?

ashiwebi’s picture

Its great to hear that drupal goes with php5.Congrats

kylehase’s picture

The parent says

Drupal 7 will be incompatible with PHP 4

but also mentions many advantages to using PHP 5.2. Where does this leave PHP 5, 5.1?

PHP 5.1 is the default in RHEL 5 and CentOS which are used by many hosting companies (and myself). RHEL will not update to PHP 5.2 so there will never be an official PHP 5.2 RHEL package. Third party 5.2 packages exists but some companies/people are purists.

nbz’s picture

I would assume that RHEL 6 will be released before Drupal 7.

greggles’s picture

Do you have any basis for that?

RHEL3 was released in 2003, RHEL4 was released in 2005, and RHEL5 was released in 2007. I believe that RHEL6 will be released no sooner than 2009. It will then take several months before it becomes the default install and several years before it is the most popular installed version.

Even if RHEL6 is released before D7, RHEL support policy is for 7 years. RHEL4 will have updates, in some form, until 2012, and RHEL5 will have updates until 2014. The RHEL policy of backporting security fixes rather than pushing people to a new major version means that those on RHEL4 who are "purists" about the package number will be using PHP4.3 until their machine falls over.

This means that Drupal will not work for RHEL purists who are reluctant to upgrade their OS. But that's OK - those are not the people most likely to be running the latest version of Drupal anyway.

--
Open Prediction Markets | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book

--
CARD.com :)

xmacinfo’s picture

If an RHEL purist does not update it's PHP 4.3 to PHP 5.2, he will be purist enough to install Drupal 4.7 and not upgrade.

nbz’s picture

No real concrete basis for my assumption.

According to some senior Fedora developers last year, there was a real chance that RHEL6 would be based off Fedora 9. That did not happen, and the active lifespan of RHEL 5 was increased.

I am basing the assumption on RHEL 6 being based on Fedora 10, so add a few months for stabilisation/certification, which should give it a release early next year.

Designers.pro’s picture

This is right decision in long run, the best way to sustain efficient code.
I'll be waiting for the release!

www.designers.pro
"Design Professionals Community"

peterx’s picture

Many hosting companies offer EAccelerator for PHP as the PHP cache. PHP 6 will include APC and APC has a distinct advantage over EAccelerator when you update live sites. Could we add APC as the preferred PHP cache for PHP 5? Would ISPs start the change now?

Many site owners do not know the benefits of a VPS over shared hosting and blame shared hosting problems on Drupal. When people move their sites from shared hosting to VPSs, they are often unaware that the VPS will start with EAccelerator or equivalent turned off and blame the result on Drupal. Some ISP help desk people make the same mistake. A little education and some sort of site setup tutorial would help.

Cpanel helps people manage VPSs but does not guide anyone in the right direction. Cpanel makes life easier but you still have to know what you need to get good performance and reliability.

Cpanel does not offer APC as an option on CentOS. Is Cpanel or CentOS the culprit? Does anyone have a good tutorial on how to replace EAccelerator with APC? I can only find Unix pages full of DOS commands.

When people are moving from one ISP to another to get PHP 5, we could guide them toward switching on the right options for the new site. The availability of those options could be part of the ISP evaluation. The end result would be faster and more reliable Drupal sites.

petermoulding.com/web_architect

my.wahyu’s picture

I'm such kind of newbie explorator, I try a few software.. plogger, coppermine, 4images.

Last I use gallery2... and i have been integrated successfully wit my drupal.

Oke .. now i have been disactivated .. and try to use the native software image that bundled with drupal.

 

Still waiting with G3..

I'm wondering what kind look like.., .... if it all about API??

Btw.. I use Drupal 6.10 ..and drupal.org said that the latest Drupal is 6.10...

So whre I can find D7 ..and what the different..?? is "D6" good enough..!!

Salam gastia.com

xmacinfo’s picture

Please note that Drupal 7 is not available, not for at least 4 to 6 months. However, it is in development and its feature set is not frozen yet. Differences and a list of new features will be made available only when D7 it will reach beta status.

If you are as developer, or just want to try out a development version, enable the Developer Links block in your account and download the current tarball.

bbeyer’s picture

What features of 5.2 are being used that are not in PHP 5.1.*

frank0987’s picture

Is Drupal 7 compatible with the recent PHP 5.3? Drupal 6 is incompatible with PHP 5.3.

peterx’s picture

My Drupal 5, 6.10, 6.12, and 6.13 sites work with PHP 5.3.0. Where is the incompatibility? Have you started an issue for the problem?

momper’s picture

5 years of php5 and drupal now joins - nice :)

nbz’s picture

Drupal joined and workd on php5 a long long time ago.

It is now using php5.2 as the minimum version for Drupal 7 (which was released three years ago) - Not bad and not a negative thing as your post hints at.

simplulo’s picture

Not only that, Drupal was a major instigator of the Go PHP 5 movement, fully two years ago:
http://php-mag.net/magphpde/magphpde_news/psecom,id,27335,nodeid,5.html

peterx’s picture

http://drupal.org/node/360605 contains a working patch for PHP 5.3.0 where you have E_DEPRECIATED on. I turned E_DEPRECIATED on for one of my new sites and had to apply the patch.

unundindur’s picture

Nice to hear.

Do we have any kind of estimate as to when Druapl 7 will be released?

litwol’s picture

With your help it will come out sooner.

Sometimes something interesting appears on http://litwol.com

simplulo’s picture

The big question is when the modules will be updated for D7....

nbz’s picture

... Is whenever people do it. Some people are already tracking the development branch. Others are not.

Best way to get your favourite module updated is to do the work. (and "not a coder" is not always a valid excuse - I am neither, but my first big task in coding was to update a drupal 5 module to drupal 6. It took some time and taught me a few things. Anyone can do it.)

simplulo’s picture

I'm surprised at how often people in the Drupal community suggest that I code, but how rarely they suggest that I chip in some money. I see little structural support here for financial contributions.

WorldFallz’s picture

probably because more often than not money is not the bottleneck-- manpower is. All the money in the world can't get something done if there isn't time or manpower to devote to it. Though you will see chipin widgets and donate buttons from time to time-- so be sure to contribute when you do!

And seriously, anyone can run modules through http://drupal.org/project/coder and address the simple changes described there for a module update. I would venture to say that doing that and posting the result as a patch to an issue queue will 1) greatly speed up a module's conversion and 2) often make the maintainer far happier than a $50 donation would.

_
Care about the future of the Drupal.org forums? Please join our conversation and show support for improving the forums infrastructure.

simplulo’s picture

I'm sure there are cases where only one person can do perform the work, and that person does not need additional money, but in other cases the module is entirely a commercial matter, e.g. I commissioned this:
http://drupal.org/project/arcade

There must be many coders out there who would be happy to contribute for some cash, especially in some of the poorer countries, especially in these dire economic times. There could be a pool of them.

greggles’s picture

http://www.hubdub.com/m35392/When_will_Drupal_70_be_released

Current winner is during the first quarter of 2010.

--
CARD.com :)

submit.dk’s picture

In Denmark the Danish community are looking forward to the release. Whether it will be in 2010 or 2011.
The most important thing is not when it's released, but the quality of the release.

Best regards
www.submit.dk/drupal

dscoop’s picture

This was a very nice release years ago. Right now there are happening a lot of issues when using Drupal 7 and PHP 7 together. Us from Cooper Webdesign would be very happy to know, when we can expect a Drupal 7 update for PHP 7 issues?

// Cooper Webdesign