Django-CMS is very powerful, but comes with no themes by default.
They say:
Themes are outside the django CMS scope. If you wish to theme the admin,
just override the template admin/base_site.html and include some custom css.
That's all very well, but everyone wanting to start a new project with
Django-CMS faces a lot of study, effort and difficult choices just to get
their first pages to display sensibly. CMSBootstrap aims to get you started in
minutes, with a quality extensible base to build your site on.
Low bandwidth accessibility is a big part of our philosophy, and this theme
needs to support that. Using Bootstrap/Sass allows us to enable and disable
Bootstrap modules quickly, so we can skip large chunks of CSS and keep the
overall page weight small, while still being flexible.
Our goal on our first project is to keep our pages below 100 kB compressed,
including images, CSS and javascript. This allows them to be loaded within
10 seconds on an 80 kbps connection. Standard Bootstrap CSS alone is 99 kB
(bootstrap-3.1.1-dist/css/bootstrap.min.css), which leaves no room for anything
else on the page within our budget!
This is related to being extensible, but often in conflict. For example:
To be extensible, a theme needs a lot of hooks to override in subclasses:
Django template blocks, CSS classes applied to elements, etc. But all the
hooks that you're not using are noise that clutters and bloats your pages,
so a page full of hooks is a poor template to copy and modify in your own
code, at least not without ripping out a lot of code.
So our aim is to have likely extension points, but not every possible
one. Other reuse mechanisms such as:
Importing existing files wholesale
Extending (importing and then overriding) existing files
Reusing a block's contents, but adding to it
Replacing a file completely
Disabling a file
should all be supported and used where possible in preference to cluttering
every template with every possible extension point.
For the same reason, our "API" to developers should be clear, simple, and
stable: unlikely to change, or need to be changed in future to support newer
versions of Django, Django-CMS, Bootstrap, etc.
This allows developers using CMSBootstrap in their projects to upgrade to the
latest version (for example, if there is a security vulnerability in the CSS,
or to support a newer version of Django) with minimal risk that it will break
their projects and require extensive repair.
As well as slow and unreliable connections, our philosophy is that websites
should be accessible:
Using old browsers (e.g. Internet Explorer 8) for those without bandwidth,
skills or permission to upgrade their browsers.
Using mobile devices (smart phones, feature phones, low cost tablets) as well
as desktop PCs. So our designs should be responsive, compatible with
older and simpler browsers such as Opera Mini, and not require Javascript.
Using free software (Linux, Firefox, Chromium etc.) as well as Windows,
Internet Explorer and Flash, to access our websites.
By people using assistive technology (screen readers etc.)
Into the future, by using web standards properly. So we use HTML5 elements
such as header and nav elements, and add backwards compatibility in
IE8 using Javascript.
Where these standard conflict, we aim to support the largest possible number
of users in our target audience.
Of course you need Django
(1.5 or higher) and
Django-CMS (2.4 or higher) in your
environment as well. They'll be installed automatically by Pip if you don't
have them already.
This allows django-assets to find the assets and compile them.
Ensure that you have the LocaleMiddleware enabled in your MIDDLEWARE_CLASSES:
MIDDLEWARE_CLASSES = ( # other middleware ... 'django.middleware.locale.LocaleMiddleware',)
Some of our templates use the request.LANGUAGE_CODE context variable, which
requires LocaleMiddleware.
You'll need to add some templates too. You don't need all of these, but you
probably want at least one simple page design, a custom home page, and the
global placeholders.
Although not required by CMSBootstrap itself, you might want to add this
setting so that you'll be ready if you decide to start using
Crispy Forms
(recommended) in your project at some point:
The standard template has login and logout buttons, for which you need to have
the django.contrib.auth.urls URL patterns installed somewhere in your URL
map. Otherwise you'll get an error:
NoReverseMatch at /en/
Reverse for 'login' with arguments '()' and keyword arguments '{}' not found. 0 pattern(s) tried: []
If you get this error message, you can add the following lines to your project's
urls.py to resolve it:
If you haven't used Django-CMS before, we recommend that you start with the
tutorial.
You need some Django-CMS pages to see the templates. If you don't have any,
then you'll just see the Django-CMS pony when you visit your site at
http://localhost:8000/.
Creating pages is not really in the scope of this documentation. You could
follow the Creating your first CMS Page
part of the tutorial. Or, if you just want to get started quickly, you can
import the homepage fixture to get a simple home page into your CMS (you
can then customise or delete it as you wish):
overriding a template file, by placing a file with the same name and path
in the templates directory of one of your own apps.
extending a template file, by creating a file with a different name that
starts with {% extends "basetemplate.html" %}.
Note that you cannot both override and extend the same file. Overriding
a file hides the original file, so you can no longer access it or inherit from
it.
Therefore we inserted some extra layers into the inheritance hierarchy: the
templates in the custom directory. They extend the real templates from the
cmsbootstrap directory, and make no changes by default. You can copy them
into your own app (with the same directory name, custom), thus overriding
the ones in CMSBootstrap. Note that:
custom templates extend the eponymous template in cmsbootstrap.
cmsbootstrap templates extend a parent template in custom.
Because Django-CMS stores the actual filename of the template file in
the database, you do not want to move templates around. Therefore the custom
templates serve another function: you can use them in your CMS_TEMPLATES
list instead of the CMSBootstrap versions, and get a default implementation
from cmsbootstrap that does nothing.
When you want to change the template in your project, create a
custom/homepage.html (for example) in one of your apps (perhaps by copying
the one from CMSBootstrap) and override some of the blocks that it inherits
from cmsbootstrap/homepage.html.
breadcrumb_wrap: the wrapper for the Django-CMS breadcrumbs element
article: HTML5 <article> element: <article class="main_article">. You can
override this to add left and right sidebars inside <main>, as the
page_3col_notitle.html template does.
content: empty by default, you can override this to hold your pages' main
content, placeholder or application.
This template exists so that you can add static content that appears on
multiple pages (headers, footers, etc.) and edit it using the Django-CMS
front end.
To do that, create a page (just one!) using this template, with the reverse_id
placeholders_extra, and populate the placeholders in it with your static
content.
To add new placeholders, override this page and add some new placeholders:
{% placeholder "footer_middle" %}
And then include it in your other templates somewhere:
In addition there is another template file called base.html above the
cmsbootstrap directory, which is just an adaptor for 404.html and
500.html in DYE, and is not used otherwise.
Many elements have CSS classes to help you target them:
* Some classes to help you write browser-specific CSS using conditional comments:
* `ie ie6` if the user's browser is Internet Explorer 6
* `ie ie7` if the user's browser is Internet Explorer 7
* `ie ie8` if the user's browser is Internet Explorer 8
* `ie ie9` if the user's browser is Internet Explorer 9
* `non-ie` if the user's browser is not Internet Explorer (or IE >= 10)
You can import the assets from cmsbootstrap.assets into your own assets
module and add extra files to combine them into a single asset, minified and
compressed, to avoid creating extra HTTP requests, like this:
To avoid including the standard CMSBootstrap files a second time, you'll want
to override the standard_css block, replacing its contents with your own
asset, in the base.html template:
You can add new Sass/SCSS assets by following the
django-assets documentation,
creating an assets.py file. For example, you could create a main/assets.py
like this:
Because you've imported the bootstrap.scss from cmsbootstrap, which in turn
imports variables.scss, you have access to all the variables defined by it,
such as $nav-link-padding used above.
Then you need to include the generated CSS file in your base.html:
If you want to make changes to these variables, without copying all of the
cmsbootstrap Sass files into your own app, you can add the cmsbootstrap
project directory to PYSCSS_LOAD_PATHS in settings.py:
In this case, all of the files imported by bootstrap.scss are found in the
cmsbootstrap project using the search path, except for the ones that you
copied into main/static/sass/bootstrap which are used in preference. So you
can modify the variable values defined in variables.scss, and enable or
disable modules in bootstrap.scss (most are commented out by default to
reduce bandwidth overhead).
In order to actually compile this, you must have created an assets.py in the
main app as described above. And you need to replace the standard-css block
inherited from cmsbootstrap/base.html with your own, including your file
instead of bootstrap.scss:
{% block standard-css %} {# note that the inherited block.super is NOT included #} <link rel="stylesheet" href="{{ STATIC_URL }}css/cmsbootstrap.css" /> <link rel="stylesheet" href="{{ STATIC_URL }}css/main/main.css" />{% endblock %}