Django: Create a site with subsites - python

I would like to create a site in django that follows the following example.
example.com
site1.example.com
site2.example.com
example.com being the main site. Users should be able to login from example.com to access the other subsites. What's the best way to accomplish this or has someone done something similar they'd like to share to help me solve this headache I'm having.
They should have different apps per subdomain

The way to do this is to have each site share the same database for at least some of the functionality; that is, some common elements are associated with one or more sites using the ManyToManyField.
See Django's documentation for associating content with multiple sites.

Related

Configuring multi-tenancy

In a local dev env, I'm currently attempting to hack my way to multi-tenancy using Mezzanine:
Mezzanine makes use of Django’s sites app to support multiple sites in a single project. This functionality is always “turned on” in Mezzanine:
That's pretty much as far as an entry-level tut for multi-tenancy on mezzanine gets. Great, so I go to the admin site, and add a site:
Domain name-----|----Display name
127.0.0.1:8000----|----English Site
127.0.0.1:8000/es|----Spanish Site
Now, I am stuck. I have fiddled around with url.py, but figured that's not where to start, considering I need to know something to map the url to. Views? Lost.
Any ideas?
(Included translation is not an option given the web service will never translate as good as a human.)
Multitenancy in mezzanine is done via domain names. You will need to run http://dev.site and http://esdev.site or similar in development (add the entries to your hosts file and make sure they match the listings in the sites part of admin).
In production you'll also want to use two different domains too.
For example, my personal site http://dpn.name/ and my business site http://behest.com.au/ are both running off the same mezzanine install.
Later on when you have the right setup, you'll be able to add new posts and pages to each specific site by either logging into the admin via each domain name, or changing the currently active site in the admin (the drop down is in the top right if you have multiple sites set up)
Hope that helps, please let me know if you need more info.

How to use same django project multiple times - each with diffrent database?

I wrote a django project that is some kind of a CMS.
Now, I want to be able to create several accounts that use that CMS, Each with a different database.
For example, user can create himself an account in my service - and he will get a site based of that CMS.
How can I get started doing this?
Look at the django docs https://docs.djangoproject.com/en/dev/topics/db/multi-db/ There are is useful example. Another good article https://thenewcircle.com/s/post/1242/django_multiple_database_support
Unfortunately Django is not suited to dynamically switch databases at runtime. You either have to implement really hackish solutions (like mentioned in this question Django multiple and dynamic databases ) or to go with several independent Django instances which you will have to start up on your server dynamically.
A much simpler solution would be to stick to one database and distinguish different users' content by some other means, like Django Sites framework. The only problem with this approach in my opinion is that you will have to carefully set up your admin site configuration, so that users don't see each other's objects (in case you planned to use built-in Django admin).

Storing/Retrieving/Editing project specific data with Django

I'm new to Django and I'm working on the public website for a small company.
I'm facing an issue that I guess has already been encountered by lots a django noobs,
but I can't manage to find a good solution.
My problem is that there some informations (contact address, office phone number, company description...) that I use in nearly all of my views and are by nature unique (undertand: a database table with only 1 row). I currently store these informations has a model in my databse, but I find it a bit weird issue an additional database request each time (each view)
I need to access them. However, I need my client to be able to edit these informations (by the admin interface).
So, please, is there a django idiom to handle such an use case ?
Thx in advance.
If you look into caching solutions, they will probably do what you need.
The general queryset caching solution I use in johnny-cache, but for what you need, you can probably just load it up from the db and store it in the cache.
What you want to do is use select_related('contact_profile','office_data') etc when you query the items in your view, and in the admin, instead of registering all the data separately just use the InlineAdmin class for the Admin site and you will be able to edit all the information as if it was a single entity.
Check out the django docs for more information.

How can I create a single log-in and profile for a network of three sites using Django?

How can I create a single log-in and profile for a network of three sites using Django?
I have a network of three sites and instead of having the user create a profile at each of the three sites, I'd like the user to only need to register one time, and then be able to use all three.
Is there an elegant solution to this problem?
Let the sites share the databases. Hence they will have a common user table.
Take a look at the django sites framework: http://docs.djangoproject.com/en/dev/ref/contrib/sites/
Depends on your server(s).
Do all the sites have access to the same DB? Then use dcrodjer's answer.
If not, you can implement a OAuth style Single Signon Service, that the other sites authenticate against.
Ex:
site1.example.com
site2.example.com
site3.example.com
siteN.example.com
Would auth against oauth.example.com
If you can put those three sites into subdomains of a single domain, then I'm almost sure you can stick to what Django offers. What I'm writing about is something like this:
site1.mydomain.com
site2.mydomain.com
site3.mydomain.com
-- where login is implemented at mydomain.com.
Basically, mydomain.com should serve a small Django page that implements only the login form and maintains session for ".mydomain.com" domain (note the leading dot - it's required for the session to propagate to site1..3 subdomains). So if you log into mydomain.com, you're effectively logged into all three subsites.
And the easiest way to share server-side auth and session data is to make ubsites 1,2,3 use two databases, one small database shared with mydomain.com for auth and session data, and the other one specific to given site.

Django: Admin with multiple sites & languages

I'm supposed to build some Django apps, that allow you to administer multiple sites through one backend. The contrib.sites framework is quite perfect for my purposes. I can run multiple instances of manage.py with different settings for each site; but how should django's admin deal with different settings for different sites, eg. if they have different sets of languages, a different (default) language? So there are some problem s to face if you have to work on objects coming from different sites in one admin...
I think settings.ADMIN_FOR is supposed to be quite helpful for cases like this, but theres hardly any documentation about it and I think it's not really used in the actual Django version (?).
So any ideas/solutions are welcome and much appreciated!
Thanks a lot...
There is an old blog post by James Bennet which might be helpful:
Create a new Site object in your admin for each domain, and put the id of that Site into its settings file as SITE_ID so Django knows which site in the database corresponds to this settings file.
In the settings file for your original site (the one with id 1), add the other sites’ settings files to the ADMIN_FOR setting, to let Django know that this one instance of the admin application will handle all of the sites.
As documented ADMIN_FOR (for which i can not post link) should be a tuple of settings modules much like INSTALED_APPS is a tuple of django app modules.
Note that blog post is from 2006 so it uses a bit outdated API.

Categories