Is there any way to administer multiple Django servers at once? - django

Short Version
Is there any tool that will let me use a single Django admin page to affect multiple Django installations on different servers?
Detailed Version
I've got a bunch of different servers, each with their own Django installation. This works great ... except when I want to do something via the Django admin to all of the servers, in which case I have to log on to each server separately.
For instance, let's say I have a release coming and a co-worker (who's not a programmer) wants to use the admin to make a "message" record about the release for the server's users to see. They have to log in to each server's admin individually, create the message record, then move on to the next server until they've gotten through all of them.
To get around this whenever I have a multi-server change I've been using Git; ie.:
I make a commit with files for the change
I push that commit
I pull that commit on all of the servers at once (using Fabric).
However, this too is sub-optimal, because we can't take advantage of the admin interface, and doing something as simple as adding a "new release coming" message requires an actual (mini-)release itself.
So, it seems to me the best way to handle this would be if there was some sort of meta-admin tool my co-worker could use to Django admin work on multiple servers at once. Does anything like that exist?

Related

Access/Substitute CreatePage outside of Gatsby-node.js

I am creating a forum using Gatsby
I have develop a form that users can use to create threads to add to the forum in a page called create.js which which sends the data to an external DB.
Once, the user has submitted the thread, I want to create a new page using a template, normally I would use in Gatsby-node.js; according to the Gatsby Docs Gatsby-node.js is only run once on deployment.
Is there another way that I can access CreatePage() outside of Gatsby-node.js or is there another function I am missing?
Ultimately I want the new page to available in the Gatsby application, without redeploying, after the user has created the necessary content.
The way Gatsby works is that all pages need to be generated at build time. You cannot add new pages without triggering a new build.
Gatsby is not a suitable platform for a forum since content changes hundreds or thousands of times a day. Gatsby is intended for content that changes infrequently such as blogs (which might update a few times a day).
I order to generate pages without using CreatePage in Gatsby-node.js, Gatsby advises to use #reach/Router and matchPage to extend the client application's router, we call this functionality (Client-only Routes)
more info here

Using Django to Create Child Sites

I am creating a series of small sites, I'm using the django framework. The theory goes a user comes to a master site, signs up, then he gets his own child site.
Example:
navigate to example.com
user creates an account "mysite"
user then gets his own site: mysite.example.com and he can configure this all he wants
My question: * would it be better to have a "gold" version of the site that gets created for each site?
for instance: cp ~/goldsite ~/mysite and change the database pointers appropriately ** the downside is if I ever have to do maintenance on a file, I would have to change all subsites.
...or * have one host and configure the database to support multiple sites. The DB might get messy.
Any feedback would be great.
Use the same code/database for all the users, otherwise it would be a nightmare to maintain the code. Think about database migrations, backups, update the code with git...
...or * have one host and configure the database to support multiple sites. The DB might get messy.
It shouldn't be really complex, associate each website object with an user and use the permissions properly.

Django + Wordpress: Integrating user login

I would like to have one users system (preferrably Django's) to rule both Django and Wordpress.
The use case is that Django is an application embedded inside a wordpress installation (via iframe or something similar). In order to use the Django, users must be authenticated, authentication in WordPress is not mandatory, but recommended (for posting comments and stuff like that).
In order to ease the usage of the site, I would like the same sign-up to apply for both the Django app and the WordPress installation. Sign-up might occur either via OAuth / FB authentication (lots of Django solutions for this), or via dedicated site users. While the signup process is most important, it would be nice if certain user fields would remain synced between the two worlds.
My thoughts on the matter:
Maybe there's an out-of-the-box solution (couldn't find any)
Create a full-fledged django app for syncing the two user models (wp_users and django's users) via one of the following options:
A master(django)-slave(wp) solution, where each change in Django changes info in the wp_users and other related tables and vice-versa (via Django periodically checking the DB or creating a WP plugin). Can be implemented either by putting both django and wp on the same (MySQL) db, using XML-RPC or some other anomination I didn't think of.
Same as above, but let WP be the master instead of Django (seems harder).
An external system to rule both models - maybe make OAuth / some other external authentication mandatory, and somehow sync the two models using this?
Has anyone encountered this situation before?
Any suggestions will be appreciated.
You should really try to work out some approach, revising your work when encountering problems afterwards.
Nevertheless imo Wordpress is kind of bordered. I wouldn't recommend making changes to both frameworks, but fixate on Django.
For example you could create a WordpressUser(User) and create a python script a crobjob, celery task or whatever you'll need to syncronize your databases. Meaning to say you should keep things strictly separated unless you have very good reasons not to (I can't think of any).

How to setup groups (sub-sites) in Django

I'm new to Django and I come from Drupal family. There we have Organic Groups with which we can create groups of content and subsites; how do I do something like that with Django?
Say I'm making this site for my company using Django and every department in my company needs a private section on the site. For example, the design people have their own part of the website into which the back-end developers can not come in. And the back-end developers will have the same thing too.
I want to build the site in such a way that I just login into Django admin and add a new category or subsite or group (whatever the Django term is) with the same settings from other groups or with similar settings.
It depends on what you mean by "private section". You should probably try looking at it from a different angle:
Django splits a site's functionality by means of "apps". Each app does its specific thing, and gets a set of tables in the database. Apps can access each others' tables. For example, it's common for other apps to access the Auth app's user, group, and permissions tables. Is this what you mean by "sub sites"?
As for access control, users can be assigned to groups and they can have various administrative permissions assigned to them. Add, change, and delete permissions are automatically generated for each model (i.e. database table). You can also add your own permissions.
I don't think you'll be able to separate the designers from the back-end developers at the Django level. You'll need to do something else, such as maintain separate source repositories for each and merge them to create the usable site (each group would have read-only access to the other). It really depends on your teams' discipline, because these elements can get intertwined.
Django recommends that static files be served by something else, say directly from your web server, or from another machine with a simple HTTP server (no CGI/WSGI/whatever). This is because Django can only slow down static files compared to direct service. However, for testing, ther is a static page server you can enable.
Given all that, static files usually amount to CSS, images, media, and JavaScript. Of these, the back-end people might want to mess with the JS, but that's it, so this could be in the designers' repo.
The Django tree itself has the code for the site and the apps. It's almost all back end stuff. The exception is the HTML template files, located in the "templates" directory in each app. These are the files that are filled in with the context data supplied by the back-end view code. I have no idea if this is front or back end for you guys; it could be mostly back end if there's a lot of CSS discipline, but I think that's unlikely.
There are a lot of things that you can do in Django that make life easier for one side or the other. For example, template tags allow custom Python code to generate HTML to insert into the page. I use these to generate tab bars and panes, for example.
I really can't help much more without getting a better picture of what your needs are. The question is still vague. You're probably best off taking a day or two going through the tutorial, seeing what the Django perspective is, and then working out how (or if!) it fits into your needs.

How to host 50 domains/sites with common Django code base

I have 50 different websites that use the same layout and code base, but mostly non-overlapping data (regional support sites, not link farm). Is there a way to have a single installation of the code and run all 50 at the same time?
When I have a bug to fix (or deploy new feature), I want to deploy ONE time + 1 restart and be done with it.
Also:
Code needs to know what domain the request is coming to so the appropriate data is displayed.
The Sites framework comes to mind.
Apart from that we have Django running for multiple sites by symlinking Django to various docroots. Works like a charm, too.
I can see two quite distinct ways to do this:
Use one database and the sites framework. Every post/picture/whatever model is connected to a Site and you always filter on Site. This requires a separate settings file for every database.
Use one database for each and every site. This allows different users for every site, but requires duplication of everything that is stored in the database. It also requires a separate settings file pointing to the correct database.
Either way, you do not duplicate any code, only data.
--
If you need to do site-specific, or post-specific changes to ie. a template, you should read up on how Django loads templates. It allows you to specify a list, ie ["story_%d.html", "story_site_%d.html", "story.html"] and django will look for the templates in that order.
I just ran into this and ended up using a custom middleware class that:
Fetch the HTTP_HOST
Clean the HTTP_HOST (remove www, ports, etc.)
Look up domain in a Website table that's tied to each account.
Set the account instance on the HTTPRequest object.
The throughout my view code I do lookups based on the account stored in the HTTPRequest objects.
Hope that helps someone in the future.