When preparing an email newsletter, one part of it that is time consuming is gathering together all the content that is needed. In my experience, virtually all the content already exists elsewhere, such as in the local CMS, in CiviCRM, or on a blog, or some other online source. So I was thinking how can I make this process easier. What I did: I created mail merge tokens for CiviCRM that autofill a list of recent blog posts, stories, or any other type of CMS content. So the end-user sees a list of tokens, one for each content type, each term/category, each aggregator feed, and for each date range. Such as "Content of type 'blog' created in the last 7 days" . What is particulary powerful about this approach, is that if you are also using a CMS aggregator (such as the aggregator module in Drupal core) then virually any external RSS feed is turned into CMS content, which is now available as a CiviCRM token.
Some examples of how this new extension may help your organization:
- Your staff posts new content of type "story" each week.Your monthly newsletter editor can use the new token for "Content of type 'story' created in the last 1 month" to save time preparing the newsletter.
- A national organization you are affiliated with has a number of blogs that they host. Your local organization would like to include recent blog posts from the national organization in the local member newsletter. Your local webmaster previously configured the aggregator module to pull in those external blogs into your CMS. Your monthly newsletter editor can use the new token for "Content of type 'feed item' created in the last 1 month" to save time preparing the newsletter.
- Any other situation where there is existing content that you want to include in your email or PDF.
This new extension "Content Tokens" is published in the CiviCRM extensions area https://civicrm.org/extensions/content-tokens
This new extension is designed in the same style as the "Fancy Token" extension that provides tokens for upcoming events, contribution pages, profiles, and WebForms.
-Sarah sarah@pogstone.com
Comments
Cool - that looks like a pretty good idea.
Nice idea, Sarah. Is it possible to have a screen shot to see what that might look like?
Ken - I added a screen shot in on the extension page at: https://civicrm.org/extensions/content-tokens
Here is what a person would see after clicking "Insert Token"
I moved the screen print from the comments to the main body above.
Sounds like a great idea, Sarah. I remember working on this type of newsletter issue a few years ago using FreeForm's Drupal content export approach. The hard parts as I recall were a) selecting only the relevant nodes manually using a Drupal module for queues to curate things, b) getting the css and graphic design inlined, and c) having proper absolute image links for the newsletter to work in the email context. What have you found in terms of a) being able to selectspecific nodes of a particular type, and b) ease of formatting using this approach? Also, could you elaborate on how this works in WordPress?
Thanks!
Hi Sarah,
Thanks for this. A few questions given prior experiences with other modules trying to crack this nut with other architectures:
1. How easy is it to format the fields in the node using inline css? (I bet that works well on this approach.)
2. Any restrictions on what people enter into rich text fields in terms of formatting / rendering issues in different email clients?
3. Could you elaborate on how this works in WordPress?
4. Where are the timeframes for the content types in the example set? Is it possible to get only new content rather than also including editted content?
Joe -
1) I am doing very simple formatting currently. ie wrap each item in a DIV tag and convert any relative URLs to absolute URLS. Inline CSS is a good idea, where should the CSS be pulled from? Can you provide an example of the inline CSS syntax you would want? My main concern is how to marry the formatting of the newsletter with the formatting of the content pulled in, in a foolproof way. (Sometimes content authors use crazy fonts, etc)
2) Currently I do not alter the styles from the original conent. Per previous question, not sure what the best approach is. One thought is to strip all formatting from the content item and use an inline css in the token/email to ensure good results for all email clients. (MailChimp has a feature to include RSS feeds in emails. Would be good to know what they do about external formatting)
3) In WordPress, the extension queries the data from the WordPress tables instead of the Drupal tables. The end-user inserts tokens as shown in the extension screen print. (More testing is needed from WordPress folks, I usually test under Drupal) In Drupal I am using the "teaser" of the node. In WordPress I am currently getting the whole post. Hopefully a WordPress person can explain how to get the "teaser" equivilent for WP.
4) Currently the extension is checking the date changed, not date created. I can create more tokens so that the user has a choice. (Was trying to avoid overwelming the user with too many token choices)
This is a great extension. Like others I'd need some inline CSS to really make it work for newsletters.
Regarding #2, could you reference a stylesheet and convert to inline. (e.g. if the referenced style sheet has something like ".fancy-p { font-family: tahoma; font-weight:500;}", all instances of '<p>' would be output as '<p style="font-family: tahoma; font-weight:500;">'. You could use "fancy-h1", "fancy-h2", etc. to target node titles and summaries with the standard WYSIWYG editor.
Joe -
1) I am doing very simple formatting currently. ie wrap each item in a DIV tag and convert any relative URLs to absolute URLS. Inline CSS is a good idea, where should the CSS be pulled from? Can you provide an example of the inline CSS syntax you would want? My main concern is how to marry the formatting of the newsletter with the formatting of the content pulled in, in a foolproof way. (Sometimes content authors use crazy fonts, etc)
2) Currently I do not alter the styles from the original conent. Per previous question, not sure what the best approach is. One thought is to strip all formatting from the content item and use an inline css in the token/email to ensure good results for all email clients. (MailChimp has a feature to include RSS feeds in emails. Would be good to know what they do about external formatting)
3) In WordPress, the extension queries the data from the WordPress tables instead of the Drupal tables. The end-user inserts tokens as shown in the extension screen print. (More testing is needed from WordPress folks, I usually test under Drupal) In Drupal I am using the "teaser" of the node. In WordPress I am currently getting the whole post. Hopefully a WordPress person can explain how to get the "teaser" equivilent for WP.
4) Currently the extension is checking the date changed, not date created. I can create more tokens so that the user has a choice. (Was trying to avoid overwelming the user with too many token choices)
Joe - I updated the extension to look at "created" date instead of changed date
Thanks for the extension: it's useful!
Hi,
I've installed 2.7 in a CiviCRM 4.5.3 and I get a bug related to this module: suddently New Contact Names were not showed at Contact View, nor search view, and what is shown is contact email. In old contacts, I can edit contact name, but ols contact name is shown (new name is saved, and I can see it again when I edit contact name, but not shown).
I get a warning related with this extension, and when I disbaled it, this buggy behavior dissapears.
What is the warning message?