I've set up a rule that sends you an HTML email when you activate your account. It seems to throw back a notification about:

Notice: Undefined variable: attachment in SmtpMailSystem->mail()

But it seems to send the email anyway, but what I don't understand is that I receive 2 emails everytime I test it. I've checked the log files and it seems to log that an anonymous user has used the validate URL to confirm their email address, then sends the email. Then it opens up a session for this new user, and then sends them the email again.

I've set the rule to run on 'When the user account is activated' and if I turn the rule off I get no emails, so it isn't that there is anything else sending an email too, it is only this rule, it just seems to do it twice.

Can anyone offer a solution?

I'm using the SMTP, Mimemail and Mail System modules

If anyone needs me to post any specifics about the rule, or the error or the email text etc, just ask, I just didn't want to flood the post with huge blocks of code if it might not have helped.


Log file output (obviously I have flipped the order for it to make sense, log files are recent most recent first)

  • New user: unset_username ([email protected]). // When I create a new account
  • Sending mail to: "Firstname Lastname" // Emails out the verification request
  • E-mail validation URL used for Firstname Lastname with timestamp ...
  • Sending mail to: "Firstname Lastname" // Emails out the confirmation email once
  • Session opened for Firstname Lastname.
  • Sending mail to: "Firstname Lastname" // Emails out the confirmation email again


Determined the issue is nothing to do with the emails, tried re-creating the rule but sending an output to the page rather than sending HTML email, it was confirmed that this rule runs twice (and hence nothing to do with emails in particular) by the fact that the message was output twice as well.


As Molot has pointed out this isn't anything to do with emails, just the rule happening twice. I'll leave the text above incase anyone else is trying to send out emails on verification and they come to the same conclusion I did, so they can find this and understand whats happening.

  • Sounds like a bugreport... good old log write outputs twice too?
    – Mołot
    Commented Aug 27, 2013 at 11:36
  • Yes, the log files say nothing is 'wrong', i'll make an edit to the question to show what the log files say since I can't do a list in a comment Commented Aug 27, 2013 at 11:41
  • I meant - if instead of sending mail you would write to a log, would it get doubled too?
    – Mołot
    Commented Aug 27, 2013 at 11:42
  • Is there a specific action for writing to log? I wasn't able to use it. But instead I tried writing a message to the page, and that wrote out twice, it wrote it before and after the 'your email has been confirmed' piece of text Commented Aug 27, 2013 at 11:56
  • I don't remember now, I recall I did it but, well, does not matter - we know not only mail is sent twice, but everything is done twice. Next step - if you will disable mail sending, leaving only message, will it appear twice? If so, we can eliminate mail from your question. If not, we will know for sure that sending email is the very step that forces rule to repeat.
    – Mołot
    Commented Aug 27, 2013 at 11:58

1 Answer 1


Understanding what's happening

Your question seems like a variation (IMO not a duplicate) of the question 'Why is my rule that reacts on event "After updating an existing user account" firing twice?'. The accepted answer in that question might help to understand your issue (what's causing it) also, ie:

some other module code is calling a user_save on hook_user_update triggering the rules event a second time.

If I was to debug this, I'd disable all contributed modules (except "Rules" and "Entity API") to check if it's indeed a contributed module (I don't expect it to be core). And then re-enable the contributed modules one by one until the issue comes back. As soon as it comes back, you pinpointed the contributed module causing the issue, and you can start working on a possible remedy for that.

Workaround 1

That question also has another answer with a very interesting workaround, with an image which looks like so (a picture is worth more then 1000 words):

enter image description here

Workaround 2

Another workaround to prevent this issue from happening, is to improve your existing rule to make it similar to the rule included in my answer to "How to implement a Rules Condition like [account:last-login] = never?". More specifically:

  • Add a Rules Condition like: User does NOT (!!!) have a role with role id = "4".
  • Add a Rules Action like: Grant User the role with role id = "4".

So this improvement of your rule will check if the user does not yet have some (designated) role with role id = "4" (adapt to whatever role id that fits your case, and make sure this role is NOT yet granted when activating a new user id). If that's the case, then the user is granted that role. With this improvement to your existing rule, this is what will happen:

  • The 1st time your Rules Actions will still be performed (and grants the designated role).
  • the 2nd time not ALL of your Rules Conditions will be satisfied (since the designated role was granted before), and therefor your Rules Actions will no longer be performed.

In other words: "this will prevent your Rules Actions to happen twice" (as in your question).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.