A production release of this plugin is now available for Rails 2.0.2, no more core patch required! See the announcement  

Following up on my previous post about multiple controller view paths, I’m now releasing my multisite plugin for Rails. It’s not yet fully tested, but it’s already in production and will be fully tested for at least one use case by the end of the week. I wanted to get the code out ASAP to garner feedback, because I’m getting the feeling that there is a lot of community interest in this. However, please note the following:

• This plugin requires edge Rails plus a patch that is still pending approval from core.
• There is currently one unaddressed issue that may need to be resolved.

Multisite Plugin

What Rails multisite does is to insert an additional view path into the search path run by ActionView when it’s looking for a template. The basic use case is that you have multiple domains pointing to the same Rails application, and you want a given domain to be able to override any of the standard templates in app/views. However, the plugin doesn’t make any assumption about what constitutes a “site”. You are responsible for writing your own method to select a site.

Multisite is based on Matt McCray’s Theme Support plugin for its structure, but is essentially all new code taking advantage of edge Rails’ multiple controller view paths. I haven’t put in any support for Liquid templates or the static file theme caching. I’ve set things up a little differently.

Controller Code

I’m basing my site selection on the main chunk of the primary domain name, so I set it up something like this:

class ApplicationController < ActionController::Base
  site :get_site

  private
  def get_site
    request.domain.split('.')[-2] #'www.darwinweb.net' returns 'darwinweb'
  end
end

File Structure & Generator

The location of the customized templates will be sites/darwinweb/views (within your RAILS_ROOT). This views directory behaves just like the regular Rails app/views directory, and it is searched first. Primarily I use this for layouts, but any template can be put in there to override a default application template.

You can generate the very simple directory structure by running:

script/generate site darwinweb

This will generate the views directory as well as a second directory: sites/darwinweb/public. Now this public directory doesn’t do anything on its own. I opted to link this in to each site via Apache VirtualHost configs. I found this to be much cleaner than requiring link helpers such as theme_stylesheet_link that cache files into a subdirectory of the main public directory.

Apache VirtualHost Config

So if this new public directory becomes the Apache DOCUMENT_ROOT, does each site have to have a copy of all the shared files? Well, no, Mongrel will server static files from the main public directory by default if Apache passes the request through. However using Mongrel for static content isn’t recommended, so I came up with an additional rewrite rule to allow Apache to check both directories before proxying the request. This is based on the stock Railsmachine config:

<VirtualHost *:80>
  ServerName darwinweb.net

  DocumentRoot /var/www/apps/rails_app/current/sites/darwinweb/public

  # Configure mongrel_cluster
  <Proxy balancer://quickidx_cluster>
    BalancerMember http://127.0.0.1:8000
    BalancerMember http://127.0.0.1:8001
  </Proxy>

  RewriteEngine On
  # Check for maintenance file and redirect all requests
  RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
  RewriteCond %{SCRIPT_FILENAME} !maintenance.html
  RewriteRule ^.*$ /system/maintenance.html [L]

  # Rewrite index to check for static
  RewriteRule ^/$ /index.html [QSA]

  # Rewrite to check for Rails cached page
  RewriteRule ^([^.]+)$ $1.html [QSA]

  # Rewrite to check for main application static file.
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ /public%{REQUEST_URI} [QSA]

  # Redirect all non-static requests to cluster
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ balancer://quickidx_cluster%{REQUEST_URI} [P,QSA,L]
</VirtualHost>

I’ve left a few of the esoteric parts out, but this config is essentially a copy of the base application config with a new ServerName and DocumentRoot. The tricky bit is the second to last RewriteRule which rewrites the URL to a subdirectory if the requested file doesn’t exist. In order for that to work, you need to have a symlink pointing the main application /public directory inside your site’s /public directory. I tried to get it working without a symlink, but mod_rewrite can’t change the DocumentRoot, so the only way to break out of sites/darwinweb/public is with a symlink. You’ll need to make sure Options +FollowSymLinks is enabled.

Development Plans

I haven’t released an official packaged version of this plugin yet because I haven’t had a chance to check out the issue with compiled template names that Rick Olson pointed out in my patch ticket. Currently I’m running only a single customized site, but that is about to change, so an official release is forthcoming.

More View Paths

Aside from the basic functionality on a site-by-site basis, I’ve also discovered that adding view_paths has a tremendous utility for selecting different templates without messing around with Rails’ implicit rendering. In a sense this returns to the original theming concept of Theme Support, but I’m looking at creating a finer-grained model. I don’t have a firm implementation plan for that, but it seems a natural fit for the plugin.

Liquid Templates

In one sense Liquid templates are an orthogonal solution to the same problem I’m trying to solve with Multisite. However Liquid provides the additional benefit of end-user-safe customization, which is definitely a killer feature. I haven’t had the time to set up Liquid templates on my current project, but they are definitely in the long-term plan. As such, they will need to be integrated into Multisite eventually.

Your Input

I’ve received positive feedback from several people already, so I know this plugin is scratching more than my own itch. But everyone’s use case is different, so I’m really reaching out for others’ input to make Multisite serve a wider audience. I’m generally interested in productizing high-end web apps, where clients are paying big bucks for deep customization capability. This is different from the 37Signals style of apps, but I believe there’s a huge market niche for this kind of stuff. If you’re developing a productized application in Rails, I’d love to hear from you.