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.

PHP has a couple DNS functions you can use to perform record lookups. Most of us are familiar with the two basic ones - gethostbyname() and gethostbyaddr(), both of which perform a single function '" returning a hostname or IP address.

She also mentions the gethostbynamel and dns_get_record functions that can give you even more insight into the current DNS of a given domain (even returning only record-type specific information).

A web application goes through some stages when growing up. Generally, it starts from development and ends at production. There can be some more stages within this two ends. And, in maximum cases this stages are overlapped. [...] In this situations, if we want to keep bootstrap in SVN repo, it needs to setup bootstrap in a little different way. So that, it can handle many server settings with a single bootstrap.

He sets up some assumptions (like a familiarity with the Zend Framework), some of the files you'll need to download and how to use them to set up your host for the multiple-site bootstrap. The different sites are defined in arrays at the beginning of the file and are compared to the current hostname. The correct include paths are then set and the bootstrap script continues on.

This is really handy for those of us who have the same code handling multiple sites or multiple sub-domains. A case in point: When I coded NetBoardz (my free forum hosting service now defunct), I had one codebase handling all 250 forums. How? Simple. When the code runs, it determines which site the user is loading and does different things (like using different databases) dynamically.

He shows the two key points to dividing things up - grabbing the domain and subdomain they were trying to access. This can be fed into a script that can switch things like layout or even functionality based on which site they've chosen.

One of the implications of following the rule is related to the whole www vs no-www question. Basically you should always use www if you're planning to use any other sub-domains and you want them cookie-free. This is because you have no way to set a cookie only to the top-level domain.

His code sets cookies for the ".phpied.com", "phpied.com" and "www.phpied.com" domains. Since the domains without the "www" offer a bit broader range of possible matches, he recommends that if you're ever going to use any kind of subdomain, you'll want to use the more broad cookie to cover it.