Handling subdomains

Time for another feature post methinks! And a bit of chance for me to ruminate on some recent development work. That seems to happen so little at the moment that I love to have the chance to ramble about it…

I first wrote Renaissance’s subdomain system quite a while ago. It worked up to a reasonable point. Here’s an example of a site that uses it:

• www.thecreationfactory.co.uk (it’s a bit old and in need of work now, I know)

It’s since become rather broken, as it’s never really been required for client work and has therefore fallen behind the development of the rest of the framework. However, finally, a new client project needs the subdomain system, so it’s time to get it shipshape again.

So what are subdomains for?

I guess before getting into designing or coding any feature, it’s pretty important to figure out what it’s actually for. To be honest, I have no idea what use a lot of the options in Renaissance are for, apart from the fact that whenever I put one in, sooner or later it tends to get used for something. Having said that, all the higher level features do tend to have a reason in mind when I create them.

So, the purpose of subdomains are so we can create,

• micro-sites (for product promotion, etcetera)
• specialised sub-sites (such as private membership areas)
• specialised areas of content where a lot of dedicated pages are required

There are probably a lot of other uses too, and I’d be very interested in hearing any ideas you might have.

The first reason especially is important, and Renaissance does not allow you to manage more than one web site per install. It’s strictly a case of one domain name, one install of Renaissance (although that might change in future). So the subdomain system allows you to create and manage different micro-sites from within the same install of Renaissance, albeit limited to a single domain name.

And what can Renaissance do with them?

I find that re-developing a broken system always seems as if it’s going to be a simple case of bringing the code up to standard with the framework when you first begin.

Pretty quickly, however, I find that there are a lot of design choices to be made—potential new features, realising that old features aren’t going to work at all with the new framework (or were badly conceived in the first place), etcetera. Renaissance’s subdomain system was definitely no exception. In fact, I was a bit dismayed to find quite what state it was in when I came back to it after a year or two of neglect! I was also quite surprised to find that getting the subdomain system up and running again would have quite a large impact on some of Renaissance’s core structure. So, a quick job started getting pretty big pretty quickly.

So, to answer the question in the heading, the things I’ve ended up deciding that the subdomain system can enable you to do are,

• tell Renaissance that you want a new subdomain, what it’s called and where on your file system it is located
• move the required index and htaccess files into the subdomain’s directory (this can be such a pain with UNIX file permissions and the rest that it’s almost worth making the user do it themselves as they’ll almost certainly have to get their hands dirty to get it to work anyway)
• set access permissions on a subdomain that will apply to all the pages on that subdomain
• set the home page for a given subdomain
• assign a page or piece of content to a particular subdomain (this will prevent that page or piece of content from being displayed on any other subdomain, including the main/default subdomain)
• delete a subdomain

Things I’ve decided the subdomain system can’t do are,

• create the subdomain itself (I just don’t know enough web server stuff to make this possible; I don’t even know if it would be possible or realistic from within PHP anyway)
• allow you to move a page to a different subdomain once the page has been created (this was a tough decision, and not the kind of limitation I like to impose)

The Home Page

Now, all of this would be pretty simple, if it wasn’t for the small factor of the site’s home page. And, for that matter, the home page for each subdomain. In fact, it would still be pretty simple if it wasn’t for the user and the interface that they need.

Obviously, there can only be one home page for the site and only one home page for each of the subdomains. As that stands, that’s pretty easy to handle. Renaissance has got along fine for a long time with a simple flag in the pages table denoting whether or not a given page is a home page. Find out whether a given page is attached to a subdomain or not and you’ll know what kind of home page it is (i.e. belonging to the site or to a subdomain). The user wants to set a different home page? Easy, just find the current one and unset it. They want to delete a home page? Again, easy, just block them from doing it until they’ve created a new home page.

The problem comes when the user wants to move a home page onto a different subdomain. I don’t think I need to run through all the possible scenarios to make you see that it could get pretty sticky, pretty quickly. So why not just prevent home pages from being moved, rather than all pages? Well, I thought of that, but the problem is that Renaissance treats all the descendant* pages of a given page as belonging to the same subdomain as the parent page. Okay, no problem there… until one of those descendant pages happens to be set as a parent, at which point things get messy again.

(Yes, I know it’s unlikely that a site would have the home page set to a different page than the heirachy’s top level page, but it is possible and I have to allow for that possibility).

I know that resolving all problems generated by moving home pages and their parents around between subdomains could be done, but I felt that with so much complication and so many caveats and blocks on a user’s actions it wouldn’t really be worth it, and as noted before, that something I very rarely decide! But it’s not as if it’s hard to create a new page with the appropriate settings anyway—just go to the page you’d want to move, select the new subdomain, save it as a new page and delete the old one. The only problem with this is that you lose your version information.

While I was at it…

… I decided that the whole home page system was a bit flaky, so I re-wrote a lot of it, no longer storing a flag in the pages table (instead storing it in the hub table**), running a lot more checks to make the whole thing more robust and creating a class just for dealing with home pages (handling them was kind of distributed around and about before). The system also now checks its home page on start-up, instead of waiting until a home page is requested.

Wrapping up

The whole system is slightly annoying, in that it’s something that’s nice to have but in no way essential that also complicates Renaissance’s operation at a fundamental level. (For that reason, there’s a main configuration option that lets the site’s admin switch off subdomains completely, so at least you don’t have the overhead if you’re not planning on using them).

All in all though, I’m quite happy with the system. It’s useful, it’s pretty easy for the user to operate, offers a fair amount of flexibility and it does add something.

I must point out, however, that I have absolutely no idea how other packages handle subdomains, or even if they allow them at all! Do you have any exerience with subdomains with other CMS packages? I’d be very curious to hear about it.