Author Topic: Improving CiviMail and Views2 integration (Read 4257 times)

GinkgoFJG · October 01, 2010, 08:02:26 am

Hello,

A lot of my clients who are migrating over from other systems are accustomed to having a page on their websites that displays a list of e-newsletters or action alerts. From that list, they are accustomed to clicking on any single message and having the e-newsletter displayed in its entirety, in the original HTML format.

I've submitted some code (which should be available in 3.3) which exposes more CiviMail fields to Drupal Views, making this possible. However, this has raised a few other questions:

What to do with tokens (e.g., Dear $firstName)? Should they be printed to the screen, stripped out, or replaced with some markup (e.g., Dear "? Views would allow me to expose two different fields (e.g., "Original Message" and "Message with Tokens Stripped Out") if it makes sense to give Civi implementors more options, but I can see how this would get cluttered fast.
What to do about <html> and <body> tags in the message? Embedding an HTML document (the newsletter) inside another document (the Drupal template) will result in two sets of <html>, <body>, and possibly other tags in the same page, making for invalid HTML. Should Views strip these tags from the e-newsletter, or should be up to each implementor to decide how they want to deal with this?

I'm happy to continue working on this integration, as it's a request I get frequently, but I thought it'd be best to get input from others in the community as to the best way to approach it.

Thanks!
-Pitt

GinkgoFJG · October 04, 2010, 06:31:43 am

I've been thinking about this more and am considering leaving the tokens in there, then writing a Drupal module that uses jquery (or some other mechanism) to do a find and replace on the tokens. There may even be a module out there already that I can modify to this end. This will give implementors more control, as they'll be able to define their own replacement rules.

As for the duplicate <html> and <body> tags, I'm still struggling with ideas here. Ideas, anyone?

xavier · November 06, 2010, 03:34:33 am

Hi,

I'm trying to put in one place the various improvements requests that have been floating around:

http://wiki.civicrm.org/confluence/display/CRMDOC32/Improvements+on+CiviMail

Could you check if you find it complete, and if you'd be able to work/fund some of it ?

(hopeing to start a make it happen campaign on it)

X+

GinkgoFJG · November 06, 2010, 07:18:38 am

Xavier,

I tried to edit your wiki page but the wiki tells me, "This documentation refers to CiviCRM 3.2, current stable version. 3.2 documentation is now 'read-only'." So I'll leave my comments here.

I'd add that I've found forwarding replies to be tricky to implement.

Regarding this item, "Have an online readable version of the newsletter, with the link being easy to add (token) at the top of the mail (click here to read it online...)," most of this now possible with the changes I made that are available in 3.3 (I think). The way to do it is via Drupal Views. Building on the work that I've done, I'd like to expose to Views the Groups that the message was sent to; this would allow you to display only messages sent to the "E-news Recipients" group, for example, or to exclude messages sent to the "Major Donors" group. Alternatively, it may make more sense to allow Civi Admins to tag individual messages (e.g., public vs private, or campaigns vs development, or free tagging for that matter) and to filter against those tags. This could have uses other than publishing the newsletter online, e.g., allows admins to answer the question, "how many emails have we sent out about the Stop Evil Company X campaign vs. the Healthy School Lunches campaign?"

I like the idea of a token at the top of messages to add the "read it online" link, but I think this could be difficult to implement, as people may want the archive available via different paths, e.g., example.com/enews vs example.com/get-active/archive.

Another challenge is that to get HTML-based emails to display correctly, it seems that it's best to bring the newsletters in via an iframe. Otherwise, the CSS of your main website starts acting on the HTML of your newsletter, and in some cases you get a pretty ugly newsletter as a result. To make it work you kind of need two Views and two themes. I'm not sure I'm explaining that well; does that make any sense?

As for how I can contribute, I'm happy to keep working on the Views/CiviMail integration, as I have a decent handle on how that works. I could probably help in other areas, too, but I'm not yet familiar with the code in question. I'm not in a position to fund any work at present, but if someone can fund mine, I can put the work at the top of my list instead on the "whenever I have time" list.

xavier · November 06, 2010, 08:28:43 am

Hi,

I'll check for the access rights, it needs to be cloned to 3.3 indeed to be readable.

As for the view/public information: the problem is that all the {token} are not going to work without knowing the user, so can't be publicly visible. I like you tagging idea.

As for the layout, I wouldn't display any layout from the site, just the newsletter.

X+

GinkgoFJG · November 06, 2010, 01:34:43 pm

Quote from: xavier on November 06, 2010, 08:28:43 am

As for the view/public information: the problem is that all the {token} are not going to work without knowing the user, so can't be publicly visible. I like you tagging idea.

Not sure what you mean by this...

Quote from: xavier on November 06, 2010, 08:28:43 am

As for the layout, I wouldn't display any layout from the site, just the newsletter.

Then this can be done with the functionality already in 3.3. You need two views. Create one view which is just a list of dates, subject lines, and whatever other metadata you need from the mailing, with links to the individual messages. The second view should take an argument -- say /enews/$mailing_id -- which is used to pull the HTML for the header, footer, and body content of the message specified by $mailing_id. What I'd then do is create a theme which has basically no markup, e.g., page.tpl.php looks like this:

Code: [Select]

<?php echo $content; ?>Then use the Drupal Sections module to specify the minimalist theme for all pages under /enews (or whatever URL you're using). Make sense?

-Pitt

Donald Lobo · November 06, 2010, 01:40:14 pm

Quote from: pittstains on November 06, 2010, 07:18:38 am

As for how I can contribute, I'm happy to keep working on the Views/CiviMail integration, as I have a decent handle on how that works. I could probably help in other areas, too, but I'm not yet familiar with the code in question. I'm not in a position to fund any work at present, but if someone can fund mine, I can put the work at the top of my list instead on the "whenever I have time" list.

hey frank:

Any rough estimate on the number of hours needed to do this and/or the expected $$$ amount? Might be worth blogging about it (on civicrm.org, i can give u the privileges) and specing out the project. more likely to find folks who have a need for this

lobo

xavier · November 07, 2010, 02:12:30 am

Quote from: pittstains on November 06, 2010, 01:34:43 pm

Not sure what you mean by this...

I meant that if your newsletter starts with Dear {contact.first_name}, then you won't be able to know what first name to display.

X+

GinkgoFJG · November 08, 2010, 02:55:11 pm

Quote from: xavier on November 07, 2010, 02:12:30 am

I meant that if your newsletter starts with Dear {contact.first_name}, then you won't be able to know what first name to display.

X+

Yeah, I think maybe the way to handle that is with a Drupal module that lets you set replacement patterns. E.g., for pages under /enews, replace all occurrences of {contact.first_name} with a configurable text such as "Friend" or "Supporter." Unfortunately, all of the solutions I've offered you are kind of piecemeal. It's perhaps not as nice a monolithic solution as you'd like.

Quote from: Donald Lobo on November 06, 2010, 01:40:14 pm

hey frank:

Any rough estimate on the number of hours needed to do this and/or the expected $$$ amount? Might be worth blogging about it (on civicrm.org, i can give u the privileges) and specing out the project. more likely to find folks who have a need for this

lobo

Hey, Lobo,

I'd be happy to do so, but I think maybe we should let the spec get a little more fleshed out. At this point I'm not sure which features I'd be estimating for. Also, I'm just kind of making stuff up on the fly -- e.g., the message tagging -- and I'm not sure how that idea fits with where the rest of the project is headed. Would be great for others who have been with the project longer than me to comment and give this conversation a bit more direction.

petednz · November 08, 2010, 03:31:13 pm

Quote from: pittstains on October 01, 2010, 08:02:26 am

What to do with tokens (e.g., Dear $firstName)? Should they be printed to the screen, stripped out, or replaced with some markup (e.g., Dear "?

Sorry I can only add questions at this point but does the above mean it would need to strip out for anonymous (if they have permission to even view the newsletter) but print for authorised users - or at least for authorised users who received the actual email??

Dave Greenberg · November 11, 2010, 10:12:10 am

I think your initial 'markup replacement' idea for tokens is pretty slick (Dear ) - since it provides folks with really flexible mechanism (customized css file) to do replacements for any tokens they typically use in their mailings. As in this example, I think you could get away with just omitting the actual tokens - which would also allow folks to completely hide things like optOut links that they may not want on the web page version.

CiviCRM Community Forums (archive)

News:

Author Topic: Improving CiviMail and Views2 integration (Read 4257 times)

GinkgoFJG

Improving CiviMail and Views2 integration

GinkgoFJG

Re: Improving CiviMail and Views2 integration

xavier

Re: Improving CiviMail and Views2 integration

GinkgoFJG

Re: Improving CiviMail and Views2 integration

xavier

Re: Improving CiviMail and Views2 integration

GinkgoFJG

Re: Improving CiviMail and Views2 integration

Donald Lobo

Re: Improving CiviMail and Views2 integration

xavier

Re: Improving CiviMail and Views2 integration

GinkgoFJG

Re: Improving CiviMail and Views2 integration

petednz

Re: Improving CiviMail and Views2 integration

Dave Greenberg

Re: Improving CiviMail and Views2 integration