|
| 1 | += Multisite for Rails Applications |
| 2 | + |
| 3 | +This plugin provides basic support for hosting multiple sites on the same Rails code base. It is based on Matt McCray's theme_support plugin, but is essentially completely gutted and rewritten with a different focus. |
| 4 | + |
| 5 | +The essential functionality of the plugin is to add a specific site's views to the view path. The concept of a view_path is new to Rails 2.0. |
| 6 | + |
| 7 | +== Requirements |
| 8 | + |
| 9 | +* This plugin is tested in Rails 2.0.2. |
| 10 | +* Template caching must be disabled (this includes both cache_template_loading and cache_template_extensions action_view config options) |
| 11 | + |
| 12 | +== Differences from theme_support |
| 13 | + |
| 14 | +If you are familiar with theme_support, a 'site' is equivalent to a 'theme' in the old system. The big difference is that this plugin doesn't make any arrangements for presenting public files. Although a public directory is created by the generator, this can just as easily be a symlink to another directory. The intended use is to configure Apache to provide access to static files for each domain, possibly with a rewrite rule falling back to the main Rails public directory. This approach was chosen because the static file caching in theme_support required long paths to static files that should be unnecessary when they are created on a per-domain basis. By letting Apache handle the specifics, static files are much simpler (no image URL coupling to the theme name, or cache expiration problems), and converting raw HTML mockups from designers tends to be much easier as well. |
| 15 | + |
| 16 | +While theme_support only officially worked through Rails 1.1, and 1.2 with some 3rd party patches (Matt where are you?), this plugin requires Rails 2.0 for the Multiple View Path functionality (http://weblog.rubyonrails.com/2007/2/4/new-feature-for-rails-2-0-multiple-controller-view-paths). This addition to Rails makes much of the remaining complexity of the theme_support plugin disappear. One big bonus is that templates can now be created on a per-site basis without a parent template having to exist in the base directory. This is handy for creating extra content pages or breaking things down into partials. |
| 17 | + |
| 18 | +== Usage |
| 19 | + |
| 20 | +You can use the site_generator to create the file structure needed, or create it |
| 21 | +yourself. |
| 22 | + |
| 23 | +It expects the following site folder structure. |
| 24 | + |
| 25 | + $app_root |
| 26 | + sites/ |
| 27 | + [site_name] |
| 28 | + views/ <- you can override application views |
| 29 | + public/ <- intended to be the DOCUMENT_ROOT of the site |
| 30 | + |
| 31 | + You specify which site to use in your controller by using |
| 32 | +the declarative 'site' syntax. Although this could be automated based on domain |
| 33 | +name, the relationship between domains and sites is not necessarily 1:1, so you will |
| 34 | +need to develop a mechanism for choosing a 'site'. |
| 35 | + |
| 36 | + class ApplicationController < ActionController::Base |
| 37 | + site 'blue_bird' |
| 38 | + |
| 39 | + ... |
| 40 | + end |
| 41 | + |
| 42 | +You can also defer the theme lookup to a controller method: |
| 43 | + |
| 44 | + class ApplicationController < ActionController::Base |
| 45 | + site :get_site |
| 46 | + |
| 47 | + def get_site |
| 48 | + domain = Domain.find_by_name(request.domain) |
| 49 | + domain.theme |
| 50 | + end |
| 51 | + |
| 52 | + ... |
| 53 | + end |
| 54 | + |
| 55 | + |
| 56 | +Note: By setting the site in the ApplicationController you can set |
| 57 | +the site for the whole application. |
| 58 | + |
| 59 | +== Changelog |
| 60 | + |
| 61 | + 1.0.0 - Initial release |
| 62 | + |
| 63 | + |
| 64 | +--- |
| 65 | +Copyright (c) 2007-2008 Gabe da Silveira, based on code from theme_support by Matt McCray, based on code from Typo by Tobias Luetke |
| 66 | +released under the MIT license |
0 commit comments