Developed from the original
multi_site extension, itself inspired by the old virtual_domain behaviour (anyone else remember that?)
This is extension is in development and only works in places. It takes our fork of multi_site and improves on it here and there. Soon it will add site templates, import-export, subdomain-creation and other requirements for creating new sites on the fly. Some of these features may later spin off into their own extensions, but we'll start them off together here and see what happens.
Provisionally working, but bugs are likely. Not suitable for production use.
- Site-scoped (and global) Radiant::Config (without breaking the cache)
- YAML site templates and chooser
- Non-horrible site admin interface
- Userland site-creation interface
- Site import and export
- Dashboard integration
None at the moment.
$ git submodule add git://github.com/spanner/radiant-sites-extension.git vendor/extensions/sites
If you're coming from multi_site, don't run
rake db:migrate:extensions: the radiant migrator ignores the migration task defined here, which does some useful checking of
multi_site migrations. Instead, this:
$ rake radiant:extensions:sites:migrate $ rake radiant:extensions:sites:update
If you want to site-scope a model class (let's say you want your assets to be site-specific as well as your pages), all you have to do is add a line to the top of the class:
If you want selective availability of some resources to many sites (or many sites to some users), this:
The scoping takes effect at the ActiveRecord level - it wraps
with_scope round every call to find (actually, to find_every), count and similar methods. If an object is out of site scope it is as though it didn't exist. This usually means your controller and view code hardly need to change at all: they just see fewer objects.
Please note that the old
is_site_scoped interface is about to break. Our fork of
multi_site is still available and works fine if you prefer that and don't need the other functionality. If you're just hosting a few sites of your own, it's all you need.
If a site-scoped class includes any calls to
validates_uniqueness_of, those too will be scoped to the site. This presents problems with model classes that have already got uniqueness validations, like most of radiant's core classes: it's very difficult to go back and change the validation rules. Instead, we reach back and change the whole validation mechanism. That happens very early on in the initialization of the app, so we can't look at associations. Instead, when defining the validations we check for the presence of a
site_id column and scope to that if it's there. It's not a very nice solution but it does work, and if the column isn't used the scoping has no effect.
Have a look at
lib/sites/scoped_validation.rb to see what I mean. I hope that a bit of headscratching with the core team will let us get rid of this hack, but for now it is needed to support
Questions and comments
Would be very welcome. Contact Will on will at spanner.org or drop something into lighthouse. Github messages also fine.