When we try to use variables - even just dropping the complete list into the message textbox, thye fail to render their values and render as explicit variable code in the emails sent out.
Same with the HTML (in a separate exercise) - when set to HTML content and inserted in the message textarea, it renders as literal code in the outgoing emails. And CSS (for body tag) is ineffectual
I keep trying to see what I could be doing wrong or if there is a module or email rendering framework dependency I'm missing but have checked and tried many times.
This has come up on the eve of a launch so a bit scary!
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | user_import-1928404-html_mail_d7.patch | 5.42 KB | xurizaemon |
Comments
Comment #1
robert castelo commentedCould you paste in an example to this issue.
Comment #2
timoti commentedThanks for getting back so soon on this.
Actually we had some improvement which might have been browser related (I was using an old FF so as to be able to use FireSass with Firebug).
Variables are now working, but we still have an HTML and CSS rendering failure - hence i have retitled the issue. This is after a couple of us have tested quite a bit.
email output in gmail and outlook.com looks like
body { color: green; margin: 2em; font-size: 16px; } h2 { color:red; } ======== HEADING ============================================================= Site Name Adipisicing typewriter post-ironic, tofu art party fixie enim cosby sweater pinterest. Gluten-free veniam laboris master cleanse, salvia actually aesthetic odio qui fixie. Cliche sartorial pickled Austin pop-up, do keffiyeh shoreditch put a bird on it authentic biodiesel in. address@outlook.com, -------- TESTING ------------------------------------------------------------- Natural Areas, http://sitename.org, sitename.org, Wed, 02/27/2013 - 20:13, http://sitename.org, sitename.org/user, http://sitename.org, sitename.orguser/88/edit, http://sitename.webhop.org/user/reset/88/136689403/dsfg3453azkWFXPYKdsaf....
(liberties taken with the above sample to preserve the innocent)
So it looks like it's forcing conversion to text even though HTML is selected
We looked to see if there was any dependency on htmlmail or somesuch - can find none…
Thanks
Comment #3
robert castelo commentedWhat's the message you are putting in the message box of the import?
Comment #4
timoti commentedactually lost the source for that but it will have been something like:
Comment #5
xurizaemonTry this. Moves the hook_mail() implementation back to .module, implements an HTML mailsystem interface, adds a hook_update_N to add.
Untested with plaintext emails!
Comment #6
timoti commentedThanks grobot - this is a definite fix - have been using for several weeks now with no issues. There are a couple UX things I'll suggest or patch in the help text area - such as making it clear to exclude body tag, head from html. But functionally - its great. I do recommend this patch be incorporated. Thanks again
Comment #7
timoti commentedso.. 'll be so bold as to say we can say RTBC
Comment #8
groston commentedQuestion with regard to sending HTML formatted email via the User Import module: Does the Drupal HTML Mail module need to be installed for the email to be properly formatted?
I ask because I applied the patch from #5 above to my installation (Drupal 7.2.7, User Import V7.x-2.2) and I am still experiencing the behavior noted in #2 above. (Please note that I do not have any Drupal development experience, thus my patching of the files may not have been done correctly. In particular, I am concerned about user_import.install - I simply added function user_import_update_7010() to the file before function user_import_update_7200() - no idea if this was the right thing to do.)
Comment #9
dodlhuat commentedThis bug is still active. You can't use any code (!...) in HTML Mails.
Comment #10
dodlhuat commentedComment #11
xurizaemon@dodlhuat, this patch was submitted to 1.x and was marked RTBC previously.
Please test patch against 2.x, and give your feedback.
If it works for 2.x then you can RTBC against 2.x
If it doesn't work for 2.x then you can submit an updated patch yourself and move to "Needs Review", or if not capable of doing that you can move to "Needs work" (and hopefully contribute towards someone else working on it).
Description of the Status value can be found in the Issue queue handbook.
Comment #14
robert castelo commentedThanks, commited to 7.x-3.x branch