Multiple websites using the same app - how to set this up? - django

I have an app that shows products available in the US. If i want to change the country, I simply modify the value of a variable in my settings.py file.
Now... each country I serve needs to have its own site, e.g. example.co.uk, example.ca, etc. They'll all be hosted on the same server and use the same database. The views, static files,etc. would be almost the same for each country.
What's the best way of setting this up? Should I have one main app and then have per-country apps that extend the app?
(Using Django 1.6.2/Python 2.7)

I recently had something similar to do.
I have for each domain a specific setting file with an unique SITE_ID and also a wsgi file per site. Then in my http.conf (I'm using apache on webfaction) i set up multiple VirtualHost instances, each pointing out to the specific wsgi file.
My configuration looks something like this:
random_django_app/
__init__.py
models.py
...
another_app/
...
settings_app/
settings/
__init__.py
base.py
example_co_uk.py
example_ca.py
...
wsgis/
__init__.py
example_co_uk.py
example_ca.py
__init__.py
urls.py

Maybe try django-dynamicsites, not sure how well it will work with 1.6.2, I've used it on a project a few versions back. It worked great, you could override settings, urls and templates for each site and share everything else.
There is another project called django-dynamicsites-lite that looks a bit more recent.

Related

Where can I keep settings data for a reusable app

Django=3.1
I'd like to push some utilites of mine, template tags, filters etc. to a reusable app.
But this app will needs a huge amount of settings. Maybe 100-200 lines.
I'm thinking of placing a file called something "my_omnibus.py" next to project's settings.py
Is a good idea? If it is, could you tell me how to import that file into the reusable app if the name of the project may change.
If it is not, where can I keep the constants?
In your app's root directory, create a settings.py and dump all settings there. In that app, use relative imports e.g. from .settings import SETTING_A.
You shouldn't create settings next to project's settings.py module because those settings are only relevant to one app. You should only do such a thing only if those settings are going to be used by all apps (an example would be celery application configuration).

Why is the urls.py file not created automatically?

Almost every video which I saw about Django (for beginners), people who create applications using the startapp command and add their urls.py file manually in their application. My question is, if urls.py is so important for views and for our app why it's not creating automatically when we run startapp command!
Not every app directly serves the end user
URLs.py is only useful for routing users to pages which primarily have to do with that app. However, many apps may only do internal things. I have an app in one of my projects that handles badges and rewards, but there is no page which corresponds to any of that because it all shows exclusively as part of the profile pages (and the routing is handled within the profile app).
It just isn't always needed and that is why it is not always included.
Simply you don't have to serve each of your app to the end-users. You may have apps responsible for only your inner interactions. So it is not logical to put urls.py in each and every app.
It vary on how you use your routing.
django give project wide urls.py by default when you create the project using django-admin startproject command. so you can create all your project's urls on this file.
And not all app intended to server user directly using urls.
Whether i also prefer to create separate urls.py and api-urls.py routers for every app and include in main urls.py

Change "ROOT_URLCONF" in Django depending on site

I just need some advice pointing me into the right direction using Django with multiple sites / clients.
Basically depending on the domain name I want to use multiple sites with only one Django instance.
For example a directory structure.
mysite/
manage.py
settings.py
client1/
url.py
client2/
url.py
So what I am thinking is, inside settings.py depending on the domain name I can change the
ROOT_URLCONF = 'mysite.clientx.urls'
The site will match about 95% so I don't see the point of changing all other settings as well.
How would I do this? I did go through site management in the Django documentation although it seems like an overkill for what I want to accomplish.
Also keep in mind I am using Apache with "django.wsgi".

Django admin template overrides not working in production environment

Like this question, my admin overrides aren't working in my production environment but they are in my development environment (same django version). I've tried reordering the INSTALLED_APPS tuple in settings.py with no change (was the answer to the question linked above). Here's how I have my project constructed:
/WebDJ/ # project dir
+devices # unrelated app, but it uses templates (see below)
+sales
__init__.py
admin.py
models.py # has Customer and Transaction model classes
+templates
+admin
+sales
+Customer
change_form.html
+Transaction
change_form.html
+devices # lots of templates under here that work fine
404.html
500.html
also:
TEMPLATE_DIRS = ('/WebDJ/templates',)
is set in settings.py. The templates in the devices app are fine. What's not loading are the overrides in the admin directory - so the change form for Customer and Transaction has some extra stuff added to them (overriding the "after_field_sets" block).
Again, it works in my development environment (using PyCharm) but not in my production environment. Any ideas? I'm really stumped on this one.
Answer: on my production machine, apparently it didn't like "Customer" and "Transaction" despite that being the exact name of the models - it needed "customer" and "transaction".

How do you setup a Django project with different sites using the same data?

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.
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.