Skinning HTML emails with Drupal using an existing front-end
A requirement that comes up from time to time is being able to use content stored in Drupal and produce rich HTML emails. In a lot of cases the design of these emails matches the design of the existing, already implemented front-end website.
In a recent project, we explored ways of creating HTML email’s which wouldn’t require us to start from scratch and would also evolve as the website’s look and feel did. Our design goals were thus:
- Use the existing website’s CSS to skin the emails.
- Use existing Drupal site-building tools to construct the markup for these emails.
- Allow admins to easily create and preview HTML emails.
Re-using CSS
A tool we came across which would allow us to re-use the existing css from our website was Emogrifer. Emogrifier is a project which takes two inputs, HTML and CSS and produces a mix of the two by converting all of the CSS rules into inline styles on your chunk of markup.
Being a Drupal 7 project, we used service_container to create a new DrupalEmogrifier service which would be responsible for gathering up the Drupal CSS to attach to any given markup.
The goal was to get all the CSS for the front-end theme, ready for the email template. One of the resulting such methods looked like:
/**
* Emogrify requires inline styles to attach to markup. Get them from a theme.
*
* @return string
* A list of inline styles from a given theme inside a style tag.
*/
protected function getThemeCss($theme) {
$files = $this->getCssFileList($theme);
$css_registry_files = [];
foreach ($files as $file) {
$global_css_files = $this->d7->drupal_add_css(file_get_contents($file), ['type' => 'inline']);
$css_registry_files[] = array_pop($global_css_files);
}
return $this->d7->drupal_get_css($css_registry_files);
}
At this point we were free to use our normal front-end tools like sass/compass to build out components for our email template in the exact same fashion we would if we were styling any new feature on the website. We also got all of the existing site components such as typography and brand colors for free.
During this process we also contributed a patch to Emogrifier which allowed us to incorporate media queries that impacted the email template, while removing those which were irrelevant, allowing us to create a responsive template for those email clients that supported it.
Incorporating Site Building
Drupal’s arguably most powerful feature is site-building, so we wanted to continue to use all the tools we’d used to build the website, to build our email template. One of the known issues with creating HTML emails is how strict email clients are with the kind of markup they will accept and render. It was unfortunately back to tables when it came to creating the markup.
One of the tools we’d used throughout the site was panels and panelizer. As a result, we could easily create a series of layout plugins which were email friendly. We created a “news_teaser” and an “email_body” template and applied them to the entities we were using to store the newsletter data. Our email teaser template file looked something like:
<div class="email-teaser">
<table class="email-teaser__table">
<tbody>
<tr>
<td class="email-teaser__image">
<?php print $content['image']; ?>
</td>
<td class="email-teaser__content">
<?php print $content['content']; ?>
</td>
</tr>
</tbody>
</table>
</div>
Within these templates and we used normal field formatters and content_type plugins to flesh out what the contents of each email would be, most of which had been drawn from the work already done on the website.
Admin workflow
A simple “newsletter” content type was all we needed to store metadata about that particular email campaign. Within it was a series of entity reference fields which allowed admins to bring in content from around the site to contribute to the campaign. This allowed all of the existing publishing workflows to be adhered and also was a familiar experience for content admins.
Other wins
One of the nice side effects of building out the email template within Drupal was that the in-browser preview looked the same as the email that was produced and sent. Content admins could undergo publishing workflows, approve and update the email template from within Drupal and see exactly what the outcome was in the final product, right away.