The PHP development team announces the immediate availability of PHP 5.5.0alpha2. This release adds new features and fix some bugs from alpha1. All users of PHP are encouraged to test this version carefully, and report any bugs in the bug tracking system.

You can see the full list of the changes in 5.5.0 (so far) in the NEWS file including things like using empty on return values, enabling systemtap by default for dtrace probes and optimized variable accessing. They need your help to make this upcoming release even better, so if you'd like to help out and test, go grab the download (Windows builds).

You've heard of Test Driven Development, but you think; "I've got a horrifying monstrosity for a codebase, it's not testable so I can't do TDD". Let me be the first to tell you that you're wrong. I'm not into writing really controversial pieces, castigating people for not doing things a certain way. If you've considered TDD at any point in time, it's because you understand (at least in the theoretical sense) that having predictable software is beneficial. So this is for you, unconverted developer...

He talks about how using TDD can help you build confidence in your code, make debugging issues easier in the project simpler and how - despite the initial time it takes to implement it in the process - it's worth it in the end. He also includes a few helpful suggestions when your team doesn't want to follow the method.

A lot of the time when we're developing applications they're likely to be based around customizing or extending an existing application, such as WordPress, Joomla, Oxid eSales et al. In these cases, there's a clear set of rules and guidelines to work with. [...] But what about when we're building our own applications, bespoke ones, from scratch. [...] What do we do then? How do we set up a great software development methodology or set of processes to ensure that we develop cleanly, clearly and efficiently? In today's post, I'm going to go through 4 areas which can serve as a solid and reliable basis for us to do just this.

The four key elements he sees are:

• Organized Development Environment
• Organized Deployment Approach
• Organized Testing Approach
• Have a Professional Bug/Issues Database

For each of these elements, he describes some of the methods and tools that can help make them possible.

Normally I feel very comfortable with PHP, but not all is good. There's some things I don't like. One is the lack of real annotations and another one is this rare behaviour with visibility within the OO. Let me explain this a little bit.

The problem came up as a part of a recent refactor where a protected method, when called from an object injected into another class, threw an "access" error that it was called from the wrong context. He reported it as a bug but was reminded of how PHP handles exposure - on the class level, not the instance of a class level.

PHP 5.3.12/5.4.2 do not fix all variations of the CGI issues described in CVE-2012-1823. It has also come to our attention that some sites use an insecure cgiwrapper script to run PHP. These scripts will use $* instead of "$@" to pass parameters to php-cgi which causes a number of issues. Again, people using mod_php or php-fpm are not affected.

The rewrite rule is there in the post, ready for copy and pasting into your config. Even if you're running the latest PHP 5.3.12 and 5.4.2., be sure to use this rule as a stop-gap measure for now. Another release is planned for tomorrow to fully correct the CGI flaw.

A study from Coverity claims that the source code of Open Source projects such as PHP has a low defect rate. Meanwhile, a few weeks ago, the security expert Stefan Esser claims that PHP source security bug prevention has a lot to be desired because PHP core developers do not have the habit of using source code auditing tools to prevent security bugs. The matter of the PHP source code quality and security bug prevention was one of the main topics discussed by Manuel Lemos and Ernani Joppert in episode 21 of the Lately in PHP podcast.

You can listen to this latest episode either via the in-page player or by downloading the mp3 directly. You can also subscribe to their feed to get this episode automatically (and past/future ones too).

PHP 5.3.9 release was mostly meant to fix a security bug, but it introduced a new more serious bug. PHP 5.3.10 was just released to fix this issue. [...] This time it is a bug that allows arbitrary remote code execution. This means that it allows to run arbitrary code on the server, injected by an eventual attacker, so it can be used to cause many types of damage inside a server.

The upgrade to PHP 5.3.10 is highly recommended to prevent this issue from effecting your applications. The post also mentions the dropping of Suhosin support (a security plugin for PHP) on the Debian linux distribution's default installation and how the PHP community has reacted to the decision.

That was a pretty annoying bug. I never did find out what the problem was as I moved onto other problems and chalked that error up to some undiagnosed weirdness on that particular server. From time to time I would get asked on Twitter if I had ever solved the problem. My answer was always "no, and if you do solve it please let met know how you fixed it." Today, my friends, was the day.

Based on a response from Demian Katz, he was able to get around the issue with flag set on the PHPUnit command line - "-dzend.enable_gc=0". Apparently the issue has to do with garbage collection and has been a known issue since the beginning of 2011.

Since the first beta of the next major release of PHP was released a few days ago, I thought we could provide packages for people who'd like to test it and see if there software is still running. And make adjustments or report bugs, if it doesn't. Complaining after the official stable release was made is usually too late, so testing your software against beta releases is very important. For your project and for PHP.

The install involves grabbing their package from the Liip server and calling the "packager.py" executable to make the version swap. You can go back to the pre-installed PHP5 version anytime by updating the symlink back. If you want more information on the package (or to report bugs) you can find the project over in github.

The key issue was that 5.3.7 accidentally broke is_a() for a reasonably large number of users. Unfortunately the fixup release 5.3.8 did not address this 'mistake', and after a rather fruitless exchange I gave up trying to persuade the group (most people on mailing list), that reverting the change was rather critical (at least pierre supported reverting it in the 5.3.* series).

This new issue was causing some strange errors to pop up in his code because of a parameter type change in the is_a call, updating the first parameter to be an object instead of a class name. The is_a() call sends its requests to __autoload in some cases and the string->object mismatch of those parameters causes errors to be thrown. His workaround is, in your checking, just be sure to call an is_object first before passing things off to be is_a() checked and autoloaded.