If you're a CakePHP user and have been frustrated by how this "bake" functionality doesn't allow for more than one validation rule on a given field, check out the new post on the SaniSoft blog (from Amit Badkas):

This is not much of a problem if you have only a few models but when you start to work on several dozen models in a project it becomes very tedious to open each and every model file to make changes.

The result of his frustration has come out in the form of a patch as a part of a new ticket in the CakePHP request submission process.

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

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.

Ben Ramsey has recently blogged about some of the research and bit of development that he's done to add "more correct" functionality to the Zend Framework for working with RESTful interfaces - proper PUT and DELETE support.

I've recently been wrapped up in an effort to design and implement a RESTful API using the Atom Protocol for a project at work. We are using the Zend Framework as the underlying framework for the project, so, in order to follow the Atom Protocol, I needed to support the HTTP methods PUT and DELETE

Since the Zend Framework has been playing such a prominent role in the development, he's been digging into the Zend_Rest_Server component code and isn't too happy about its support for PUT and DELETE. As a result, he's proposed methods that might help resolve things such as isGet, isDelete, isOptions and getEntityBody. He' even created a patch to make the needed changes.

The Developer Tutorials blog has posted their "winner" of a list of things to do to keep you and your website secure:

When it comes to PHP security, you often think of input filtering, SQL injection prevention, XSS in user submitted content and so on. Well, forget about that. They're all pretty trivial compared to what I feel is by far the most important security issue of any web application. Read on to find out why.

Their number one thing to do to keep safe and secure? "Keep your systems updated." They point out that security a web site is one thing but securing the system that it runs on/has been developed on is another (and improperly patched, it could cause some huge problems).

Now, the best way to keep on top of potential vulnerabilities in your underlying systems is with updates. Sometimes, however, you need to go a little further. [...] Watching the web is also a good idea; major security vulnerabilities generally make it to the front page of Digg.

Christopher Jones talks today on his blog about a bug he's just corrected and integrated into the release of the Oracle Instant Client that lets PHP correctly take advantage of the temporary LOBS functionality.

When PHP is done with the temporary LOB, it needs to tell Oracle to destroy it. If this isn't done, then the temporary LOB will hang around using DB space until the connection is closed. I just merged a fix worked on by Krishna Mohan and myself for bug 43497.

Example code is included showing two instances of its use - a normal use that frees the memory correctly and the other showing how to create the temporary lob to hold the data as needed.