SubscribeRails Multisite Plugin Ready For Prime Time
For those of you who were following my multisite plugin, be aware that it is now updated and ready for use in Rails 2.0.2.
See he original announcement for more information about its use.
It’s worth noting that this plugin conflicts with all template caching. You will get an exception if you try to use it with template caching. I believe caching can be supported fairly easily with some small monkey patches to Rails. That may be forthcoming if there is demand for it (I don’t need it yet myself).
March 12, 2008 at 1:37AM
Gabe – I am just starting a new rails app that needs ‘multisite’ capability, so I am glad to find your plugin. What I have tested so far seems quite promising.
Help me understand the site/public directory. I understand that I can configure apache in production to point at this directory based on domain accessed. What I don’t understand is how this works in dev mode, where I don’t have apache running. Thoughts?
March 12, 2008 at 6:38AM
Great question!
In my case I have set up Apache 2 locally on my dev box and given it the same configuration that I use in production except substituting the real domain names for something like
sitedomain.local.The local domains are set up in my
/etc/hostsfile.Now without Apache you should still get the multisite functionality for views directory by accessing
http://sitedomain.local:3000, but obviously this presents a problem for static files in the public directories.I don’t believe there’s anything simple you can do to get mongrel (assuming you are using mongrel) to search multiple document roots as my Apache config does. Even if you could, I assume it would be outside the scope of the Rails app (I’m a little shaky on mongrel static file serving, so I could be wrong).
That would actually be a whole article unto itself, and I think of limited value. I would be more interested in developing a solution for other web servers first due to mongrel’s limitations. There are other things you can get from a local Apache setup, such as SSL support. At some point I may put in some time to figuring out how to make it work with Nginx since that is a server I use on other projects.
If you want to get this working on a pure mongrel setup, I’m afraid you’ll have to get your hands dirty, though I’m happy to publish anything you discover. Multisite is an extremely simple plugin, and I think quite elegant. The Apache setup on the other hand is just what worked for me. I think it would be very helpful to have alternate setup ideas.
March 14, 2008 at 6:04AM
Thanks for the info. I will probably set up apache on my dev box as well, but I might spend a little time researching a ‘lighter’ approach. If I discover something other than apache, I’ll let you know.
April 11, 2008 at 1:27PM
I’m in a similar situation to David. Running stand-alone mongrel for development but have apache2 with mongrel cluster for production. I’m in the process of upgrading from rails v1.2.3 to v2.0.2 which required me to ditch theme_support and start using multisite. However, haven’t been able to come up with a clean solution for dealing with the public folder.
Just thought I’d mention it because I feel like a large portion of multisite plugin users may end up falling in this category. In which case, configuring the public folder issue becomes a major obstacle to adoption.
From your README, it sounds like the rationale for this design decision was to avoid the long paths required for static file caching. Perhaps offering this option as a plugin configuration setting would be helpful. Just throwing out ideas, maybe the development config can use internal public folder mapping and production config can use apache DOCUMENT_ROOT settings.
April 11, 2008 at 3:25PM
Thanks for the feedback.
Compared to theme_support, multisite is an extremely simple plugin. I’m basically just piggybacking on top of Rails 2.0 view_paths, requiring only a few lines of code. My use case is also unique in that I was bringing in a large amount of existing HTML pages with hard-coded asset links that I didn’t want to mess around with, so the Apache solution was just very natural. Admittedly my local dev setup is beefier than most because over the years I’ve run into several bugs and difficult problems that were most readily solved by getting my local Apache setup dialed in.
Clearly multisite is ripe for feature enhancements. Lack of site-specific caching support is a huge one, as is the difficulty of local development. At this stage I don’t have a strong vision of what an elegant solution would look like, which makes feedback all the more valuable. My current job and project are in a very different arena and so I’m not working with this plugin on a daily basis and don’t have any brilliant ideas coming forth in the immediate future. However keep the brainstorms / ideas / roadmaps / patches coming and sooner or later I will likely taken action on this issue.