In his most recent post Anthony Ferrara gives a lesson in security prompted by the recent major issue with a SQL injection vulnerability in Drupal. He gets into detail about the vulnerability itself and the ultimate question: "how could this happen?"

Recently, a severe SQL Injection vulnerability was found in Drupal 7. It was fixed immediately (and correctly), but there was a problem. Attackers made automated scripts to attack unpatched sites. Within hours of the release of the vulnerability fix, sites were being compromised. And when I say compromised, I'm talking remote code execution, backdoors, the lot. Why? Like any attack, it's a chain of issues, that independently aren't as bad, but add up to bad news. Let's talk about them: What went wrong? What went right? And what could have happened better? There's a lesson that every developer needs to learn in here.

He details (complete with code examples) where the vulnerability was, how it could be exploited and what the resulting SQL would look like when it was abused. Fortunately, the fix for the issue was relatively simple, but fixing is easy - distributing that fix is much more difficult.

How did this happen? Everyone makes mistakes. Everyone. It's going to happen sooner or later. Heck, this vulnerable code was in the database layer since 2008, and was just discovered two weeks ago. That says something about how complex vulnerabilities can be.

He suggests that the bigger lesson here isn't about who made the mistake or even the code that caused it. It's more about how it was handled, and that, in using any kind of CMS/framework like this there's always risk. People are human, people make mistakes - "the key is how you deal with it".

If you've been developing any PHP at all recently, you've probably heard about the Composer package management tool that's caught on like wildfire in the community. If you're not currently using it, you might wonder what it's all about. Well, in this recent post on the Fortrabbit blog, Ulrich Kautz explains the tool and how to get started using it.

Composer describes itself as "a tool for dependency management in PHP". It uses a large repository of packages which is continuously extended and maintained by the community. It is now out there for about a year or so. This article goes out to everybody who is not already using it: we want you to give it a try it and here is why.

He talks about what Composer is (really a "dependency manager" more than a "package manager") and why its a good thing for projects to use. He gives the quick install instructions and an example of setting up a "composer.json" file to pull in the Twig templating and Doctrine ORM libraries. There's also a quick mention of including the Composer autoloader so it can find the resources correctly.

In a new post today Patrick Allaert has continued his "Readable Code" series with some tips on how you can make your API handle more.

His suggestions include:

• Changing the handling to look for multiples by default
• Avoiding inner looping (repeated looping) and try for code reuse
• Transforming a scalar value into an array to make it easier to handle this way (by casting)
• and how to handle objects in the same array-handling kind of code

He also tosses in a little mention of performance, noting that a call with range in the argument to his array-handling method is faster than looping over the same range and calling the method each time.

If you're a NetBeans user and have been frustrated by it's default handling of non-PHP extension files as PHP, you should check out this new post from Sachin Khosl on digimantra.com on how to fix the issue.

You love coding in Netbeans and you find it pretty uneasy when it does not function the way you want it to. That was the same with me when I started development in drupal and I was unable to associate the .module as PHP in my favorite editor Netbeans. However with little play around with options I was able to associate .module files as PHP file in Netbeans IDE. So for doing so follow [these] steps.

You can change the setting for plenty of different extensions (and add your own custom ones) in the Options under the Miscellaneous section's Files tab. Check out this screenshot to see the location.

Marco Tabini has taken a different tack on error handling in his latest post. He suggests that developers need to spend a little less time trying to prevent so many errors and a little more time handling the ones that do happen.

When an error occurs, the vast majority of the web-based application code that I see during my reviews performs the software equivalent of running around with its head cut off: the developer spends an inordinate amount of time and resources trying to make the software look like what was essentially a catastrophic failure was nothing more than a small temporary hiccup.

[...] In reality, by the time an error has occurred, there are only two possible outcomes: either you expected the error to occur, in which case you have already written code to handle the failure, or you didn’t, in which case your main focus should be to use the error as a learning opportunity.

Marco suggests alternatives to this usual worry and hysteria - spend more time ensuring that (if something does fail) there won't be any more damage, let the IT team know as soon as you find the issue and testing before you fix (reproduce the error before you dig in to try to fix it).

DevShed has posted the latest article in their "introduction to views in CodeIgniter" series - a look at working with the views to add more layout/design to them with CSS.

Now it’s time to continue exploring the capabilities given by CodeIgniter when it comes to handling views. Since the visual appearance of the web page mentioned above was pretty rudimentary, in this second article I’m going to improve it a bit to make it look more appealing and professional.

To add in their CSS, they update their header_view.php file to includes the styles in the template. The views for each block are then loaded via the controller - header, content and footer areas.

Chris Jones has changed his stance on something he's been recommending PHP users compiling the OCI8 libraries into their installation - the use of enable-sigchild.

I am no longer blindly recommending using --enable-sigchild when configuring PHP with the OCI8 extension. I used to do this as a catch-all. It might have saved some users grief, and did little harm. With changes in recent versions of Oracle and my gut feel about common usage, it will be less confusing not to mention it as a general suggestion.

The point of using the compile flag was to help with the opening/closing of connections to Oracle server processes, but there's a better way he recommends now - using a "BEQUEATH_DETACH" option of "YES" in the sqlnet.ora/Apache config. If that doesn't work, then look into recompiling with the enable-sigchild option.

Jani Hartikainen has written up a new post looking at error handling in one of the more popular PHP frameworks - the Zend Framework.

In Zend Framework based applications, error handling is typically done using the error controller, but there are different ways to send the execution to it - some better than others. Let’s look at some ways to trigger the error controller and how to have it handle different error conditions.

He walks through the steps to create the Error controller, change the front controller to use it and add in a few different kinds of actions to handle the various error types that might come up (like "page not found" or "not authorized"). Errors can then be forwarded to each of the actions by the resource the visitor errored from. Of course, he also mentions that exceptions can do something even better - handle the error without all of that messy forwarding around. (There's an example of that version too).

Johannes Schluter recently looked at one of the new features coming with PHP 5.3 - the goto functionality:

Over the last few days I already mentioned a few hidden gems from PHP 5.3. Now at Christmas I wanted to take a look at some new language feature of the upcoming PHP version: Added "jump label" operator (limited "goto"). (Dmitry, Sara)

No, its not the sort of "goto" you're thinking of - its a bit more limited than that. Johannes mentions that it only allows you to jump within the same execution unit and you can't jump into loops. Used incorrectly, it can be bad but he points out two useful instances - one being a code generator and the other an instance where you might need to drop out of code but not kill off the script in the process (sample code is included for this second one).

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.