Brandon Savage has a new post about a key concept that both new and experienced developers need to remember when working with user input - Filter Input, Escape Output (FIEO).

Brand-new PHP developers have drilled into their heads the concept of Filter Input, Escape Output (FIEO). This concept essentially insists that all user-provided content be filtered or escaped, without exception. With the delivery of PHP 5.2.0, this got a lot easier, because PHP included, by default, the Filter library.

He gives two examples of an email validation method - one using a regular expression and the other using the filter_var function of the filter extension with the FILTER_VALIDATE_EMAIL constant for the type.

Keith Casey has a suggestion for budding (PHP) developers out there looking to jump head first into their first project: "Don't trust the users."

Recently I taught a class of bright-eyed, bushy-tailed PHP'ers just getting their start in the world. They haven't done their first production application and we were working in the "safe" confines of a classroom, but there was one concept that I pounded into their heads: Don't Trust the Users.

Generally, as Keith mentions, users aren't malicious/incompetent/ignorant 99 percent of the time, but there's always that off chance that they are and you need to protect you and your application from it by filtering input and escaping all output to prevent any mishaps.

Adam Jensen has a new post to his blog today looking at a solution he's created to be able to access the raw input a user has entered.

I've run into a minor problem, and I'm not sure my solution is particularly ideal. See, the Zend_Form approach described above does a great job of implementing Chris Shiflett's Filter Input, Escape Output principle...user input is filtered for invalid HTML before it's ever saved to the model, and can then be escaped as appropriate in the view layer. But what happens if you need to be able to retrieve the user's original unfiltered input later?

While working with the raw data could be dangerous, he has created a custom model that, through the getters and setters and doing validation/sanitization and the presentation layer rather than behind the scenes. It's not ideal but he's willing to take suggestions...

Derick Rethans has made a quick post about an update he's made to the XDebug function traces to add in information on variable modifications.

After I had a quick look at the feasibility of this feature I spend some time on implementing it for Xdebug's HEAD branch that is going to become Xdebug 2.1. Variable modification tracing can be enabled by setting the php.ini xdebug.collect_assignments setting to 1. Of course this can also be done in either .htaccess or by using ini_set(). This setting requires general execution tracing to be enabled as well and it's only available for human readable trace files (the default format).

He gives examples of how two example scripts would be logged to the trace file - one inside of a basic function and another showing updates to the properties on a class.

DevShed has posted the next part in their series looking at using the XDebug extension. This time they focus on the var_dump function and the enhancements the extension brings to the table.

As you may know, "var_dump()" is a PHP native function, but the X-debug library provides an enhanced version of it that's capable of retrieving much more information about a supplied variable. These capabilities greatly extend its usefulness in debugging.

This enhanced version of var_dump displays not only the usual variable information (types, value, etc) but also allows for more advanced output like the object definition, including properties, in their example.

In a recent post Fabien Potencier took a look at one method for getting metadata information from a subversion repository about the project(s) inside.

Last year, I deployed a new tool to manage symfony plugins. The first goal of this tool was to simplify the process of contributing new plugins. [...] The question I wanted to answer was quite simple: How many plugins were created per month before and after the change?

He uses a very handy option to modify the output of an "svn log" command - the "--xml" argument. This outputs the latest information (like author, date, paths and msg) for each of the log entries. This can then be thrown into a call to simple_xml_load_file and parsed down into the numbers he was looking for. He even generated a graph of the results as they coordinated with the different symfony releases.

Sameer has put together a few images, the results from the Wordle website when he plugged in the names of the built-in functions included in PHP.

The application is simple. You enter a bunch of text and Wordle does the rest. The applet provides options to change color, font and layout. Just for fun I created a Wordle cloud to display php's built in functions. Two samples are shown below. The size of the font in the cloud is proportional to the number of functions starting with the particular name.

Among the largest on the list are words like "array", "get", "mysql" and "mcrypt". He used a call to the get_defined_functions() method and looped through the "internal" subarray to build his lists.

Kae Verens has posted a quick tutorial about serving up files by routing them through a "fetch" script, pulling their contents in one side and back out the other.

One thing I need to do while building the multi-user version of webme is to convert it so file references such as /f/photos/an_image.jpg get transparently converted so they serve correctly, even though the actual file may be located somewhere entirely else.

There's two steps involved - rewriting the URL request for the types of files you'd like to pull through the script (using some mod_rewrite magic in Apache) and make the script to do the actual work. Source for that is included too. Not only can something like this help you keep things organized but it also allows for extra security if you need to store the files outside of the webserver's document root.

Sebastian Bergmann as a new post talking about a few of the features of the PHPUnit unit testing framework, especially test isolation.

Some of PHPUnit features come with the cost of a performance penality. This posting explores the effect of the --no-syntax-check, $backupGlobals = FALSE;, and --coverage-html options.

He compares benchmarks for a test with few different settings - $GLOBALS, syntax check and code coverage (including graphical output of the execution times on the various parts of the tests).

NETTUTS.com has posted the third part of their series on creating a simple PHP5 framework today:

Now that we've got a basic framework (see part 1 and part 2 of this series), we can start thinking about integrating designs with our PHP framework. For now, we'll concentrate on the front-end design, including how we can make it easy to 'skin' our new framework.

This part looks mostly at the HTML and CSS for the presentation layer (the views) to make a simple two-column layout with some basic image and text content.