HubL Tokens

[AnthonyPizziol]

 I'm an average user, not a designer and need help adding the proper HubL tokens to my email design template in order to easily edit the content when sending an email. Can anyone please help explain the process in lamens terms? Much appreciated!

[mgrubbs]

At the most basic, basic, basic level, you can create a template designer email (the one with the gray boxes + drag/drop ) and start pulling in custom module types to allow users to add their own content directly in the email.

I've had mixed results here, as end-users are typically breaking styling of headers / fonts by copy+pasting things into Text modules or loading an image and fixing the width so it's not responsive. (just a few examples, there are lots of ways you're limited via this approach).

My Preferred method:

The best way to get started is to build a custom HTML email template in the design manager and tinker with custom modules. You can take an existing email template built in the template editor (like a HubSpot default template) and "clone to file" . This will give you the raw HTML version of a "pretty" template file.

This will help you understand the structure of the template, what tokens are required, as well as some basics as to how the custom modules fit into this setup.

From there, you'll want to look at the list of supported custom modules and try just dropping some into the template, saving, and creating an email with that template. 

Look at how things render, see what modules give you what result in the interface, and try changing some of the module attributes / parameters described in the documentation.

The biggest / most important module parameter:

If you want the user to just have an "interface element" but nothing show up directly in the email editor, then use the export_to_template_context flag. This then gives you the results of a user interface element as a variable in the template itself.

Now, rather than clicking in the email to change this variable, you have to reference it by using the widget_data.name_of_module.<parameter you want> format.

Example of the two ways to use custom modules:

Here's an example of a text field using the custom module w/o the export_to_template_context. This is a simple text field being used as a text field - meaning to render text.

<h1 style="color:#1d1d1d; font-family:helvetica;">
{% text "headline" label="Enter Headline", value="Default Headline" %}
</h1>

The above example lets the user modify the headline without accidentally overwriting any headline-specific styling. Because the style information is wrapped around a simple text element.

Let's say though that you want the results of a user element to determine the theme color of the email. I'll assume that this color will affect a number of backgrounds and the headline text.

We can use the "color" custom module to pick a color, then export_to_template_context to make that color available all over the template. I'll apply it in context of the text field used above.

-- Use the widget_data.name_of_module.value format described above to reference the  and get the color variable --

{% color "my_color" label='Choose Color', color='#000000', export_to_template_context=True %}

<h1 style="color:widget_data.my_color.color; font-family:helvetica;">
{% text "headline" label="Enter Headline", value="Default Headline" %}
</h1>

The above example will allow the user to do 2 things:

1. Click the text headline to directly edit it within the email
2. Use a custom module interface element to pick a color that will apply to the headline

Things to Note:

If you aren't comfortable in the design manager, there's not much you can do without some actual guidance.

The custom modules can either be taken at face-value for what they are (color, text, html block, image, etc) or you can treat them as tools to set variables / manipulate large chunks of code (more advanced).

Either way, there's no easier way to learn than to jump in and test!

Best,

Mike