Notice: Undefined offset: 0 in mimemail_html_body()

I got the same error message after updating the mime mail module from previous version="7.x-1.0-beta4" to version="7.x-1.0". The mails were not sent correctly: the mail body was empty. I re-installed now beta4 again - hoping that this fixes the issue (so long it seems so). I will report here, if this is not the case.

I experiment the exact same problem (same watchdog message and empty body email) since the upgrade to 1.0. Reverting to 1.0beta fixed the issue.

I managed to reproduce the issue in combination with mimemail_compress and bootstrap.
The offending piece of CSS looks as follows:

/* the emails are themed to have <body id="site-mail"> */
#site-mail {
        .element-invisible { display: none; }
}

This in turn gets nested into the compressed body as follows:

<body id="site-mail" class="user-password-reset" style="margin-top:12pt;margin-left:1em;margin-right:1em;.element-invisible
{
display:none;">

(Note the missing closing bracket)

For whatever reason, the sub-class gets nested into the body style="" attribute; unfortunately, I'm not familiar enough with XPath/DOMDocument to fix it.

The whoopsie happens in file mimemail_compress.inc, lines 157 - 161:

    // This removes styles from your email that contain display:none. You could comment these out if you want.
    $nodes = $xpath->query('//*[contains(translate(@style," ",""), "display:none")]');
    foreach ($nodes as $node) {
        $node->parentNode->removeChild($node);
    }

It seems that the new compressor sub-module doesn't play well with bootstrap as there have been other issues with selectors/styles as well, I had to revert to beta4 to resolve it.

Update: here's the relevant bits of my phpinfo():
https://hastebin.com/gupopimaso.rb

Same issue here, bumping to major (might even be critical). Empty mails are kinda bad...

When sending out email notifications, about 3 of 20 mails are empty in my case, producing this message. Is there a solution to this problem meanwhile?

I had to add an if () near line 376 in mimemail.inc to check that there was a match, then plain text emails were no longer blank.

function mimemail_html_body($body, $subject, $plain = FALSE, $plaintext = NULL, $attachments = array()) {
  if (empty($plaintext)) {
    // @todo Remove once filter_xss() can handle direct descendant selectors in inline CSS.
    // @see http://drupal.org/node/1116930
    // @see http://drupal.org/node/370903
    // Pull out the message body.
    preg_match('|<body.*?</body>|mis', $body, $matches);
    if (!empty($matches[0])) { // <----- ****************************
    	$plaintext = drupal_html_to_text($matches[0]);
    } else {
    	$plaintext = drupal_html_to_text($body);
    }
  }

+1

Using Rules to send mails to users with a role. I'm trying to use SMPT in combination with mimemail (mimemail_smtpmailsystem). This fails due to above error and no mails are sent. Using only mimemail as mailsystem the error occurs but mails are sent correctly anyway.

Any solution on this problem?

Upping this to critical, module is highly unreliable at the moment.

In my case the similiar error was occured when having "Locale"-module enabled. I wasn't required to have it for my setup, so disabling it fixed the issue.

Users who choose to receive text-only emails will receive blank messages, because $plaintext is empty in mimemail_html_body() when, for whatever reason, there is no body tag in $body (apparently it happens with the "forgotten password" email, at least for me). scrypter's approach seems fine, see attached patch.

Better.

But I still reverted to beta4.

I can confirm this behaviour: php notice and empty system mails for users, who set their email to plain-text-only.

mimemail version: 7.x-1.0

And I can confirm that patch #14 applies and fixes the issue.

I managed to track down the issue to the head section of my mimemail template, removing the following lines fixed the blank emails for me:

    <?php if ($css): ?>
    <style type="text/css">
      <!--
      <?php print $css ?>
      -->
    </style>
    <?php endif; ?>

Even though I wasn't trying to insert any css into the head of the email it was breaking it and producing a blank body without a header, only a footer displayed.

patch #14 works for me, thank's

Patch #14 works for me, too.
However, I've noticed double processing of links placed to the text by the drupal_html_to_text function: duplicates of link numbers (e.g. "url[1][1]") in the original text and progressively increased lists of links in the footnotes.

P.S. Sorry, I think now that this duplication is due to the second procession of plain-text messages by this function in the Views Send module (which I use for bulk sending).

Problem observed for new content notifications. Does not happen systematically. Maybe only on less than 10% of the notifications which are generated.

Notifications are generated according to rules an roles. Using Drupal 7.56, Rules 7.x-2.10

Reverting MimeMail to beta 4 does not solve the problem. Using patch #14 makes that no notifications are sent anymore.
Is the problem really in MimeMail or in other modules that are also involved in the chain that contributes to generating notification content.
Notifications are sent in html format.

Any idea about where to look?

#14 worked for me as well. In my case the client reported that the body received emails were all blank.

FWIW, I encountered this issue because I had an implementation of hook_mail that was never setting the body of the message. While this is probably not the case for most of the people on this thread, it is worth noting that something like that can also cause this issue.

#14 took care of the error for me too.

I confirm that #14 also corrected the problem on my site.

Came across this issue while having the same problem. Using Rules to send mails to all members of an Organic Group. One user has his mail preferences set to plain text only. This user received the mail without the body and an error like the subject of this issue appeared in the log.

Before hitting this issue I already created this attached one line patch to solve the problem.

Same issue and #25 fixed it for me.

Serious issue, my users didn't get proper password recovery e-mail if they had selected text-only e-mails in their profile. #25 fixed it.

Note the D8 version of Mime Mail requires the same fix, but for a slightly different reason - see #2942376: Undefined offset: 0 in Drupal\mimemail\Utility\MimeMailFormatHelper::mimeMailHtmlBody()

If this issue is important to you, can you please review #2986204: Missing test dependencies so we can get that committed and get the tests working?

The above patch should be checked by the testbot for coding standards problems before being committed. Also, it wouldn't hurt to add a comment to that one-line patch to explain why it's being done so that no-one tries to simplify that piece of code in the future. Likewise, there really should be an added test case to accompany the patch so that we can ensure that future changes to the code don't break this again.

Why has this patch not been included in the 1.1 release?

Because 1.1 was a security release. It's a good practice (in my opinion) to ONLY include security related issues in a security release. When you're trying to patch lots of sites, you don't want to have to worry about additional functionality/changes that were bundled in with the security update.

We obviously all failed in setting this issue to the correct status either...

Unfortunately the security update brings back the problem.

Good news though, patch #25 still applies and still solves the problem.

So after updating to 7.x-1.1 (security update), you need to re-apply the patch.

Several users confirmed that the patch works correctly for D7. Setting this to RTBC now.

Thanks. #25 worked applied cleanly and addressed the issue as well. Please commit.

Yep #25 worked for me. Thanks.

I just upgraded my openatrium and came accross this when sending notices through openatrium to my group members.

+1 , this affects the latest openatrium release that relies on the mimemail module.

The patch works, can someone please jam this in and tag a release?

As I said in #28, this patch needs a comment and a test. Now that we have testing up and working for this module, I'd like to use it.

To reproduce this in openatrium:
Create a document with group notification enabled.
When you delete that document an email is sent saying that the document was deleted. The notice of delete email provokes the issue because the preg match is empty.

For the comment I suggest this: // Correctly validate empty preg match else put a sane default.

#25 worked for me. Thanks for posting fix.

In my case it was sending blank bodies for the mail.

This warning was also cluttering up my watchdog, #25 sorted it out.

It was getting hit as I'm constructing the e-mails programatically, but for e-mails that I'm blocking (['#send'] = false) I don't bother generating a HTML body, therefore the parameter is empty going into this function as this is called prior to it cancelling the e-mail send.

As I said in #28, this patch needs a comment and a test.

@TR if you'd like to have tests, feel free to write them

The patch fixing the problem has been confirmed by several users.

I really don't think documentation or tests should be a show stopper for a critical bug fix. A cleaner approach would be a follow-up issue.

Blocking this patch is very frustrating for people who need it.

Same problem when I use "plain text only".

#25 worked for me. Thanks!

We’ve run into this on a Drupal.org site, too.

I suspect this was introduced with #2594743: Theme function called for plain messages also. Messages formatted as plain text no longer get a <body> tag from mimemail-message.tpl.php

@drumm good catch! It's really that simple.

As reportet in 2594743 it "somehow felt wrong" to call the theme function, but actually that's correct and removing that theme call totally broke plain text mails.

The easiest solution for us is to revert those wrong changes. Patch is attached, please review.

Dear issue followers. One of you should take the time to review the patch #42.

If no one does, the next mimemail release will break plain text mails again.

I do confirm #42 takes care of the issue.

Also just struggled with this issue.
I think approach in #42 looks good.
mimemail_html_body() always treats the passed in body as HTML no matter if the $plain flag is set or not. And it uses the body only if no explicit plaintext was defined.
So we shouldn't run in any collisions.
That given, mimemail_prepare_message() shouldn't change the body based on the plain flag. This also holds true regarding the mail_post_process hooks invoked in mimemail_prepare_message() - these hooks don't know if the plain flag was set or not and shouldn't get changing parameters on an opaque flag.

As requested by TR in #35 I've added a simple test.
The test only patch should fail - the extended patch from #42 should return green.

Looks good to me. The added tests look like they should have good coverage, with and without $message['params']['plaintext']

RTBC +1

Test coverage is good. Very useful for issues like this.

I tested manually that this patch is working on a website that sends with Rules.
That website was previously on beta3. And with this patch I can update it to the newest -dev.

Rerolled patch from #45 as the update to mimemail.module wasn't applying.

Thanks @jerdavis, can you please also tag and push a release with this fix?

I'd defer to TR on tagging a new release. I'd need to review everything that's gone into 7.x since the last release and understand the implications of tagging a new release of a module in use by 80k "stable" sites. I do agree it should happen.

After updating the MIME Mail 7.x-1.0 to Mime Mail 7.x-1.1 getting an error
Notice: Undefined offset: 0 in mimemail_html_body() (line 383 in file /sites/all/modules/mimemail/mimemail.inc).

After updating the MIME Mail 7.x-1.0 to Mime Mail 7.x-1.1+8-dev (2019-08-20) getting an error
Notice: Undefined offset: 0 in mimemail_html_body() (line 389 in file /sites/all/modules/mimemail/mimemail.inc).

$plaintext = drupal_html_to_text($matches[0]);

Tried different versions of PHP 5.4, 5.5, 5.6, 7.2, 7.3

The letter comes spoiled.

This happens when the archive is sent to the mail by the Backup and Migrate module of the latest version.

We are still waiting for 7.x-1.2 to be tagged. Please read issues carefully, to get this fix prior to the next tagged release (hasn't happenned yet) you must use a dev release OR patch 1.1 . This fix is only in the dev branch, please
Use the 7.x-1.x-dev release.

This is why I asked 5 months ago for a tagged release , to spare others the trouble.

mimemail 7.x-1.x-dev did not help.

Is there no way we can get a hotfix for this? It is kind of a big deal that a supposedly stable version of a module used "80k stable sites" is broken...

Kevin, did 7.x-1.x latest dev help? D85 said "no",
Or did you try patching 1.1?

mimemail 7.x-1.x-dev works.
But on one of my sites, the problem persists. I assume that this is due to some specific server settings.

@DD 85,

This module will probably enlighten or solve your debugging on that broken site

Duplicate module fixer
https://www.drupal.org/project/dmf

Remove the incorrect duplicate mimemail module using duplicate module fixer

I ended up patching 1.1

It is a really easy fix. Would just be nice if it was built in.