Last time we spoke of Django, we installed Django CMS: perhaps the most popular out-of-the-box CMS available for Django. Now that we've explored the most popular CMS, let's move on to the best CMS.

I realize I'm speaking of something subjective as though it were fact. As much as I'd like to agree that this is wrong, doing so would make for a boring read. I'll stick to my guns here.

Installing Wagtail

To makes things easy, we'll start with the obligatory server updates and Python3 setup. This way, the copy-and-paste crew will have no problem following along. It's important to note that this example will take place on a Ubuntu server.

Let's get started by updating and upgrading our packages:

$ apt update
$ apt upgrade -y

Next, we'll just make sure that we have the latest versi0ns of Python3, Python3-dev, and pip3 installed:

$ sudo apt install python3-pip python3-dev
$ sudo -H pip3 install --upgrade pip

Finally, we'll follow best practices here by keeping our packages confirmed to a virtual environment we create:

$ python3 -m venv mysite/env
$ source mysite/env/bin/activate

Great. With the environment activated, we can start getting to work. Before installing Wagtail, we need to install two dependencies: libjpeg and zlib. These are libraries critical to image compression and the sort:

$ pip3 install libjpeg zlib

Now we can install Wagtail:

$ pip3 install wagtail

Good job. For our next trick, we'll create our actual Wagtail project. This installation contains Django at its core: simply installing Wagtail with install Django and create the necessary project structure. I'll be creating the project in the /var/www directory, but feel free to do as you please.

$ mkdir /var/wwww
$ cd /var/www
$ wagtail start mysite
$ cd mysite

wagtail start mysite is a command that will create a project called mysite in the current directory. Again, name your project as you see fit. With that directory created, change directories so you're inside said project, and install Wagtail dependencies from the requirements.txt file:

$ pip3 install -r requirements.txt

As with a normal Django project, we need to run our migrations to get things set up.

$ python3 migrate

This command will result in the following output:

Operations to perform:
  Apply all migrations: admin, auth, contenttypes, home, sessions, taggit, wagtailadmin, wagtailcore, wagtaildocs, wagtailembeds, wagtailforms, wagtailimages, wagtailredirects, wagtailsearch, wagtailusers
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK

Next, we need to created a superuser:

$ python3 createsuperuser

Running this will prompt a few details as follows:

Username (leave blank to use 'root'): myuser
Email address:
Password (again):
Superuser created successfully.

You're a hero. Now, you're probably anxious to see what all the fuss is about. Let's get your development server up and running so you can start playing around in the browser:

$ python runserver

That command should give you the following:

Performing system checks...

System check identified no issues (0 silenced).
April 20, 2019 - 03:48:58
Django version 2.1.8, using settings ''
Starting development server at
Quit the server with CONTROL-C.

Great work. Now if you visit your server's default address on port 8000, you should be able to hit the barebones Wagtail project you just created. To reach the admin, hit https://localhost:8000/admin/.

Config files

As mentioned, installing Wagtail will immediately set up a Django project. If that's so, where is our famous file? It's actually split into three files:,, and All these are stored here:

$ cd mysite/settings is the closest to Django's file. This contains all settings which are common to both our dev and prod environments.

Django settings for mysite project.

Generated by 'django-admin startproject' using Django 2.1.8.

For more information on this file, see

For the full list of settings and their values, see

# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
import os

PROJECT_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
BASE_DIR = os.path.dirname(PROJECT_DIR)

# Quick-start development settings - unsuitable for production
# See

# Application definition







ROOT_URLCONF = 'mysite.urls'

        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
            os.path.join(PROJECT_DIR, 'templates'),
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [

WSGI_APPLICATION = 'mysite.wsgi.application'

# Database

    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),

# Password validation

        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',

# Internationalization



USE_I18N = True

USE_L10N = True

USE_TZ = True

# Static files (CSS, JavaScript, Images)


    os.path.join(PROJECT_DIR, 'static'),

# ManifestStaticFilesStorage is recommended in production, to prevent outdated
# Javascript / CSS assets being served from cache (e.g. after a Wagtail upgrade).
# See

STATIC_ROOT = os.path.join(BASE_DIR, 'static')
STATIC_URL = '/static/'

MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
MEDIA_URL = '/media/'

# Wagtail settings


# Base URL to use when referring to full URLs within the Wagtail admin backend -
# e.g. in notification emails. Don't include '/admin' or a trailing slash

As you might imagine, settings stored in either or are specific to dev or production, respectively. comes with some presets, such as setting DEBUG to True, as well as a pre-populated SECRET_KEY:

from .base import *

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'i!9r654&2us(2g!2ep#n*vufp-)z#mn+^qid_w8o^thnsj)nbm'

# SECURITY WARNING: define the correct hosts in production!

EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'

    from .local import *
except ImportError:

Unlike, comes with no such predetermined values. The understanding is that you must set these values yourself: after all, if anybody were to grab a hold of the secret kept in, your career as a developer is basically over:

from .base import *

DEBUG = False

    from .local import *
except ImportError: