Usually your action pages add action takers to your mailing list.  But sometimes you’ll have a form where you want users to opt in or you want to avoid subscribing them at all. Perhaps the page is collecting feedback, or it’s part of a coalition campaign. Maybe you’re looking to improve deliverability by requiring an opt-in.

The examples here show two ways to add a checkbox  so users are required to opt in or, alternately, hide the checkbox and don’t provide a way for action takers to subscribe.

Step 1: Create the custom field so you can turn opt-in on and off depending on the page:

• Pages > Other > Custom Page Fields > + Add a custom page field
• Create a custom page field like this:
  • Display Name: Opt In
  • Name: optin
  • Field Type: Select From List
  • Field Choices

   
  yes=Yes, require users to opt in before subscribing
  nosub=Do not subscribe any users to the page

The database will store yes and nosub as the case-sensitive values (which you’ll use in the code below) but staff will see the longer text as they’re editing the page.

Step 2: Add the custom page field to a test action page: 

On the Action Basic screen, expand Custom Page Fields, select the Opt-In field from the drop down, and set the value to Yes.

Step 3: Edit the template.

For one page type

If you’re only adding opt-ins to just one type of page — we’ll work with letter pages here — you can use this simple example.

• Pages > Appearance > Templateset > (whichever templateset this page is using) > letter.html
• Wherever you want the opt-in checkbox to appear, insert this code:

{% if page.custom_fields.optin %}
<!-- require an opt-in -->
<input type="hidden" name="opt_in" value="1" />
<!-- show a checkbox if optin=yes -->
{% if page.custom_fields.optin = "yes" %}
<!-- set value to the ID of your mailing list -->
<input type="checkbox" id="id_list_1" name="lists" value="1" /> <label for="id_list_1"> Keep me informed</label>
{% endif %}
{% endif %}

• Use the plus sign on the right side of the screen to preview and test the page by submitting with a new email address.

Try not checking the box and submitting, then checking and submitting.  View the user record for the email address you used to confirm your results.   When you’re satisfied, go back to the letter.html template you were working on and click publish.

For multiple page types

If you want to include opt-ins across multiple page types, it makes sense to separate out the opt-in code so that you can edit it once and affect all your page types.

• Pages > Appearance > Templateset > (whichever templateset this page is using) > Add a file — let’s call it optin.html

  {% if page.custom_fields.optin %}
  <!-- require an opt-in -->
  <input type="hidden" name="opt_in" value="1" />
  <!-- show a checkbox if optin=yes -->
  {% if page.custom_fields.optin="yes" %}
  <!-- set value to the ID of your mailing list -->
  <input type="checkbox" id="id_list_1" name="lists" value="1" /> <label for="id_list_1"> Keep me informed</label>
  {% endif %}
  {% endif %}

• Publish that file.
• Edit one of the page types you want to allow opt-ins on, like letter.html. Add {% include_tmpl optin.html %} wherever you’d like the checkbox to appear.
• Use the plus sign on the right side of the screen to preview and test the page as described above. When you’re satisfied, go back to the letter.html template you were working on and click publish from there.
• Edit the other relevant page types (like donate.html, letter.html, signup.html) in the template  the same way, adding {% include_tmpl optin.html %} wherever you’d like the checkbox to appear. Again preview and test the pages.

Step 4: Train your team

Make sure anyone who will be creating pages knows when to use each of the options:

• Leave the field blank (or don’t add it to the page) when you want to subscribe all users as they take action.
• Set the value to Yes, require users to opt in before subscribing when you want to show a checkbox.
• Set the value to Do not subscribe any users to the page when you don’t want any users to be subscribed.

You can create mailing templates by adding custom mailing fields to your mailing wrappers. These fields will display in a new Content section of the Compose screen along with the mailing Body field so that you can have multiple editable elements of the wrapper, while hiding the messy structural code out of sight — and safely out of editing range.

For example, you may have a wrapper like this:

<h1>{% include_tmpl custom_fields.headline %}</h1>
<img src="{{ custom_fields.image_url }}" width=300>
{% block content %}{% endblock content %}
<p>{{ custom_fields.signature }}<br/>
Your Organization</p>

Choose this wrapper for a draft and your Compose screen will look like this:

Switching wrappers will change what fields show up here; their display is governed by what is defined in the selected mailing wrapper.

Templates vs. Models

Mailing models are example mailings that are copied each time into a new, fully-customizable mailing. Everything — metadata, content, styling — copies over. Sometimes that’s super helpful! But sometimes you want to maintain the structure and style of a mailing without the content, or you want to control or simplify customization options. Templates are all about simplicity.

Example Wrapper: Template with Sidebar (Built In)

Your instance already has the custom mailing fields of sidebar_text, featured_image, link_url, signature and references.

The image and buttons will automatically link to the URL entered in the link_url field, and the call-out box will only appear if there are values for either the sidebar_text or the featured_image. The button is drawn via CSS so it’ll be visible whether or not the user has images enabled for their email client. And the image is automatically sized to be a max width of 260px.

Setup

One time: create custom fields

Mailing fields used in the wrapper are standard custom fields, so you can set a type, description, defaults, or make a field required. They should be created prior to including them; including a field unrecognized by the system will display the field in red with a warning that it needs to be created.

If you create an HTML type custom field, we’ll include the WYSIWYG in that section under content. You must use specific syntax when you include fields of this type, or of any type where you plan to use template tags or filters:{% include_tmpl custom_fields.NAME %}. Otherwise, {{ custom_fields.NAME }} is sufficient.

One time: Add custom fields to your mailing wrapper

The custom mailing fields section in the snippets menu on the Wrapper screen will insert your fields using the appropriate syntax for the field type. You’ll also see a list of custom mailing fields used in the wrapper under the template box. Hover over them to see the field type, display name and description.

If there’s a value in the mailing field…

You may only want to show an element if the staff member has specified something to go there. For example, a gray sidebar box doesn’t make sense without an image or button to go inside it — it would just be a gray rectangle! A simple if statement can show your element if a field is filled in:

{% if custom_fields.image_url %}
   <div style="align:right;background:gray;padding:10px;max-width:200px">
      <img src="{{ custom_fields.image_url }}" width="100%" />
   </div>
{% endif %}

Now the sidebar will show if there’s an image URL, but it won’t if that URL isn’t filled in.

Working with templated mailings

• Any custom mailing fields not used for the selected mailing wrapper will continue to be available in the Custom Mailing Fields section at the bottom of the Compose screen.
• On the Proof and Send screen, click on the blue Preview link next to the Content header to view a rendered version of your mailing combining all of the fields as previously.

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. Continue reading “Templateset Nonproliferation”