Yes, this is exactly the problem. My code above takes care of everything in one instance. It's starting to sound like this will be the best solution. Building a custom sites framework may be overkill for the sake of altering a few settings variables at run time. Hard to know if my solution will run into any problems without testing in a high load environment.
On Mar 23, 9:29 am, Tom Evans <tevans...@googlemail.com> wrote: > On Mon, Mar 22, 2010 at 5:53 PM, Tim Shaffer <timster...@gmail.com> wrote: > > It gives you multiple sites from one codebase with multiple settings > > files. They are using the same project module. So your project would > > look like this: > > > project > > - app1 > > - app2 > > - settings.py > > - settings_site1.py > > - settings_site2.py > > - urls.py > > > settings.py would contain all the settings like a normal django > > project, then settings_site1 and settings_site2 could import all those > > default settings and overwrite just the settings they need to (like > > SITE_ID and MEDIA_ROOT). > > That is fascinating, but if you had 20 sites, you would need to run 20 > instances of the project. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
