Question

I’m currently looking at the the documentation for Django sites:

http://docs.djangoproject.com/en/dev/ref/contrib/sites/#ref-contrib-sites

which explains how to associate content with multiple sites. The example used is LJWorld.com and Lawrence.com.

What does the Django project structure look like for the above? Is each site an app on its own, for instance:

project/
    manage.py
    settings.py
    urls.py
    ljworld/
        models.py
        views.py
    lawrence/
        models.py
        views.py

If ljworld has SITE_ID=1 and lawrence has SITE_ID=2, does the SITE_ID variable has to be explicitly set in ljworld/settings.py and lawrence/settings.py?

How do you run the dev server of either ljworld or lawrence?

Update:

I used two sites with shared content in the above. What should be done if there are n different sites who are sharing the same content? Do I really need n different Django projects on n different servers, all connected to the same database server?

Moreover, if I need to make a change in settings.py which should affect all those web sites, it will be very tedious to change each of those files manually.

Answer 1

No, each site is not an app on its own; each site is a project on its own. The whole idea is to have different projects with a (fully or partially) shared content. So you might have a structure such as:

ljworld/
    manage.py
    settings.py
    urls.py
    ljworld_specific_app1/
    ...
lawrence/
    manage.py
    settings.py
    urls.py
    lawrence_specific_app1/

You would normally use two Web servers to serve the projects – though normally both would refer to the same DB server. Naturally you can also have apps which are shared between the two projects – just keep them somewhere in the server’s PYTHONPATH.

Edit:

“Two Web servers” of course doesn’t necessarily mean two physically different servers. They could well be two virtual hosts running under the same Web server instance – heck, you could even map the two projects to two different directories under the same virtual host.

For shared settings, you could use the same technique as for shared apps. Have a global_settings module which contains the shared settings available somewhere on the PYTHONPATH and import it from each of the settings.py.

And if you wanted something really hackish, you could probably even drop all the different projects, use just one and create a middleware that changes settings on the fly. But I would advise against it.