Templateset Nonproliferation

Multiple templatesets are the obvious way to handle multiple brands. A new templateset gives you total control of the look, feel, and behavior of your ActionKit pages or microsite. But each additional templateset means one more thing to maintain and upgrade, which can get cumbersome quickly.

A few simple bits of Django will reduce the number of templatesets you need to maintain.  Read on for details.

You’ve got a friend in custom page fields

Custom page fields can often take the place of an additional templateset. They’re written into a templateset and then available to page creators as an input field. For example, an organization with a 501c3 and 501c4 might use a custom page field to control the logo and tax deduction notice.

Here’s what you’d add to your wrapper template:

<img src="{% if page.custom_fields.entity = '501c3' %}/images/501c3.png{% else %}/images/501c4.png{% endif %}" />
{% if page.custom_fields.entity = '501c3' %}
  Your donation to the Foundation is tax deductible.
{% else %}
  Your donation to the Action Fund is not tax deductible
{% endif %}

While that’s two changes in the template, it would appear as a dropdown under Custom Page Fields as the campaigner creates the page:

Image 3-12-19 at 10.51 AM

We wrote a previous post on using page fields to customize page styling:

Customizing page styling

Other examples of variations you can add using page fields include:

Mirror, mirror, on the template

The Django template language relies on template inheritance: The ability to  “build a base ‘skeleton’ template that contains all the common elements of your site and defines blocks that child templates can override.” ActionKit templates already show this principle; wrapper.html defines a content block that other templates fill.

To make templatesets easier to maintain, we’ll use template inheritance to define parent (or master) templates with {% extends %} and {% include %}.

One templateset to rule them all

You can define one templateset as your parent.  Then to simply mirror the content of a the survey template in the Parent_templates templateset, we’d use:

{% include "Parent_templates/survey.html" %}

This can be especially useful if you want to add a different appearance but have your survey page work the same regardless of your branding, or for page types that you use infrequently.  You only need to update the parent template and all the templatesets that include it will also be updated.

Let’s say we want to create a new type of event map that keeps the organization’s look and feel but overrides the page’s title text and the default event search behavior. The wrapper.html template contains these blocks:

{% block title %}
  {{ page.title }} | {% filter ak_text:"org_name" %}{% client_name %}{% endfilter %}
{% endblock title %}

Set the title of the page

{% block content %}{% endblock content %}

Defines the page content — what goes inside the wrapper’s style. The content is often populated by choices in page setup.

The event_search.html in the Parent_templates templateset extends the wrapper. We can override those blocks while retaining the rest of the event_search.html template from the Parent_templates templateset by extending Parent_templates/event_search.html. That could be used to add a different event map, as in this example:

{% extends "Parent_templates/event_search.html" %}
{% block title %}
  {% filter ak_text:"org_name" %}{% client_name %}{% endfilter %}'s Events: 
  {{ page.title }}
{%  endblock title %}
{% block content %}
  <h1>Hello world</h1>
  <div id="event-map">
{% endblock content %}

Considerations for implementation

  • Most look and feel changes can be handled with custom page fields.
  • Are you using the built-in ActionKit behavior for a particular template? Inherit from the Original templateset to do so.
  • If your templatesets have already proliferated, start by mirroring the templates that you haven’t intended to diverge from the master templateset.


Interested in scheduling a demo with ActionKit? Let us know!