Drupal 7 and PHP 5.2
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
All right!
Thanks for the news, Robert.
indeed
Good news for developers, bad news for incompetent hosting companies. Yay :)
--
John Forsythe
Need reliable Drupal hosting?
I know that PHP 5 is going
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!
backwards compatibility
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
non issue
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
Interesting point
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
If the Drupal team thinks
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).
Chicken, egg?
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
digg it
Of course helping out to digg the story would be good:
--
Knaddisons Denver Life | mmm Chipotle Log
good news
+1
Good news ^^
-----------
arthuran.net
And slashdot it
And Slashdot It!
Thank you for the great
Thank you for the great news! i know XML support in php5 will be a HUGE benefit to the drupal project.
With the push for PHP 5.2,
With the push for PHP 5.2, will the Drupal projected embrace Objects too?
Here is the dossier on the topic.
TBD
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
PDO
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.
We all have
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
The day has come finally!
The day has come finally! hope other open source projects will also follow.
--
Cheers,
Sivanandhan, P. (a.k.a. apsivam)
ehm
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?!
Yep.
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
Yes
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.
Please keep in mind that
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.
german - not yet...
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 :-).
Great News
Great news. Better late than never. ;)
awesome
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?
worthy? off topic?
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
look at the schema api in
look at the schema api in D6... its the first step in the right direction...
See above
PHP 5.2 may bring PDO, too. http://drupal.org/gophp5#comment-249078
--
http://ken.blufftontoday.com/
http://new.savannahnow.com/user/2
Search first, ask good questions later.
I'm quite surprised by this
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. :)
Doesn't have to be OO
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
I'm quite surprised by this
I'm quite surprised that you manage to come to that conclusion, since there is no mentioning of OOP at all in the post.
Er... last line of "benefits and features"
Mind you, it's one line out of the entire post, but it's still there.
This is great
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.
Excellent News!
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
w00t! Drupal is now part of
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 blog this and second this! Yay!
I blog this and second this! Yay!
http://indiecom.net/node/909
"Hello from Malaysia! ^^ "
Website: www.indiecom.net
Skype: ga1984
Cool graphics
Dude, that graphic is totally awesome!
--
Larry Garfield
http://www.garfieldtech.com/blog
http://www.palantir.net
Took me 0.00025 seconds to switch to PHP 5.2
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 .phpand save the changes.
My site is now running with PHP 5.2.
I apologise for going OT,
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.
I did not change a single Drupal code
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.
Thanks. I thought it best to
Thanks. I thought it best to continue the discussion here:
http://drupal.org/node/157276
----
Previously user Ramdak.
Did the same thing
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
The Other elephants in the room.
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
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
Joomla
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.
Some Wordpress discussion
Some Wordpress discussion here
http://comox.textdrive.com/pipermail/wp-hackers/2007-July/thread.html#13...
Lead Developer Matt Mullenweg's comment here
http://comox.textdrive.com/pipermail/wp-hackers/2007-July/013593.html
Not particularly encouraging...
We might as well get a list
We might as well get a list of Drupal5 Compatible web hosts started.
Marcel
http://www.BlogPostsForSale.com
http://www.SponsoredThemes.com
php4 or php5
My webhost offered me the following advice when I asked about their position on php5:
Is this good? It seems like the best of both worlds.
5.2 by default
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
Cirtex hosting.
I'm hosted by them and noticed they are on the list of supporters.
http://cirtexhosting.com
OO
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
OO where it makes sense
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
MySQL 5
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
Drupal 7 performance wish list
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
-1 to wishlists. +1 to personal battle plans.
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.
Forums are places for discussion.
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
+1 to contributors of all kinds
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.
Keep in mind...
... "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
topic
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
Wishlists arn't in Drupal's
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
BEST
"Improved performance and a more accurate memory usage."
The best performance around. php 4 is dead.
_______________
seobanks
Web Hosting: PHP5
We need to maintain a list of Web Hosting providers who are already offering PHP5, MySQL 5...
perhaps...
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
current drupal 4.7.6 and php5 compatible ?
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
download page
Go and read what the download page states.
No answer in download page
I am sorry - the download page does not answer my questions :(
Any short answer ( yes / no ) will be much appreciated.
Best regards
system requirements
According to http://drupal.org/requirements, yes.
In which way does the
In which way does the download page not answer your question?
It's by all means the boldest text that can be found there..
My apologies
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
Good deal. It's time for
Good deal. It's time for PHP5 to shine!
PHP 5 OOP + runkit could help Drupal go OOP
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!
Understand provider's concerns
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.
Hosting Providers and PHP 5
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.
Great News
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
What about Drupal 9?
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
Same here
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
Move to 5.2?
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
Sorry, doing too many things
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
Please don't hijack the
Please don't hijack the thread.
http://drupal.org/Troubleshooting-FAQ
--
http://ken.blufftontoday.com/
http://new.savannahnow.com/user/2
Search first, ask good questions later.
I'm not hijacking. I'm just
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
As mentioned, site5 has the
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
Switching...
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
PHP5 and drupal
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
I know...
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
drupal works on php 5.2
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
Besides the memory issue,
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.
Not sure yet
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
Cron jobs works fine
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.
They work fine..
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
Kind of hard to take this seriously
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/
I think maybe you should
I think maybe you should read your own link a little further, those instructions are for both PHP4 and PHP5.
--kevin
Great news
That's what i call a GOOD a VERY VERY GOOD news ! Thanks
PHP.net ends life of PHP 4.
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.
Link to Announcement: http://www.php.net/archive/2007.php#2007-07-13-1
-Bryan
CMSReport
Thanks
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
Got the stone rolling
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!
Forget WordPress
Well, I think we can safely assume WordPress won't be joining the effort:
Matthew Mullenweg: On PHP
Yes, that entry confuses me...
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.
As a user of Drupal, I 100%
Seconded
commentary
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
A follow-up
A follow-up: What Matt Mullenweg doesn’t know about PHP5, and how it hurts him and his users (and Matt answering in the comments).
Drupal 6/7 code generation using D4PHP
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?