As of alpha8 (possibly before) mimemail is no longer generating text alternative versions of email. The culprit for this bug is in mimemail.inc

function mimemail_html_body($body, $subject, $plaintext = FALSE, $text = NULL, $attachments = array()) {
  if (empty($text)) {
    // todo: remove this preg_replace once filter_xss() is properly handling
    // direct descendant css selectors '>' in inline CSS. For now this cleans
    // up our plain text part. See mimemail #364198, drupal #370903
    $text = preg_replace('|<style.*?</style>|mis', '', $body);
    $text = drupal_html_to_text($text);
  }

Changing to the following brings this back, though I'm not sure what the implications are for the xss issue. Given that this should be fully plain text, I'm not sure what the initial filter was all about.

function mimemail_html_body($body, $subject, $plaintext = FALSE, $text = NULL, $attachments = array()) {
  if (empty($text)) {
    // todo: remove this preg_replace once filter_xss() is properly handling
    // direct descendant css selectors '>' in inline CSS. For now this cleans
    // up our plain text part. See mimemail #364198, drupal #370903
    $text = drupal_html_to_text($body);
  }
CommentFileSizeAuthor
#17 mimemail_1116930_02_6x.patch1014 bytessgabe
#17 mimemail_1116930_02_7x.patch1.01 KBsgabe
#14 mimemail_1116930_01.patch1013 bytessgabe

Comments

sgabe’s picture

sgabe commented

I cannot reproduce this, can you give an example?

sdague’s picture

sdague commented

I can't give a live example because I had to hot fix it on our site - http://mhvlug.org. I'm using the print module restricted to admins to generate meeting announce emails via mimemail. If there is some slice of that data that I could give you that you think would be useful, let me know.

sgabe’s picture

sgabe commented
Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

That preg_replace() removes the CSS code from the message before passing it to drupal_html_to_text() since that cannot handle direct-descendant CSS selectors (>) properly. If you remove that line there is a chance (depends on your theme or mail.css) you will see some CSS code in your messages.

If you can provide the value of the $text variable before and after these modifications, that would be great help to see what happens exactly.

You can use the Devel module's dd() function which logs any variable to a file named “drupal_debug.txt” in the site’s temp directory.

Please, use the "code" and "php" tags when posting code.

pol’s picture

pol
Location Brussels
commented

Why not using $text = strip_tags($body); ?

sgabe’s picture

sgabe commented

Because that will work only if the CSS Compressor is enabled, otherwise it won't remove the CSS.

pol’s picture

pol
Location Brussels
commented

So, if CSS compressor is not enabled, where is the CSS ? always between <style></style> or somewhere else ?

sgabe’s picture

sgabe commented

It will be between style tags, but it can be inline too (that would be removed by strip_tags). Depends on the content, just think about the WYSIWYG editors.

pol’s picture

pol
Location Brussels
commented

I'm proposing a solution in this patch.

sgabe’s picture

sgabe commented

But, the line $text = preg_replace('|

|mis', '', $body); always returns an empty string.
I am trying to reproduce this by adding new users and sending notifications about the new account. I am checking the value of $text before and after the above line. In every case (with or without CSS Compressor or mail.css) the text alternative is automatically generated just fine. As I see the preg_replace() properly removes the style tags and drupal_html_to_text() deals with the rest. What am I missing here, fellas? Why is this not working for you?
pol’s picture

pol
Location Brussels
commented

Hello sgabe,

We are using a custom form, extended from the stock contact module form.

You can have an example of the HTML generated here: http://pastebin.com/FitSh1Zz

If you use that HTML, it won't work with your current code, that's why I did the function mimemail_strip_html_tags().

sgabe’s picture

sgabe commented

It seems that preg_replace() crashes when the text is too large.

pol’s picture

pol
Location Brussels
commented

Yes... unfortunately.

sgabe’s picture

sgabe commented

Then lets just extract the body and pass it to drupal_html_to_text().

    preg_match('|<body.*?</body>|mis', $body, $matches);
    $text = drupal_html_to_text($matches[0]);
sgabe’s picture

sgabe commented
Version: 6.x-1.0-alpha8 » 6.x-1.x-dev
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new mimemail_1116930_01.patch1013 bytes

See the attached patch.

pol’s picture

pol
Location Brussels
commented

I think that's the way to go.

I just tested with the text from http://pastebin.com/FitSh1Zz and it seems to work pretty good.

Unfortunately, It will be impossible for me to do more tests on this until Monday.

I'll give you a report on it monday if you want, I think it's gonna be positive and maybe an alpha9 will be out :-)

Thanks sgabe ;-)

sgabe’s picture

sgabe commented
Title: no longer generating text alternatives » No text alternative if the CSS is too large

Unfortunately this is not the one that blocks the new release but #1044534: Improve support for multipart/mixed messages for example. However, thanks for your help with this and for posting the other one too. ;)

sgabe’s picture

sgabe commented
Status: Needs review » Fixed
StatusFileSize
new mimemail_1116930_02_7x.patch1.01 KB
new mimemail_1116930_02_6x.patch1014 bytes

Committed for both branches. Let me know if you encounter any problem with this.

pol’s picture

pol
Location Brussels
commented

Patch is working pretty good, tested this morning, everything's fine...

About #1044534: Improve support for multipart/mixed messages, I still have to look at it, but it seems quite complicated.

Don't you think we should release an alpha9 correcting #1116930: No text alternative if the CSS is too large and #1167576: Accept plaintext and text parameters for system messages ?

Thanks !

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

milovan’s picture

milovan commented
Version: 6.x-1.x-dev » 7.x-1.x-dev
Issue summary: View changes

I have an issue with Mimemail sending empty email to users who hecked to receive only plain emails.
Debugging, I came to the following piece of code that retruns body as empty string after regex:

preg_match('|<body.*?</body>|mis', $body, $matches);
$plaintext = drupal_html_to_text($matches[0]);

Variable $matches[0]is empty, because this regex doesn't even work, I believe. I tried on a couple of online regex testers and none of them matched anything with for example following html mail code:

<pre><p>user001,</p> <p>A request to reset the password for your account has been made at example.com.</p> <p>You may now log in by clicking this link or copying and pasting it to your browser:</p> <p><a href="https://example.com/user/reset/1/123456789/aPilA0aNJXfg3e43HLKehfbCkmvrJT24fdJxggsO0">"https://example.com/user/reset/1/123456789/aPilA0aNJ...</a></p> <p>This link can only be used once to log in and will lead you to a page where you can set your password. It expires after one day and nothing will happen if it's not used.</p> <p>--  example.com team</p> </pre>

My second question is, what "mis" in regex is for? I couldn't find a reference what that is.
Thanks!

matslats’s picture

matslats commented

Having the same issue.
I don't understand this regular expression, and the case of it returning no matches is not covered.
preg_match('|<body.*?</body>|mis', $body, $matches);
The problematic email is being generated by the support module.
The mail body at that moment is a chunk of valid html inside

tags.

tr’s picture

tr commented
Issue summary: View changes

Added code tags to the original post to make it readable.