Aller directement à la fin des métadonnées
Aller au début des métadonnées


We are living in a world where most of the people are connecting to the internet for their first time through their mobile devices. Majority of them use emails to communicate over the internet as emails have been the most established and reliable form of communication.

With more more mobile devices coming in different sizes, also the existence of tablets, laptops and huge monitors, there is a basic need to make the emails support these different devices. While text emails, work fine on these different sized devices, brilliant looking html based emails suffers, sometime making it impossible to be read on mobile devices.

Emails are also the main medium to connect the organization and the participants in CiviCRM. The project I was working on was “Responsive Layout for Emails” that included making emails more reliable and readable over different devices by providing a simplified and responsive layouts for email. Considering the situation of current world, 50% of emails open occurs on mobile device and 70% of people delete emails instantly which do not timely render. The main aim of the project was to let people read emails sent through CiviCRM properly on all of their devices.

Also, this will allow end-users to align system emails to the brand of their organization.

 Implementation Details

The main objective of the project was to make emails compatible and responsive on different clients and devices. At the same time making it easier for the end users to modify system workflow emails.

After going through Jira, and using civicrm built via build-kit, some of the issues identified were:

  • The current emails were not responsive and can be modified using tables layouts optimized for desktops.

  • To make a common change in all the system workflow message, a user has to go through all the templates and make changes separately, eg adding a logo on the top of the template.

  • The current emails have style in their head, styles in head are not respected and ignored in lot of email clients like gmail.

We started with tackling the above problems one by one.

Abstracting Header and Footer and Adding Token Support for the same.

The problem with the current system flow templates was to add same header and footer to all the templates, we had to individually edit the templates again and again. 

The plan was to abstract them into few different layouts, the user will have option to choose and modify these layouts per system email. Giving them the ability to modify headers and footers at one go for all the templates. Needless to say all these templates would be responsive and will together result in a responsive layout.

Now, we have default header and footer template tokens in the system specifically for workflow emails as {{transaction.header}} and {{transaction.footer}} which can be easily included in the templates. These templates can be edited like any other default mailing components in the "Header, Footers and Automated Responses" section of the website.

A default set of both the components is set up in the database which can be updated on the next upgrade (4.7.11) of CiviCRM and is available on the new installations as well.

 Converting Current System Workflow Emails responsive.

The second part of the project was to convert all the system workflow email templates into responsive emails. With the help of opensource Zurb Framework for responsive emails, we modified every template to look good on all the devices. This part was initially planned to be integrated into the core of the CiviCRM and changing the content of the templates on the upgrade, but after discussions with the mentors, it was suggested to be implemented as a extension.

The extension "TransactionTemplates" is in aplha with all the templates modified into responsive templates, including the tokens for header and footer of the workflow emails. The extension can be installed as general CiviCRM extension. It is suggested to install extension from within CiviCRM : Extensions.

Extension can be found here :

Style Inline

Writing style in header is easier to write and read for a user but many email clients such as gmail, outlook block the css in header and the plan was to have a post processor which converts all style to inline style. Thanks to Eileen we have an extension which is ready to used. 

The extension using hook _civicrm_alterMailParams alter the content of the mail by inlining the css of the html before sending. While installing the extension "TransactionTemplates", a suggestion to install the inline css extension is giving for the best usage.

Work Log

28 April - 25 May(Community Bonding Period)

  • Understanding the code base of CiviMail.

  • Community bonding.

26 May (Week 1)

  • Fixing a bug in civimail.

  • Wiriting tests for the same using selenium web tests.

02 June (Week 2)

  • Understanding the code of framework of User-Driven Messages

  • Daily update thread on Civi forums

  • Discussed possibilities with community

09 June (Week 3)

  • Creating a function in token class to replace transactional header and footer.
  • Update a template to test the replace the tokens.
  • Testing the above function created in the Message template : : sendTemplate() function. 

16 June(Week 4)

  • Replacing header and footer token with appropriate token.
  • Posted on for feedback from the community members and end civicrm users.
  • Feedback from mentor.
  • Implementing the changes suggested if any.

23 June: Mid term submission (Week 5)

  • Searching for various inliner to online the css of the emails.

  • Working and understanding the code of inline extension provided by elieen.

30 June (Week 6)

  • System-generated email's headers and footers are responsive.

  • The header and footer layout is easier to brand(logos etc) according to the organization.

  • Ask mentor & community for feedback and updating the wiki accordingly.

  • Asking fellow developers to test the tokens

07 July (Week 7)

  • Studying how an upgrade works and posted related question on the civicrm.stackexchange.

  • Including the code in the next upgrade.

  • Implementation of feedback by mentor and community.

14 July (Week 8-9)

  • Studying different responsive frameworks to edit the workflow templates as suggested by mentor.

  • Trying few of them as to find the most appropriate and flexible one.

  • Selected Zurb for rest of the templates modification

28 July (Week 10-11)

  • Collaborating the inliner code into a plugin, which will convert the internal css into inline css.

  • Testing plugin.

  • Feedback from mentor.

  • Releasing alpha.

  • Bug fixes

4th Aug(Week 11)

  • Modifying css according to our need.

  • Modifying every template according to the css using table format.

  • Testing emails on different platforms.

  • Creating an extension to override the default templates.

11 Aug: Wrap up (Week 12-13)

  • Working and modifying the extension.

  • Wiki update

  • Project wrap up.

The source code of the project is in a public repository on Github. I would be communicating to mentors over IRC and hangouts for meetings. I will also keep the community updated through blog posts and the forum.


Responsive System-Workflow Emails

Bugs Fixes:

  1. Simple bug fix for mismatch of spelling of civisualize as civisualise.
  2. Removed test contribution with a query change.
  3. Initially only Body text was compulsory which might not be the requirement every time. Therefore, body text was made optional and added a validation rule which checks either one of them is filled.

What's Left?

Integrating CSS Inliner plugin to the extension.

  • This will allow to inline the css at the time of installation, thus saving the efforts of doing the same everytime before sending an email.

  1. Jul 29, 2016

    JoeMurray dit :

    What is the current status of this initiative? Is there a repo somewhere for testing?


Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.