Quite a while ago I looked at using the filter_var() function to validate URL's using the FILTER_VALIDATE_URL flag and someone pointed out recently that this function has not only changed since the initial release, but that a number of flags can be added to change the way that this function works.

He lists some of the other flags that are now available that can be used in conjunction with FILTER_VALIDATE_URL to get more fine-grained in your filtering - checks on things like a required scheme, hostname and query string. He includes some code with a set of URLs to run through some tests and output as a table with the pass/fail rank of each URL value. You can see the resulting output here.

In this tutorial we will build an online bookmark system. This will be used to create a database for storing all our URL's and their descriptions. There are many commercial and non-commercial applications that offer almost the exact functionality that we will create in our application; the difference is that we have full control over our application, allowing us to tweak it to suit our needs.

The application lets users login/logout, manage bookmarks, gives recommendations based on those bookmarks, show some news headlines and, most importantly, the user must be able to personalize their interface with a custom color scheme and image of their choosing.

This first part gets up to the point of creating the databases (a bookmarks and users tables) and creating the basic template wrapper for the entire site.

Namespaces are potentially coming in PHP 5.3 (does anyone believe?) and people start discussion about how they can even shorten their names from Abstract to aSomething and from Interface to iAnotherthing. I'm a fan of short names. [...] I agree with these rules and am of the opinion that class names must all above anything contain a semantic. Interfaces indicate what you can do with an object, while abstract classes model that different classes have a common base and can be used in the same mannor. And indeed you can add these semantics to names without using the terms.

He gives a few examples, things like Persistable, Configurable and Reflector.

From the first tip:

Don't rely on obscure names to keep your application safe. You should always check permissions, test for vulnerabilities with testing tools and keep an eye on your log files for suspicious activity. When designing your applications and web sites though, don't make it easy for bad people to do bad things. Don't use default or common names for your files and directories.

And from the second:

It's a sad fact of life but users are evil. Users want nothing more than to find a way to exploit your application. As soon as you let your guard down and start thinking "I'm only selling small stuffed animals so how evil can my users really be?" you've lost the battle.

You can catch up on these and the other previous security tips on this page on the Zend Developer Zone website.

There have been no fewer than 4 different proposals floated before, but this one combines flexibility, performance, intuitiveness, and minimal architectural changes, and has only a couple of small drawbacks. Let's take a closer look.

He details the functionality - what it is, what's been decided on, and the advantages of the method. The basic approach is a "lazy" one where PHP will only store the request when it comes in, no filtering or anything, until you want to do something with it (i.e. get it via $_GET, $_POST, etc). When the request for data is made, PHP looks at the encoding settings and formats the data accordingly.

Advantages he mentions for this method include removing the guess-work on PHP's part for which encoding the request is and that it removes some of the overhead by not processing the data until it's actually needed.

I promised to investigate the steps needed to set up DokuWiki with the simplest authentication scheme for a friend and I thought others might benefit from it too, so here it is.

There's about fifteen steps in all, including the download/install of the package and creating the basic functionality (like a simple Auth schema - he gives an example). Create the superuser and set up the desired restrictions and you're home free. If you want more information on authentication in DokuWiki, check out this page on the DokuWiki's wiki.