Matthew Turland has posted a call to action for all of those PHP developers out there content to sit back and just request features for the language - get up and get involved!

A question that seems to be popping up more and more these days is, "When will PHP 6 be released?" It's especially annoying because the people that enjoy an exercise in futility ask this question are the same people that simply refuse to take WIR [When it's ready] for an answer. Or maybe they just read into the hype generated by trigger-happy publishers who want to preempt a stable release, I don't really know.

He points out some of the current stats - PHP 5.3's beta release date as coming to the original date, that PHP 6 code hasn't even been moved outside of CVS and the amount of work left to be done on it before its even close to being ready. This is where you come in - the internals folks contribute their time (off-hours usually) to developing the language and can only do so much:

So respect them and their time and stop asking when it's going to be ready, because they don't really know much better [about PHP6] than you do.

He also suggests two other things that you can do to keep up with the current state of development - keep your version updated and track the RFCs to see what features are being added and any bugs that might still be open for pre-release. You have to be proactive about keeping up with the current status - otherwise, you have no room to ask, over and over, "when will it be done?"

As was previously mentioned by Christopher Jones, the PHP 5.3 branch is now under a feature freeze. Lukas Smith has posted a few more details about the upcoming release.

Last thursday was the begin of the feature freeze phase. Well its not really a hard feature freeze in the sense that we still have plans for a few new features and tweaks, but it means the end of the "maintainers freedom" that usually rules PHP development more or less.

New features will have to go through either him or Johannes to be included and they are doing their best to get the alpha 1 release of this new version out by July 31st.

Lukas is also trying a more unconventional approach to bug fixes to try to get the major ones knocked out first - posting them as a comment to this blog post. So far, no comments on bugs have been added, but there are a good number to get through. To help narrow it down he's also put out a plea to developers out there to help validate current bugs to potentially knock off a few of the ones that can be marked bogus.

Andrew Johnstone has posted some of his experience he's had developing with one of Zend's latest offerings - Zend Neon. Neon is the Zend project to bring robust PHP development functionality to the community on top of the Eclipse platform.

I've been using Zend Studio for Eclipse (beta) for several weeks in a rewrite of a framework and numerous sites at work and overall I really like the IDE. Its got some great features and being based on the eclipse project makes it really extensible and customizable.

He happy overall with the IDE but has come across some bugs in his time developing in it (nine of them) with issues ranging from the SVN functionality and samba out to small syntax sorts of things (like the auto-formatting).

Derick Rethans has announced today (briefly) the release of the Release Candidate version of his PHP debugging package - XDebug 2.0.0RC3.

I just released Xdebug 2.0.0RC3 through the web site and also through PECL. This hopefully last release candidate of Xdebug 2.0.0 addresses a number of segfaults and other small bugs that crept in in Xdebug 2.0.0RC2.

The Xdebug extension helps you debugging your script by providing a lot of valuable debug information. The debug information that Xdebug can provide includes the following: stack and function traces in error messages, memory allocation, protection for infinite recursions.

In part of an effort to work out some of the 'kinks' in PHP (as far as the security of the language itself), Stefan Esser has proposed a "Month of Bugs" for PHP. The idea is to release security issues found, one for each day - the month's hasn't been specified yet - with complete vulnerability information.

While it is true that many PHP applications are written by people with no clue about security it is absolutely not true that PHP is a secure programming language. I think it is necessary to make ALL people aware of this.

No word yet on when this month will start, but we will keep you posted as soon as it's out. If you'd like to check out the community's response to this effort, check out some of the comments already posted to this announcement on the PHP Security Blog.

On the O'Reilly OnLamp.com site, there's a bit more in-depth look at using the (now infamous) Google Code Search to locate issues with scripts that have been collected over time.

I've written about using Google to find security flaws in the past. However, thanks to Google Code Search, it is now easier to scan publicly available source code for potential security issues. The idea is query Google Code Search using techniques previously reserved for local static code analysis.

The examples he gives include a search for SQL injection in a Java application, a SQL injection in a PHP application, and a cross-site scripting problem in a PHP app blindly echoing out the user's input.

He also includes a few links to some code analysis tools that can be used to help prevent some of these issues - Flawfinder, RATS, and SWAAT

First Andrei posted a note about it and now Scott Mattocks has made his own comments on the release of the PHP-GTK 2 Alpha version .

This is the first release of PHP-GTK 2. PHP-GTK 2 is a PHP extension that combines the power and flexibility of both PHP 5 and GTK+ 2 to allow developers to create stand-alone desktop GUI applications using PHP.

Scott reminds all potential users of this release out there that this is most definitely aplha and shouldn't be used in production due to some bugs and feature changes that will need to be resolved.

If you're still interested, you can grab the download from the PHP-GTK site and check out the new manual or subscribe to the mailing list for a little help.

PEAR, the large repository of useful PHP libraries, is steadily growing even more in popularity. The PEAR server packages introduced have made it even easier for people to share their own libraries with the world. Unfortunately, all of this useful code doesn't come without a few issues, and in this new blog post, Lukas Smith mentions the top five packages with the most number of bug reports.

The 5 packages with the most bug reports are all pretty popular although the quality of the code varies. They are all also fairly complex and/or large. I have gone through the bugs of most of them now and then to see if I spot an obvious bogus report.

As of the time of this post, the top five are:

• Spreadsheet_Excel_Writer
• SOAP
• HTML_QuickForm
• Mail_Mime
• PhpDocumentor

Lukas also puts out a call for help, hoping that there are users out there that would like to help conquer these bugs, to help out with making the packages a cleaner place. All it takes is a little time, some inititave, and a glance at the bug reports for the packages to get started.

In this post on Bitacle.org, they look at a 5 minute approach to finding some of the more common issues with PHP web applications.

Detecting and correcting problems with applications at early stages is an important role of the server manager. Unfortunately, not all errors are detected at the testing stages. Even more unfortunate is the fact that most errors go undetected because they are usually triggered when a certain set of criteria is met.

Since all you have is 5 minutes (which is one of the tenets of this Server management series, and quite possibly the only simple truth in your case), in this installment, we'll unlock the secret of server log foraging.

They mainly make use of grep, a very handly unix command-line tool, to parse through the server logs for answers. Combine that with upping the error reporting level inside of PHP itself, and you should be able to track down most of the problems you'd have. They also include a sample situation or two to watch out for specifically.

With Greg Beaver helping out Joshua Eichorn on the "bug squashing" in the phpDocumentor project, there have been several bug-related emails that have come their way - and not all of them good. So, in this latest post on Joshua's blog, he offers some suggestions that would make the emails easier on them.

phpDocumentor Bug submission guide:

• phpDocumentor Version
• PHP Version
• OS Version
• How your running phpDocumentor, CLI, CLI+ini file, Web interface
• Instructions on howto reproduce the error
  • A simplified set of code to parse that produces the error
  • How you have phpDocumentor configured, an ini file being the prefered way rather then a mile of command line parameters

He also notes, of course, that patches are always welcome (as built off of version 1.3.x in the PEAR cvs).