Stefan Esser points out a problem with the mt_rand and rand methods in PHP that makes them not quite random enough for cryptographic uses.

PHP comes with two random number generators named rand() and mt_rand(). The first is just a wrapper around the libc rand() function and the second one is an implementation of the Mersenne Twister pseudo random number generator. Both of these algorithms are seeded by a single 32 bit dword when they are first used in a process or one of the seeding functions srand() or mt_srand() is called.

He looks at how its currently implemented, some examples of bad methods to get "random" numbers, how shared resources are a problem and an example of a cross-application attack (the application in more than once place using the same method for getting random numbers).

In the comments he recommends either grabbing from /dev/random (if you're on a unix-based system) or making the creation of your numbers a bit more complex to include things the outside world wouldn't know.

PHPClasses.org has posted a review of a recently released book from No Starch Press, "Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems".

n the PHP development life-cycle everyone faces common problems. Considering this, No Starch Press came with a good book named "Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems" written by William Steinmetz and Brian Ward. Wicked Cool PHP is a wide collection of complete PHP scripts that solve specific problems frequently encountered by PHP coders. The book contains 12 chapters covering 76 frequently encountered problems.

He goes through each chapter, mentioning what its about and any extra tidbits it might include. There's wide range of topics covered - everything from the basics of configuring PHP out to security and user/session tracking.

Stefan Koopmanschap had a problem - adding a link to a Zend Framework form (Zend_Form) built from an XML definition:

I was quickly told by the friendly people in #php_bnl on irc.freenode.net that I needed to use Decorators for that, so I went diving into the documentation. Reading the official documentation, I couldn't really get into how exactly the decorators worked and what I could do with them.

It was this article on the Zend Developer Zone that helped him the most, though. He explains his solution, defining the Decorator with a setDecorator method call, and includes the one-liner that made it work.

After hearing Stefan Priebsch's talk at this year's Dutch PHP Conference, something occurred to Derick Rethans - there was a small sort of issue with using namespaces and possible future PHP's own namespace.

One of the things that came up is the conflicts that can arise with internal classes. In PHP 5.3 this would alias the class Interval in the namespace PEAR::Date to the class Interval. For now, this code would work just fine. However, if PHP would introduce a class "Interval" at some point in the future (and PHP can do this as it owns the global namespace) then the above code would suddenly stop working

He offers a simple solution that can prevent this sort of conflict for the future - defining your "use" and then creating a new instance of the namespace into a variable instead of just an "as".

On the KillerPHP blog today, Stefan Mischook comments on whether or not WordPress version 2.5.1 "sucks".

I just recently installed the this latest version of Wordpress (2.5.1) and quickly found it hanging (while trying to load a page) for as long as 40-50 seconds! I then proceeded to isolate the potential causes (database, custom fields, custom theme) and have since found out that something stinks in 2.5.1's core.

He details some of the steps he took to try to track down the bug - installing on another server, searching the web for others with the same issue. His suggestion?

Before you upgrade your old working installation of Wordpress, I would suggest that you test 2.5.1 in some other directory just to be sure it works with your server.

In a new post today, Michael Kimsal walks through the procoess he followed to try and get the most optimized testing environment he could around a WordPress installation he already has set up.

I've recently been working on a project trying to take an existing customized wordpress site and create automated integration tests around parts of it. I'm using phpUnderControl, phpUnit, Selenium RC, Firefox, Xvfb (virtual frame buffer) and...well, I think that's it.

He mentions the two issues he came across, both with the WordPress software (the "siteurl" setting and the pathing for the templates). He recommends that application code be portable to avoid problems like these. Applications that can be dropped in anywhere and "just work" can help not only make life easier for the installer but also for the tester.

Michael Kimsal has put together a small page to help you get started using the phpUnderControl continuous integration system:

If you're not using phpUnderControl, you owe it to yourself to check it out, as I think 'continuous integration' will likely change the way you think of development. I've used CruiseControl in the past for PHP, but the PHP-specifics phpUnderControl brings to the project are too much to pass up.

The page mentions some of the common issues you might have in getting started - installation problem, the use of the PHP Code Sniffer and the Project Mess Detector from PHPUnit.

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).

In some thoughts related to the just-passed religious holiday, Alan Knowles decided to come up with another series of 7 deadly sins one could commit in their PHP (CMS) development.

Among those on the list are things like:

• Defines for configuration
• Filenaming
• If your code is public, you should try not to ridicule yourself.
• Mixing PHP and HTML

Check out the rest of the post and some of the interesting comments that follow.

Eirik Hoem has posted an update on a previous problem he was having when working with SOAP in PHP and its handling of arrays.

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.