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.

In the first they detail more of what the bug is, how it could be exploited and link to the original advisory for the problem. Also included are more details on the issue, including sample avenues of attack.

In the second post they look at the recent PHP release and note that it does not completely rid the language of the problem. They point out that the Rewrite rule that's included in their post (not the one on PHP.net) should be used to prevent this issue from effecting your installations.

When it comes to optimization, there are two competing viewpoints in the PHP community. Some say that optimization should only ever be an after thought and to avoid premature optimization at all costs. Others will say that this is impractical, and you should make your application fast as you write it, since then you won't have to go back and clean it up to make it faster. While I can understand the viewpoints of both sides, I am firmly in the former category.

He talks about the "90/10 Rule" of development (most of the work is done by only a small part of the code) and what that critical 10% could be made of. He also touches on the "60/40 Rule", "instinctual optimization" and the emphasis people put on benchmarks for their tool or framework of choice.

Let us start with some architecture basics behind PHPMD. All rules in PHPMD must at least implement the PHP_PMD_Rule interface. You can also extend the abstract rule base class PHP_PMD_AbstractRule which already provides an implementation of all required infrastructure methods and application logic, so that the only task which is left to you is the implementation of the concrete validation code of your rule.

He walks you through some sample code and talks about some of the common interfaces that are available to your testing. He takes one of them, IFunctionAware, and looks at it specifically, showing how to use it to detect and add violations for the validation. He includes an example of writing a rule based on an existing software metric (in this case, the number of public methods). There's also bit at the end showing how to write a rule based on the "abstract syntax tree" to be able to check just about anything in the code you're looking to test.

PHPMD can be seen as an one level down/low level equivalent to PHP_CodeSniffer. It is a simple command line tool that can be used to check your application's source code for possible bugs, suboptimal or overcomplicated code. The current release of PHPMD ships with three default rule sets.

The first deals with code size, the second checks for unused variables and the like and the third looks at naming conventions. He shows how to take one of the structures from one of these three and create a new rule. For his example it's a measurement of cyclomatic complexity. He also shows you how to exclude certain rules that might come in another set so you don't have to completely redefine to use pre-existing rules.

The latest release of PHPMD can be pulled from pear.phpmd.org or from its github repository.

Quite often have I been staring at my virtualhost setup for the admin subdomain of this application, wondering why the hell it kept serving the frontend. I'd set the DirectoryIndex to backend.php, so why did it keep serving the frontend?

The culprit was something that's usually one of the first things set up when you load a new framework - the mod_rewrite rules in an .htaccess. Of course, since they were the default, things would get routed back to "index.php" instead of his "backend.php" as he wanted. To fix it, he moved these options out of the .htaccess and into the virtualhost configuration.

I'm in the process of creating the website for my upcoming book *and* had recently switched back from using Apache to using Nginx again, so I thought it might be time to roll up my sleeves and figure out how to make it work in a subdirectory. After much gnashing of teeth and pissing and moaning, I figured it out.

A simple configuration example is included as a part of the post showing how to correctly configure the rewrite routes to catch everything and send it back to the index.php file. His is a two-part process: it tries to match anything with "/foo" in it then, if it wasn't caught there, it sends it off to be rerouted to the front controller.

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.

Many people probably think the PHP Throwdown has stalled, but it's quite the contrary actually. We've been mulling over many things and have come to some conclusions. So if you're interested, read on!

The judges have been found, the categories are still being decided, prizes are en route, Jupiter Hosting has stepped up as a sponsor for the event, registration is coming soon, and the rules have been posted.

Be sure to check out the main page for complete details on the event. The PHP Throwdown is a competition to see what can be accomplished with PHP in 24 hours. Who: You! You can compete in a team, or individually.

You might have noticed that Digg has a cool way of maintaining clean URLs. Digg actually uses LAMP - Linux/Apache/MySQL/PHP. But where are the .php extensions? The answer is here. 4 steps to implement your own Digg style clean URLs.

His method turns on Apache's rewrite engine (you do have mod_rewrite enabled, don't you?) and adds a rule to push all of the requests to two default PHP files. There's also a ForceType method that can be used to achieve the same effect. One .htaccess file later, you're in business and the PHP script only needs to access the $_SERVER['REQUEST_URI'] value to get the parameters.