On the Pineco.de blog there's a tutorial for the Laravel users out there showing how to set up subdomains in your application using the built-in framework functionality (and their setup with Valet/Forge).

Often we need to handle subdomains with our Laravel application. Let’s take a look, how can we treat the routes dynamically and set up the subdomain with Valet and Forge.

The tutorial then walks you through the steps to get subdomains working:

• Defining Subdomains in Our Routes
• Dynamically Generate Subdomains
• Faking Subdomains in Valet
• Setting Up Subdomains in Forge

Each section comes with a brief explanation and any code or configuration changes that would need to be made to make it all work.

Matthias Nobak has continued his series of posts covering software architecture and class structure. In a previous article he talked about using interfaces and in this latest tutorial he covers the reuse of "domain code", the main logic of your application (rather than the structure).

Last week I wrote about when to add an interface to a class. The article finishes with the claim that classes from the application's domain don't usually need an interface. The reason is that domain code isn't going to be swapped out with something else. This code is the result of careful modelling work that's done based on the business domain that you work with. And even if you'd work on, say, two financial software projects in a row, you'll find that the models you produce for each of them will be different in many subtle (if not radical) ways. Paradoxically you'll find that in practice a domain model can sometimes be reused after all. There are some great examples out there. In this article I explain different scenarios of where and how reuse could work.

He then goes on to cover three "reuse" situations, providing a summary for each:

• Reuse-in-the-small
• Reuse-in-the-large and software diversity
• Reuse-in-the-even-larger: reusing entire subdomains

He finishes up the article sharing some thoughts about which of the types seems more obtainable and, in his experience, useful.

On NetTuts.com today there's a new tutorial showing you how to use the CodeIgniter framework to create Basecamp-style subdomains in your application.

CodeIgniter is a simple and lightweight PHP framework used to create powerful web applications. Today, we are going to do something nifty: we’ll combine user names and subdomains to make for a more cohesive user experience. If you’re a bit confused, this feature allows your users to access their accounts by typing in a custom url, which maps to their user name, such as harbinger.yourapp.com.

Their setup shows the homepage for the application if you go directly to the domain but changes to a login form when you hit the subdomain. There's a bit of DNS configuration involved to get the subdomains working (you'll have to add in a wildcard to catch the subdomains). They show you how to set this up on your localhost if you're working on OSX or Windows. With a few changes to the Apache server for virtual host and a basic install of CodeIgniter, they get started creating the database tables and control panel application.

On the Ask About PHP blog there's a quick tutorial looking at a setup to use the CodeIgniter framework to power multiple websites (in subdomains).

CI’s default folder structure is really geared towards one site domain, and having both the application folder and the system folder visible to the browser is not exactly a secure approach. By configuring your install to support multiple sites, not only do you make the updating of the CI core easier, but also make the CI install more secure as a whole.

The example is on a Windows system, but the instructions are generic enough to work on any platform. They're using it under a XAMPP install, but the changes are all below the document root of that setup. You'll need to edit some of the config files and be able to update the Apache configuration to work with VirtualHosts

Based on some feedback that I got from readers a little while back (and some of my own thoughts before that), I've decided to split off the job postings to take them out of the main feed. Several people felt that they distract from the main portion of the site - the news.

They haven't gone to far, though - as you'll notice, there's now a "Jobs Feed" on the sidebar that you can subscribe to and get the latest jobs posted with us. This number is growing more and more every day, so it's a great place to keep up with. We've also moved them over to their own subdomain, jobs.phpdeveloper.org to keep things nice and tidy.

From here on out, if you want to find out about the latest job openings, you'll need to subscribe to the new jobs feed or check out the new subdomain, jobs.phpdeveloper.org to keep up with the latest postings. We'll still post the weekly summaries here in the main feed each Saturday for those that just want the overview.

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.