CiviCRM Community Forums (archive)

Hi,

We have been working with a simple token to embed a view into a civimail https://github.com/eileenmcnaughton/civicrm_views_token (in this case the customer uses nodequeue to group a selection of articles for the newsletter although I can think of other use cases).

However, the issue is the styling. We can add style tags to the header & this gives us a nicely formatted email ..... unless people are using gmail - which removes them & requires them to be in the html elements. I understand there are modules / libraries out that that will process html & 'in-line' style elements - has anyone investigated at all.

NB - adding the style to the view seems like a drag

OK so we tried the first of these & found it worked with this patch

https://github.com/eileenmcnaughton/civicrm-core/commit/116dfd92348d2e08b0149bac0d0283c7f3353b23

and adding the file to packages

https://github.com/eileenmcnaughton/civicrm-packages/commit/972b1b02ee0af41b61aa71678aece422235f7832

What that means is that links to stylesheets with the the html are converted into inline html - which is quite powerful actually.

In conjunction with https://github.com/eileenmcnaughton/civicrm_views_token this really does open up the possibility of 'no-touch newsletters' - ie. a fully-formatted list of latest / most popular news items, a view of upcoming events. A weekly security advisory  or whatever - it addresses the issue of having to both put content on your website AND in your newsletter.

So, what are the technical issues

1) testing - any issues with this will almost certainly happen on edge cases  - so it's very hard to test thoroughly. This is substantially mitigated by the fact there is no change at all unless there is a css link (e.g. <link rel="stylesheet" type="text/css" href="http://civicrm.org/civicrm.css">

2) performance - at the moment we have it parsing once per mail - there is a case for that given it's not impossible that a token could provisionally add a stylesheet - however, if we assumed the stylesheets would always be the same we could return early if none are found in the first one. We probably need a 'big sender' to test to see if performance issues exist when there are stylesheets present

3) deployment - if the in-lining is accepted for core but not until 4.5 then we have to figure out how to deliver it for the drupal views token prior to then - I don't fancy packaging the 'late-parser' approach in the above patch as an extension. We could do the parsing in the drupal_views_token module & process only the portion added by the token - but then we have to consider what happens with 4.5 if the late parser is included - we wouldn't want it to be processed twice (for performance & possibly output reasons).

I will probably wait to see what sponsorship there is before trying to look at a deployment approach that would make this more generally available.

4) note that sending a test email from civimail doesn't seem to process token hooks

5) I also thought it should be possible to configure a header with only html since the html message is parsed to text at the end but the field is compulsory. I'm not sure if this rules out adding the views token (which returns html) in the header element - I would need to do more testing as to what happens to the text version

I've added it to the 'compose' function - and, importantly, it is after the token replacement - what I found is

1) Wysiwig editor - inline stylesheets work in the editor - but if you have them in your header rather than your template you may not get the benefit of them (unchanged / need to confirm as I think headers may be visible)
2) preview editor - yes, with this patch inline stylesheets are applied in the preview editor (header or otherwise)
3) test email - doesn't swap out the hook token & I don't think it does the inlining either
4) Civimail emails - yes - styles converted to inline html styles gmail & other email clients

Re existing inline css - I have done limited testing of that - you might want to give a test. The patch is very small & easy to apply

We have now moved this to an extension

https://github.com/eileenmcnaughton/nz.co.fuzion.cssinline

Regarding this extension, I have a question.

If I install the extension, I see it is bundled with cssin already installed in the packages directory. When I create a newsletter template I insert a link to my stylesheet:

<link href="http://mysite.org/sites/all/themes/mytheme/css/newsletter.css?ver=3.0" rel="stylesheet" type="text/css" />

My stylesheet lives at: /sites/all/themes/mytheme/css/newsletter.css

How do I tell the WYSIWYG tool that the styles I have defined in my stylesheet exist? Is there a config page somewhere for the WYSIWYG that I don't know about?

Thanks,
Andrew

Thanks Eileen,

I must be doing something wrong then... It doesn't seem to be doing that.

This is a D7 site running CiviCRM 4.6.20 LTS

I've installed the extension and as far as I can tell it installed correctly. cssin is bundled with the extension so I haven't downloaded it or anything.

I've got a very simple stylesheet called at: /sites/all/themes/mytheme/css/newsletter.css It jus has a couple of styles defined as follows:

.copy {
  font-family: helvetica, arial, sans-serif;
  font-size: 1em;
}

.copy-large {
  font-family: helvetica, arial, sans-serif;
  font-size: 1.5em;
}

I've got a simple email template that contains nothing except for:
<link href="http://mysite.org/sites/all/themes/mytheme/css/newsletter.css?ver=3.0" rel="stylesheet" type="text/css" />

The link is supposed to go in the EMail template, Administer -> CiviMail -> Message Templates, correct?

I've cleared cache's and that hasn't made a difference.

By the way, I see that the CKEditor in CiviCRM has a file called styles.js that tells it what styles it can use.