In this recent post to his blog Johannes Schlüter he talks about a way that he's come up with to test functionality that uses persistent connections (and an module he created to help).

In a few rare cases this is not what people like, for that PHP introduced "persistent connections" of different kinds. Testing those is a bit annoying as you have to configure a webserver and ensure to hit the same instance over the course of a test and then use a load generator, probably one which can detect a failure. Additionally by having a webserver in the game there is more code being executed, which might mean an additional source for trouble while debugging. An alternative might be using FastCGI, while that adds it's own issues for such a test. To solve this for myself I, some time ago, wrote a PHP SAPI module called pconn and pushed it to github.

The extension provides a way to emulate requests by executing a script multiple times automatically, making it easier to test things that require checking against multiple things simultaneously. While the built-in webserver (PHP 5.4) can be used to test some of these things too, Johannes' extension can also be compiled to help with testing of threading in applications as well.

On DevShed today, there's a new tutorial posted looking at two things that can cause headaches for PHP developers (especially when evaluating and comparing values) - nulls and empty strings.

Anyone who has programmed for any length of time has encountered the concepts of null and empty strings. They are not the same, and confusing the two can cause some serious problems. This article deals with these concepts in the context of PHP and MySQL.

They start with a bit of a quiz before getting into how to handle them correctly - making null "safe" and working with it correctly in a MySQL context. SQL statements and table structures are included for their examples.

On his blog, Mike Lively has posted a look at some of the work he's been doing on patches for the late static binding functionality to be included in PHP, including an example of the updates in action.

This weekend I wrapped up a few small tests and sent the patch in and it was subsequently pushed to php 5.3 and php 6.0. Now, this is not at all the way I wanted things to work, in all honesty I think the patch is pretty hokey but unfortunately nobody really spoke up in support of the changes I wanted to make to parent:: in regards to LSB.

His example shows how to override a static method and push that new method's execution to the parent class (in two ways - safe using forward_static_call and the not so safe calling itself with a parent:: override).

Andrei Zmievski has posted an encouraging note on his blog about the progress of PHP6 concerning the number of functions that have been correctly converted to support Unicode.

Well, PHP boys and girls, this feels like quite a milestone: 50% of the 3084 functions that are bundled with PHP 6 have been upgraded to support and work safely with Unicode.

He includes a small chart beside the post as well showing where things are currently at like the safe vs unsafe functions.

Tobias Schlitt has a great (long) post responding to a proposal made on the php.internals mailing list for the inclusion of "taint mode" in upcoming PHP versions.

Tobias starts with an overview of what "taint mode" is so that everyone's on the same page. His example involves the incoming and outgoing data usually involved in an application and how the incoming can be the most problematic when it comes to the values inside. This is where taint mode can come to the rescue. At its most basic level, it's a method for, assuming everything coming in is "tainted", creating a mechanism to automatically clean the data before it's even touched.

With the basics down, Tobias looks back to the proposal for a few additional comments. He considers the proposal a great way to introduce the functionality to the language. There are some draw backs he mentions, though, including the additional overhead of working through every inputted value.

Overall, I think this whole thing would be a great addition to PHP and I hope this could come for 6.0. What do you think?

You can also check out some other opinions on the matter:

• "Tainted mode" pour php on the Kamelot Blog

In an effort to get some thought going about ways to encourage security in PHP applications, Stas has posted an idea about a simplified php.ini setting - production=On.

His idea is that, with this setting on, the PHP installation would:

• disable display errors
• disable phpinfo()
• turn expose_php off
• make max_execution_time/memory_limit reasonable
• and possibly a few others that some developers forget to set correctly

On the PHP Security Blog, there's two new posts concerning their Suhosin patch for PHP - one talking about a remote code execution vulnerability found in the uploadprogressmeter extension (which as already been corrected) and the other dealing with the "stealth mode" of the patch to find compatibility problems.

As mentioned, the issue with the uploadprogress extension has been fixed and as been introduced into the PECL repository. The other post just mentions what the patch is doing to try to keep compatibility problems from happening due to back extensions and/or modules being loaded in an application.

More details about the Suhosin patch can be found here.

A new release of the Zip PECL package has been made according to this post on Pierre-Alain Joye's blog today. The main update in this release is to counteract a Windows bug that's interfering with binary file opens.

The issue is actually a windows bug. No matter if I give or not the "b" flag to fopen, the write operations are not binary safe. It seems to be a known issue as many projects use the same trick.

The problem comes up when PHP forces the binary mode in SAPI and CLI, making the binary writes to a file non-binary safe no matter what. Pierre is also asking for help from anyone out there with any information/bug reports/references about this issue that would yield something useful.

The answer is very simple - watch John.

When John migrates, to me it means two things in particular;

• If there is a performance hit vs. the older PHP version, it will be an acceptable one.
• There are no show-stopping bugs.

It's an interesting standard to set for the adoption of something as beneficial as the move from PHP4 to PHP5, but it is one way to judge the effectiveness. When you see the major applications tailoring their setups for PHP5 environments, it might be time to consider jumping ship yourself...