From an important notice posted on the main PHP.net page - a bug has been found with PHP 5.2.7 and it has been "recalled":
Due to a security bug found in the PHP 5.2.7 release, it has been removed from distribution. The bug affects configurations where magic_quotes_gpc is enabled, because it remains off even when set to on. In the meantime, use PHP 5.2.6 until PHP 5.2.8 is later released.
The 5.2.7 downloads have been removed from the downloads page but you can now redownload the PHP 5.2.6 source and binaries if you need them.
You can also find out more about the issue in this post on Stefan Esser's blog
Michelangelo van Dam has posted his summary of the recent BugHuntDay that happened in Roosendaal (the Netherlands) this past weekend:
Bughuntday is a whole day developers can come together to start fixing bugs for open-source frameworks and libraries. This Saturday we started these series with Zend Framework, a hugely adopted PHP framework within enterprise and professional web application development.
He also includes the slides from the presentation and a video of Jurien Stutterheim's talk introducing everyone to testing and the Zend Framework. There's pictures of the event on Flickr too.
Chuck Burgess has a quick post pointing out the next "PEAR triage days":
PEAR's next Bug Triage days are this weekend: Saturday 4 PM - 9 PM UTC and Sunday 4 PM - 10 PM UTC.
You can find the schedule and more information about joining in at this page on the PEAR wiki. You can find others working on the triage on the EFNet's IRC network in the #pear-bugs channel.
On the Zend Developer Zone there's a new article that looks to answer the question in its title - "Why should I care what server my application is running on?" (by Eddo Rotman)
Imagine this - you develop an application on your machine and then, when you come to deploy it to the production server, all of a sudden, you encounter various errors and failures. Or maybe, when you decide to switch your hosting provider, your application stops behaving the way it should. How about this -... one day, out of the blue (well, out of your IT manager's whim) your application just misbehaves. Sounds familiar?
Times like can never be completely avoided (yes, there'll always be bugs) but you can take some steps to help prevent most of the major failing points. He points out some of the key configuration directives to watch out for, differences in some functions' responses based on the OS, and the differences in character sets between a unix-based and Windows based environment (like rn versus just n).
The CodeIgniter framework has made a new release today, 1.6.3, containing updates to fix a few bugs and address some security concerns.
We are happy to release CodeIgniter version 1.6.3 today. Version 1.6.3 is primarily a maintenance release, with a variety of bug fixes and some refinement to existing features (with a few new ones tossed in for good measure). Details of course can be found in the Change Log.
The release also fixes a potential cross-site scripting issue that, while it hasn't been reported as used yet, could still have some bad consequences if found and abused. You can grab this latest version from the CodeIgniter downloads page.
Matthew Turland has come across an "interesting bug" in PHP's stream wrappers functionality - some strange 404 or 500 HTTP errors in one of his scripts.
I wrote a small script a while back that's gained a surprising amount of popularity thanks to a plug from the site that it posts to. [...] I learned that this [connection from the script] could be done with streams, I attempted to implement it in that fashion, but ran into strange issues where I would get 404 or 500-level HTTP errors rather than the response I was expected.
He eventually found the bug related to his problem (in the 5.2.x branch) but happily notes that it has been corrected and will be patched in the upcoming 5.3 (and 6) branches.
According to this post on the PEAR blog, the first PEAR bug triage is now over:
PEAR's bug tracker hit the 600+ open bugs mark a month ago. [...] So with 600+ open bugs (not including the feature requests), we had to do something. [...] The logical step was to hold our own bug smashing event and see how it works for PEAR.
Back on March 22nd and 23rd (Easter weekend) they hunted for bugs. Several developers showed to help out and many bugs were fixed and they managed to bring the number of open bugs for PEAR down to 547 with the two days of work. There were some milestones reached too:
Thanks to the triage, we are close to reaching two important milestones: Closing bug reports with lower bug ID than 1000 (1 bug left!) and 2000 (5 left).
Matthew Turland is looking to "save you some grief" by pointing out an issue he recently had trouble with and eventually found out was a bug in PHP.
It's pretty rare that I encounter a bug in the software I run that hampers my ability to work or my server environment's ability to function normally. However, I encountered one last week that has taken me and several Rackspace support technicians nearly a week to figure out, namely PHP bug #43677.
The issue was that PHP seemed to be "forgetting" the include_path in the current script (not Apache). The bug has been found in PHP 5.2.5 (and possible in all of the 5.2.x releases as well). The problem has been fixed in the latest CVS version and a patch has been created for those that want to correct the problem right away.
Johannes Schluterrecommends that, this Easter, you not only enjoy the holiday and hunt some eggs but also do a little bug hunting at the same time:
Around Easter there are different holidays, in Germany for instance Friday and Monday are holidays. This gives you some time without annoying customers and colleagues asking you to do stuff. So what could you PHP geeks do when getting bored? - A good idea is to test PHP development snapshots.
The PHP group has put out the second release candidate for PHP 5.2.6 and is looking for a few good testers to help them find whatever issues may lie deep in its code. Accoring to Johannes, though, not much should be broken this time. It's PHP 5.3 everyone should really watch out for...
The scenario was that when an array with only one object was returned over SOAP the array was discarded and pointed straight to the single object.
Come to find out, this behavior wasn't a bug, it was a feature - the fix is to add another parameter to the initialization of the SoapClient to add the SOAP_SINGLE_ELEMENT_ARRAYS feature.