Sorry for bringing up an old topi, but there seem to be a few suggestions around for allowing users to create their own subdomains with a django project, but no real recommendations (maybe that's for a reason?)
The main issue that people bring up is that they don't need/want to create a separate settings file for each subdomain, but they do want to associate different content with each subdomain (site)... even though the sites model has a 1-1 reln with a settings file. After reading quite a few different opinions, all solutions seem to be along the lines of mapping (via DNS) all subdomains to a single django project (and hence single settings file), the differences only being with what to do with that domain once it gets to Apache: Option 1: Rewrite url at apache and pass to django (i.e. subdomain.domain.com -> domain.com/subs/subdomain/ ) I get the feeling that this option would work well if each subdomain isn't really a different site, but is just a view of a model with some common functionality (eg. domain.com/subs/subdomain/edit/ etc.). That is, you don't have a need to associate instances of lots of different models with different subdomains. That said, it seems that people DO do exactly that (http://www.rossp.org/blog/2007/apr/28/using- subdomains-django/) and end up re-implementing a relationship very similar to the Sites app... Option 2: Sending the url as-is to django and then either: 2a: use a middleware to re-write the url (just like the apache re- write above) Or, as outlined below by Afternoon below (as well as Max in the comments of the post above) : 2b: use middleware to match the url (subdomain.domain.com) with a site in the sites app, then dynamically set the SITE_ID to be able to get associated content via Site.objects.get_current() (although the SITE_ID would obviously not correspond to a separate settings file). Main issue here is that we're doing something that is warned against in the settings documentation...dynamically changing a setting. But on the other side, it would allow the sites app to be used to associate different content with different subdomains. So, any hints from the experts? * Option 1: Apache rewrite to django view path * Option 2a: Django-middleware rewrite to django view path, or * Option 2b: Django-middleware to match subdomain.domain.com to site model (and dynamically set SITE_ID). My guess is that if we don't need a separate settings/urls file for each subdomain then it's probably because each subdomain is not a separate site in the djano-sense? Any insight appreciated! Cheers, Michael On Oct 17 2006, 12:28 am, "Afternoon" <[EMAIL PROTECTED]> wrote: > I would like to create a virtual hosting style solution which allows: > > * New sites to be created through-the-web. > * Multiple domains to be assigned to each site. > * Each site to have separate media and templates folders. > > The requirements are not too difficult, I can implement most of this on > top of the standard sites framework without great modification. One > thing I do need to do is modify settings.SITE_IDat runtime. The domain > name is found in request.META["HTTP_HOST"] and theSITE_IDis looked-up > from that. I've created a trivially simplemiddlewareto do this and it > works, but the settings documentation forbids runtime modification. > > * Why should settings be left unchanged? (I have some guesses) > * Is there a way around this problem? > * Anyone have any other suggested designs for this solution? > > I can create my own version of the sites framework, which doesn't use > settings.SITE_ID, but it would be nice to reuse what's there, > especially as other parts of Django link to the framework. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
