We Keep Coding

What is the advantage of using a Django bootstrap module over linking to bootstrap files directly?

I see there are Django bootstrap modules (e.g. crispy_forms, django_bootstrap). I am trying to decide whether to use a module or link directly to bootstrap files in a base html file like the following:
<!-- jQuery library --> <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<!-- Latest compiled JavaScript --> <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"></script
I have an understanding that with the modules I would do the styling in the code. With using bootstrap directly, I am thinking I have to style it in the template files.
I am trying to see reasons why I should be using a module. Also, with the bootstrap modules would I be able to use all bootstrap features?

Using modules for bootstrap is an awful idea. It creates tight coupling between ur app and the css framework. If you ever decide to move to a different framework you’ll need to refactor your forms in addition to the html templates. This also applies if you decide to upgrade from bootstrap3 to bootstrap4 in the future. Bootstrap4 has a ton of backward incompatible changes.
Create a form rendering template snippet and reuse that everywhere you need a form. If you want to change or upgrade cas later, all you have to do is update that one file.

The django-bootstrap modules provides a set of convenience template tags and integration with existing django features such as forms.
For instance, styling and rendering a django form in a template with bootstrap styling is as simple as
{% bootstrap_form form %}
As for upgrading to bootstrap4, django-boostrap4 is available.
Of course nothing is forcing you to use the django bootstrap module if you prefer to manually write your own bootstrap HTML tag class names and that might be better for your specific use case.

Django static text model

So basically I have surveys application and there's main user dashboard. There he can see his surveys, new surveys, etc and there's also some static about text.
What I want to do is make that text not static - let administrator edit it. What are my options here. I thought about using flatpages app but that would mean that I would have to write my custom middleware to pass context to flatpages which is overload and writing my custom app only for two static texts seems like too much work.

Custom django admin template for app

I would like to create a custom index.html derived from the admin/index.html individual for each app in my django project.
For instance my folder structure is like:
app1
templates
index.html (different from the global template admin/index.html)
app2
templates
admin
base.html
index.html (global template index.html)
How can I achieve custom admin index.html files for my apps, that are recognized by django? For the moment only the index.html in the global template/admin folder is considered for rendering the index pages in my backend.
I'm using django 1.6

Unfortunately, only certain parts of the Django admin site can be overridden on a per-app basis, as it says in the documentation:
Not every template in contrib/admin/templates/admin may be overridden per app or per model. The following can:
app_index.html
change_form.html
change_list.html
delete_confirmation.html
object_history.html
Remember that the admin interface is itself and app, so it's going to do a single template sweep and load the first set of templates that comes up.
I think your two best bets are either to use multiple admin sites in your project or to add a custom view for specific apps -- the former is probably easier, but will be a problem if you don't want people to have to login separately to control certain things.

Multiple Django template loaders

I'd like to use Jinja2 with a Django project. I'm using this template loader from Django Snippets, but I still need to be able to render templates with Django for the admin pages. Whenever I try to use the admin pages, though, I get a TemplateSyntaxError because of the unknown tag "load". Is there a way to make the Jinja template loader defer to Django's built-in system when it can't handle the template?

I would recommend using this fork of Coffin when using Jinja and Django templates at the same time: https://github.com/GaretJax/coffin/blame/master/README.rst I implemented this on http://umbel.com/ which uses a combination of Django and Jinja templates.
It has a setting that you can use to disable Jinja's template loader for specific apps:
JINJA2_DISABLED_APPS = (
'admin',
'auth',
)
Hope that helps you out.

Using Django admin look and feel in my own application

I like the very simple but still really elegant look and feel of the django admin and I was wondering if there is a way to apply it to my own application.
(I think that I've read something like that somewhere, but now I cannot find the page again.)
(edited: what I am looking for is a way to do it automatically by extending templates, importing modules, or something similar, not just copy&paste the css and javascript code)

Are you sure you want to take every bit of admin-site's look & feel??
I think you would need to customize some, as in header footer etc.
To do that, just copy base.html from
"djangosrc/contrib/admin/templates/admin/"
and keep it in
"your_template_dir/admin/base.html" or
"your_template_dir/admin/mybase.html"
Just change whatever HTML you want to customize and keep rest as it is (like CSS and Javascript) and keep on extending this template in other templates of your application. Your view should provide what it needs to render (take a look at any django view from source) and you'll have everything what admin look & feel had. More you can do by extending base_site.html in same manner.
(Note: if you keep the name
'base.html' the changes made in
html will affect Django Admin too.
As this is the way we change how
Django Admin look itself.)

{% extends "admin/base_site.html" %}
is usually a good place to start but do look at the templates in contrib/admin/templates and copy some of the techniques there.