The Time To Embrace PHP 5.3 Is Here
I am amazed at the number of Drupal modules that do not work under PHP 5.3. Until recently it had been acceptable to write code that didn't work in PHP 5.3. There was a small market share and the initial release of 5.3 had some bugs that made it worthwhile to rely on PHP 5.2. But, with the upcoming release of Drupal 7, which requires at a minimum PHP 5.2, and with PHP 5.3 starting to ship on some of the popular linux versions it's time to make sure Drupal sites run under 5.3 without any problems.
Drupal 7, A Clean Point In Time
Now that modules are being ported to Drupal 7, in anticipation of its upcoming release, we have a perfect opportunity to support PHP 5.3. By support I do not mean rely on PHP 5.3. While it has a fair market share it is still at a point where supporting both PHP 5.2 and 5.3 is beneficial.
This should be easier than when we supported PHP 4.4 through PHP 5.2. The differences between 5.2 and 5.3 are much smaller and both versions are far better than any version of PHP 4.
Differences Between 5.2 and 5.3
In addition to the list of incompatibilities between 5.3 and previous versions there are two items I'd like to highlight.
- Call-time pass-by-reference no longer works. That is, when you want a variable passed by reference into a function the
&symbol should only be on the variable in the function definition and not when the function is called. - Don't use the ereg family of functions. The posix regex functions are now officially deprecated. Instead PCRE should be used for regular expressions.
Multiple Environments On One System
I typically develop under PHP 5.2. I want the ability to develop and test under PHP 5.3 side by side with 5.2. It is possible to setup a second system with the alternate version of PHP but it is more practical, for me, to have it right within my regular development workflow. Luckily there is a lot written about doing just that. Here's a short list.
- Use MAMP. MAMP 1.9 provides both PHP 5.2 and 5.3.
- Use WAMP with a PHP 5.2.x add-on.
- FastCGI with Multiple PHP Versions.
- MacPorts and Multiple PHP Versions.
- Zend Server with PHP 5.2 and 5.3.
- Multiple PHP versions using Homebrew to install them.
If you noticed that this fairly OS X centric. Most of the ideas on this, like using FastCGI, will work on other environments (e.g., *nix systems) as well.
I run PHP 5.3 because of phd and did so for quite some time. D7 works with PHP 5.3 well as far as I can see.
Drupal 7 works under php 5.3. I just want to see all of contrib run under 5.3 as well.
Just the facts:
Linode, one of the VPS hosting companies, publish some stats:
48% Ubuntu server
24% Debian
16% CentOS
everthing else below 5%
http://www.linode.com/about/
So Ubuntu server basically has half of the web server pie, at least on VPS's.
And the latest Ubuntu release (10.04 Lucid Lynx) ships with PHP 5.3. You do the math...
I started a new VPS just yesterday, and I was forced to install Ubuntu 9.10 instead of 10.04, exactly because Drupal mudules' lack of PHP 5.3 support.
The PHP 5.3 issue tag is a great place for people to get started contributing code, as it's often really simple changes required.
For windows users, http://www.wampserver.com makes it trivial to test between all different combinations of apache, php, and mysql. Its simply a matter of downloading the desired packages and selecting options from the little control applet.
While my homebrew build scripts will get php 5.2 running side by side with the php 5.3 that snow leopard ships with, you'll have to source a 5.3 homebrew formula if running on leopard or wishing to track recent updates to 5.3 as apple is unlikely to ship regular updates. Of course my script isn't really tested on leopard so ymmv.
Also using this approach you will have to write your own switching script to swap symlinks and restart apache when switching. I'm only running 5.2.12 for drupal development at moment using my homebrew formula so haven't done this but it would be trivial as the homebrew approach involves leaving everything that the mac ships with alone (except for the apache config file of course) and building custom stuff under /usr/local.
Your first difference is not exactly correct. What you are describing does still work altough it generates a deprecated error (with a new error type, but it was a notice since at least PHP 5.0). However, what does not anymore work is calling a function by value when it it was defined as by reference.
This happens usually when call_user_func_array() is used, because it works differently than calling a function directly. When using the previous function, by reference parameters need to be added to the parameter array by reference. You can find a simple example here: http://api.drupal.org/api/function/drupal_execute/6 (Note the $args[1] = ... line).
Additionally, Drupal 6.17 (earlier versions were almost) is PHP 5.3 compatible (but not E_DEPRECATED compatible since the ereg() functions can not be removed without breaking the API) and most contrib modules are too and for those that arent exist in most cases patches (I've written quite a few including these for core).
Drupal core is not so much the issue. Contrib is where we need to target since there are modules in contrib that are not PHP 5.3 compatible.
As for the call time pass by reference see http://www.php.net/manual/en/language.references.pass.php.
Many developers have notices disabled during development. The notices that have existed have not been noticed by many so seeing something is new to them.
"worth wild" is cute. But I think you meant "worthwhile".
oops. Thanks for catching the mistake. Fixed.
The moral of the story is I think, to always develop with your PHP error reporting set to E_ALL rather than the more common E_ALL & ~E_NOTICE. This will show you where you are using depreciated techniques which would've caught 90% of problems of moving from 5.2 to 5.3.