Friday, September 9, 2011 - 17:43
Written by

A couple of issues have begun to sting us repeatedly and I see others raising same issue.



Getting a Default Header/Footer used in the SysTplMsgs


SysTplMsgs (System Template Messages) are found here /civicrm/admin/messageTemplates?reset=1)


To avoid repeated copying of the desired header/footer in to the upto 22 SysTplMsg, one option would be to add a checkbox to the CiviMail Footer/Headers (/civicrm/admin/component?reset=1)


So the current Default in CiviMail Header/Footers would become Default CiviMail, and a new option/column would show for Default SysTplMsg.


This would then cause the requisite code to be included here in the SysTplMsgs



 <!-- BEGIN HEADER -->
  <!-- You can add table row(s) here with logo or other header elements -->
Clearly would have to avoid any table width settings clash that might mess up the layout.
Additional info could still be added under the default header. Eg we usually include some code to show the Participant/Contribution/Membership/Contact ID depending on the context.
Consistent use of Pay Later option
Our clients general require the SysTplMsg to differentiate between 'paid' and 'pay later' in as much as the 'paid' should be a 'receipt' and the 'pay later' should be an invoice. This is covered in some circumstances, but not all, in particular for 'pay later' that is handled at the backend (eg someone posts in a Membership form and indicates that the payment will be made as a bank transfer)
The Subject for eg online Memberships already has
{if $is_pay_later}{ts}Invoice{/ts}{else}{ts}Receipt{/ts}{/if} - {$title}
But if an 'invoice' for a 'pay later' Contribution is made from the back end 'pay later' is not considered yet and currently provides
{if $receiptType EQ 'membership signup'} {ts}Membership Confirmation and Receipt{/ts} {elseif $receiptType EQ 'membership renewal'} {ts}Membership Renewal Confirmation and Receipt{/ts} {/if} 
so requires something like 
{if $is_pay_later}{ts}Membership Invoice{/ts}{elseif $receiptType EQ 'membership signup'} {ts}Membership Confirmation and Receipt{/ts} {elseif $receiptType EQ 'membership renewal'} {ts}Membership Renewal Confirmation and Receipt{/ts} {/if}
Then we also need to insert   

{if $is_pay_later}

to get the Pay Later instructions in to the body of the email.



Do the above suggestions make sense to others and do they avoid pushing people in a solution they may not want for reasons I can't picture?


Thanks for your input. I'd just like to respond to Part 1 as I've recently been through the process of updating the email templates on our site.


What sort of HTML element is represented in the System Templates?

If the header and footer are sourced from outside the template, then what is in the template? I imagine (from the current implementation) this will be one or more TR elements, and that the header sets up the TABLE, TBODY, etc, and the footer closes those elements down.

It's important to agree this so all the system templates are useable with the header/footer.


Both header AND footer

The current system message templates suggest where the header goes, but there's no guidance on footer placement etc.

I think you are suggesting the structure of the template would become (asuming the message is a series of TR elements) ...

      Import header
      <TR> content 1 </TR>
      <TR> content 2 </TR>
      <TR> ... </TR>
      Import footer


... noting that the CiviMail headers and footers need all the HTML to create a well-formed message.


NOT the default CiviMail header and footer

I'd suggest the header and footer for the system messages is not the default CiviMail one. Some reasons ...

  • I've put permalink tokens in my header. This won't work for system template messages where a permalink is not appropriate.
  • My CiviMail HTML editor doesn't assume I'm inserting TR elements into my message. Thus in my CiviMail templates I have the header set up a TD element in a table, so the editor can just paste HTML. This could be mitigated by viewing the system template contents as the contents of a TD, rather than a series of TR elements (see above).

Good idea - I concur.

I think it would be confusing to have to go to civimail (that can be disabled anyway) to modify the header or a non civimail email.


As the sys messages are already smarty aware, I'd suggest to create a new function plugin CRM/Core/Smarty/plugins/function.includeMessage.php to include a different message


So you'd create a new message "pete_header" with the logo and bla bla you want and in your message(s), you'd add

{includeMessage message="pete_header"}


And yes, creating a new header message and adding a {includeMessage message="header"} in all the messages seems like a good idea. Should we do it for the upgrades as well?



P.S. and in the grand tradition of trying to enlarge vastly the perimeter of the initial question: it would be absolutely smashing if the images could be saved and attached to the messages sent and embedded directly (so you don't have to click here to display external images)

Yes, both suggestions make sense to me.

I'm not sure I follow ken's concern below about permalinks, and why they are inappropriate in system message templates.



Does CiviCRM generate permalinks for system messages? (eg, a contribution receipt containing a personalised note.)