3. Make changes and deploy them#

Now you have a working Django Wagtail installation. It includes the Page model, from wagtail.core.models, that typically you would extend to include your own fields.

This process is described in the Wagtail tutorial, and adds a home application to the Django application that adds a new page type. We’ll run through the steps here.

3.1. Add a new home application#

You’ll notice that we use docker-compose run web a lot here, to execute familiar Django commands inside the application’s Docker environment.

3.1.1. Create the application#

docker-compose run web python manage.py startapp home

Edit its models.py to add a new HomePage model with a body field:

from django.db import models

from wagtail.core.models import Page
from wagtail.core.fields import RichTextField
from wagtail.admin.edit_handlers import FieldPanel


class HomePage(Page):
    body = RichTextField(blank=True)

    content_panels = Page.content_panels + [
        FieldPanel('body', classname="full"),
    ]

3.1.2. Configure the Django settings#

home needs to be listed in the application’s INSTALLED_APPS, in settings.py. Add home to the list:

# all Django settings can be altered here

INSTALLED_APPS.extend([
    "home",
])

3.1.3. A brief explanation of Aldryn Addons#

This application uses the optional Aldryn Addons system, which makes it possible for applications to configure themselves. For example, you can can find all the configuration that Aldryn Django does for Django settings in addons/aldryn-django/aldryn_config.py. (Aldryn Django is simply a convenience wrapper for Django - the Django used by your application is a wholly standard Django installation obtained from PyPI.)

You don’t have to use Aldryn Addons on Divio; if you prefer to manage settings manually, that will work just as well. However it makes development much faster, as it takes care of all the settings that would otherwise need to be managed correctly for the different cloud environments as well as the local environment.

One advantage of Aldryn Django is that it declutters the settings.py file, removing deployment-related values that are better handled via environment variables, and also provides a guarantee that settings for database, media and so on will always be correct. Aldryn Django’s aldryn_config.py sets them appropriately for each environment, including the local development environment, and also appropriately at each stage of the build/deployment process.

In settings.py, you’ll find the lines:

import aldryn_addons.settings
aldryn_addons.settings.load(locals())

These lines load all those settings into the settings module. This includes populating INSTALLED_APPS. A good way to see what settings are applied is via Django’s diffsettings command:

docker-compose run web python manage.py diffsettings

3.1.4. Create migrations and migrate the database#

docker-compose run web python manage.py makemigrations home
docker-compose run web python manage.py migrate home

3.1.5. Add templates to the application#

3.1.5.1. Application-level base.html template#

In templates, add a base.html:

<!DOCTYPE html>

    <head>
        <title>{{ self.title }}</title>
    </head>

    <body>
        <h1>{% block page_title %}{% endblock %}</h1>

        {% block content %}{% endblock %}
    </body>

</html>

3.1.5.2. Application-level templates#

In home/templates/home/home_page.html:

{% extends "base.html" %}

{% load wagtailcore_tags %}

{% block page_title %}{{ page.title }}{% endblock %}

{% block content %}{{ page.body|richtext }}{% endblock %}

3.1.5.3. Add a page in the Wagtail admin#

In the usual Wagtail way, add a new page under Home, and ensure that in Settings > Sites, the default Site is attached to it.

3.2. Deploy to the cloud#

If you are satisfied with your work, you can deploy it to the cloud.

We made changes settings.py, added the home application and some templates. So:

git add .
git commit -m "Added Home application"
git push

On the application Dashboard, you will see that your new commit is listed as 1 Undeployed commit. You can deploy this using the Control Panel, or by running:

divio app deploy

When it has finished deploying, you should check the Test server to see that all is as expected. Once you’re satisfied that it works correctly, you can deploy the Live server too:

divio app deploy live

3.3. Using divio app push/pull#

Your local database has new content, but your cloud database hasn’t been touched by the work you did locally. One very useful function of the Divio CLI is ability to push and pull your database and media storage to and from the cloud environments. For example, try:

divio app push db

This will push the local database to the cloud Test environment. Once the process has completed, you can refresh the cloud Test site; you’ll see that it now has the same content in its database as the local site.

Similarly, you can push/pull media files, and also specify which cloud environment. See the local commands cheatsheet. A common use-case is to pull live content into the development environment, so that you can test new development with real data.

3.4. Install a package from pip#

Next, we’re going to install a new package, Django Axes, into the application (Django Axes keeps track of log-in attempts). Then we’ll test it and deploy it to the cloud.

To be used in a containerised system, packages must be built onto the image, otherwise the next time a container is launched, the package will not be there. The image is built by the Dockerfile, and in our Dockerfile for Django application , this includes an instruction to process the application s requirements.in file with Pip. This is where the package needs to be added. Open requirements.in and at the end of it add a new line:

django-axes==3.0.3

It’s important to pin dependencies to a particular version this way; it helps ensure that we don’t run into unwanted surprises if the package is updated, and the new version introduces an incompatibility.

Now you can build the application again by running:

docker-compose build

3.4.1. Configure the Django settings#

As before, add the application (axes) to the settings:

# all Django settings can be altered here

INSTALLED_APPS.extend([
    [...]
    "axes",
])

3.4.2. Run migrations#

docker-compose run web python manage.py migrate axes

3.4.3. Check the application#

If you launch the application again with docker-compose up you’ll find Django Axes in the admin at /django-admin:

'Django Axes in the admin'

Test it by attempting to log in to the Django admin with an incorrect password.

3.4.4. Deploy again#

Once more, you need to:

  • commit the changes

  • push them

  • deploy them on the cloud

3.5. More complex configuration#

See Configure a more complex application from the basic Django tutorial pathway. This includes some further configuration examples that it is good to know about.

3.6. Where to go next?#

This completes the basic cycle of application creation, development and deployment; you should now be familiar with the fundamental concepts and tools involved.

Other sections of the documentation expand upon them. The how-to guides in particular cover many common operations. And if there’s something you’re looking for but can’t find, please contact Divio support.