As the Laravel News site mentions in one of their latest posts, the Laravel Homestead project received an update recently that makes it easier to install per-project rather than the previous "one install for everything" setup.

Over the weekend, Homestead received a new update that allows you to run it on a per project basis. Previously Homestead was designed so that you install it once on your system and share all your sites within the virtual machine. Joe Ferguson created the pull request to help get this feature implemented and he has a full write up on his blog.

This change pulls in the functionality doing all the hard work for you. It copies over needed files and setting up the Homestead vagrant instance directly from inside the project. Joe also describes the command line options you can provide, defining a name and hostname for the new instance. You can find out more about it in the official documentation.

From the HashBangCode.com site today there's a new post that revisits filtering with the filter_var function included with the language. The focus in this article is specifically in validating URLs with the FILTER_VALIDATE_URL flag.

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 a handy little post to her blog today Vanessa Vasile has an example of how to use built-in PHP functions to perform DNS lookups in your scripts.

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).

Anis uddin Ahmad has a handy bootstrapping example for those that might want to use the Zend Framework for more than just a single site.

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.

John Rockefeller has a tip he'd like to share with all of the other PHP developers out there - a little method he's come up with to host multiple domains off of the same code.

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.

Stoyan Stefanov has come up against one of the frustrations of web development involving cookies - problems caused by the switch from a "www." in the host to none. He's come up with a test to show you how cookies are set and where you can access them from.

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.