Mime Mail module: HTML emails and Plain text emails

I'd love to see Mail editor provide two fieldsets. In the first one we would create and edit the HTML message. In the second part, we could edit the plaintext version.

The result should be a multipart mail message that would be handled automatically by the mail client.

i dont know how to do that stuff :(.

if anyone cares to contribute a patch i will gladly review and commit it. however i dont know how to do the whole multipart and headers thing necessary for proper html email template.

For a starter you can look at PHP.net.

http://ca3.php.net/manual/en/function.mail.php

Cheers.

Here is a blog post about this subject:

Multipart HTML Emails With Drupal
http://agileapproach.com/blog-entry/multipart-html-emails-with-drupal

Any progress here? I love the way Subscriptions does such neat plain text digests out of the box, it would be even more amazing if it could do it in HTML. I was wanting to use the Notifications framework for email replies (mail to web) and Subscriptions for digested updates. Perhaps this is a bad idea to start with :-)

If you want mail_edit to handle html emails, simply install the htmlmail module.
AFTER it has been installed, run the following SQL command:

UPDATE system SET weight=1 WHERE name='htmlmail';

If you installed Drupal with table prefix, be sure to adjust the table name accordingly.

Do not forget to clear the Drupal cache after that.

This will make sure that the htmlmail magic occurs AFTER the mail_edit has done it's replacing.
The problem here is that mail_edit completely disregard the body when you specify your own custom template. When htmlmail makes this email as HTML, it gets replaced by your template.

So, an alternative to what I propose is to put your full HTML inside each of your templates. I prefer the first option.

Any comments?

Interesting!

If you expect comments, you shouldn't mark the issue "won't fix", because that'll take it out of sight.

i've commited the patch to htmlmail module to fix this. There will be a new official release soon.

subscribing

Hi Chris Herberte,

Does this mean we can send HTML emails with Mail Editor at this moment if we install htmlmail module?

I use Mail Editor to set the email for many mail templates for many languages, and would really like to make them html emails.

Thanks

whoops, I'm not sure how the component changed with my last update.

Also, is there anything else that needs to be done to send Mail Editor mail templates as html emails?
Does all the code just go into the body section and that is it?

Thanks

Could anyone please help clarify what the below means from #6, and what to do to get this working =)

The problem here is that mail_edit completely disregard the body when you specify your own custom template. When htmlmail makes this email as HTML, it gets replaced by your template.

So, an alternative to what I propose is to put your full HTML inside each of your templates. I prefer the first option.

Using Mime Mail module it is possible to make all emails sent via Mail Editor to send as a html email. But it would be great to be able to specify the plain text version as well just in case the recipient does not allow html emails.

As a reference, Mime Mail module just added Rules Integration which allows HTML and Plain text versions to be specified. #501722: HTML mail actions for Rules

I hope this feature request can be considered which will greatly improve the usage of this module.

Thank you!

Who will investigate and work on this?

+1 subscribing

this looks to be the patch for rules http://drupal.org/files/issues/mimemail.501722_03.patch

I stumbled over this and decided to give it a shot.
The patch became bigger than I initially thought it would be, but it shouldn't be to hard to review.

One of the main issues was that rules uses an enhanced token replacement system.
To be able to use these rules specific tokens I had to introduce new hooks.
Doing so I tried to make the new hooks as generic as possible - this hopefully helps to avoid the need for even more hooks.

Another essential change is the newly added "data" field in the mail_edit table.
The idea of this field is to provide a generic storage for implementation specific data. This is handy for the mimemail integration as it allows us to store the plaintext version of the mail in a very simple and generic way.

Last but not least I've added a proper api documentation mail_edit.api.php. I hope this will help to understand the existing and new hooks.

Changelog:

• New hooks:
  • hook_mail_edit_format_preprocess(): Allows to preprocess all the data and settings before formatting.
  • hook_mail_edit_mail_alter_postprocess(): Allows to process the message after all processing by mail edit is done.
• New serialized field data in the table mail_edit.
  All form values in the template edit form, located in $form['data'], are automatically stored in the new field.
• The token tree uses the "new" dialog flag to ensure the edit form initially loads fast.
• Rules integration.
• Mime Mail integration - currently just integrated with the rules actions.

I just figured out that mimemail recently added the function to manually define the mail key in the rules action. This means I had to adjust the code to take that into account - the solution is ugly and I think we will see bug's because of the custom keys but for the moment I don't have a better approach.
Btw. the mimemail integration works with both the new and the old mail key handling.

I just came across a related issue in mimemail: #2020875: Mimemail l10n integration / Provide option to set language in rules actions
Multilingual stuff doesn't work as expected without the patch - at least I didn't expect that always the systems default language is used ;)

I've decided to implement hook_mail_edit_token_types() for the rules and the mimemail integration. Even if it's not directly usable, maybe even misleading to have the token of an entity with another token-prefix, I think it's still really valuable to be able to browse the full token tree. The replacement tokens listed by rules are limited even though the nested tokens should be fully supported.

Further I added static caching to _mimemail_mail_edit_get_element_by_mailkey() this will hopefully help to avoid unnecessary db queries.

Thank you for picking this up, and especially for mail_edit.api.php.

Weird -- the testbot shows green, but when I try to apply the patch, I get

mail_edit-mimemail-integration-and-more-212224-18.patch:194: new blank line at EOF.

and I haven't been able to fix it.

Without being able to tentatively apply this patch and running my visual diff I'm a bit lost...

However, it seems that this requires a considerable investment in Mime Mail-specific code, which I'm not willing to make. The Mime Mail maintainer's business model is a bait-and-switch operation of the worst kind.

What are considered whitespace errors is controlled by core.whitespace configuration. By default, trailing whitespaces (including lines that solely consist of whitespaces) and a space character that is immediately followed by a tab character inside the initial indent of the line are considered whitespace errors.
By default, the command outputs warning messages but applies the patch.

There were some extraneous blank lines in the new mail_edit.api.php.
I think the best way to see what triggers the whitespace errors in git (which also could be ignored) is to use git apply --whitespace=fix and then recreate the patch and diff it with the one that threw the error.
However, I've removed the extraneous blank lines in the attached patch. The errors should be gone.

However, it seems that this requires a considerable investment in Mime Mail-specific code, which I'm not willing to make. The Mime Mail maintainer's business model is a bait-and-switch operation of the worst kind.

May I ask you to elaborate this a little bit further? I think the Mime Mail module is a handy one, and the maintainers seem to care about the project, too. So what's the issue there?
Further the investment in code would be more Rules centric. As you'll see, the Mime Mail integration uses wherever it can the functions of the Rules integration or uses the same architecture where re-using a function isn't applicable.

May I ask you to elaborate this a little bit further? I think the Mime Mail module is a handy one, and the maintainers seem to care about the project, too. So what's the issue there?

The problem is not with the module but with its project owner, and it's based on past encounters with her in the Premium queue.

• The first one was four years ago and has apparently been removed in a nontransparent way; #284704: Requesting commit access was the result of the pressure, but it later turned out that jerdavis was an employee of the project owner, and he continued to follow the same plan of course.
• Another one here: #642392: full node access control, hide cck fields, multiple roles and msg per role
• And the last one before I turned away in disgust: #1119168: Premium has been forked.

The project owner let others do all (and I really mean ALL!) the work and she brazenly asked to get paid for committing ports and patches developed and posted by well-meaning but uninformed idiots. She does not lift a finger unless she gets paid for it, except to do stone-walling. I've never encountered anyone in the community who is further away from the Drupal Code of Conduct, by far, and I will not spend my rare spare time to support her evil scheme!

If I understand this right, you'll force me to fork your / create a new module because someone forced you to fork / create a new module? What made you, understandably, very angry and disappointed.
And as of this past experience you're projecting this bad feelings into all projects where Allie Micka is or was involved?
That sounds quite unhealthy!
So how about to join the presence again - and I think Mime Mail is a great example why that's better than the past would let us expect.
sgabe seems to be a very active and passionate maintainer, e.g. the patches I posted got attention and welcoming feedback. And his last commit was just about an hour ago.

Not only that, but imagine if I go to Mime Mail and say "Hey let's introduce Mail Edit support" and it's realized, all the credits for it would go to the Mime Mail module! ;)

If this is still a problem I'll happily invest some time and visit you in person in Bern to figure out together a viable way - because I think we can and should get this done.
Btw. did you know about CH DUG Sommer Treff tomorrow? How about talking about this and having a BBQ?

@salvis: I understand your pain and frustration. But even if you are right, you should give the example and choose your words. I would suggest that you tell that this “is hard to work with her”, or “very hard and counter productive”, but do not use harsh words! That does not encourage anyone to help or listen.

That sounds quite unhealthy!

On the contrary. Steering clear of and not generating income for that person is the healthy thing to do. (It was mikl who ended up forking Premium.)

Not only that, but imagine if I go to Mime Mail and say "Hey let's introduce Mail Edit support" and it's realized, all the credits for it would go to the Mime Mail module! ;)

That'd be perfectly fine with me. I'm all for putting credit where it belongs, everywhere and every time.

If I understand this right, you'll force me to fork your / create a new module

No, what I'm trying to say is that I cannot accept code to specifically support Mime Mail (code which I would then be forced to maintain into the future) because I will not join the, er, ranks of fine people who contribute their time and energy to increase that person's bottom line.

So, yes, I agree that we can and should get this done, but we'll have to somehow work around the given impediment.

(No, I hadn't heard of the CH DUG Sommer Treff, even though I'm subscribed to "Event posts in Switzerland"; somehow this didn't come through. Thank you for the invitation, but I can't fit it into my schedule.)

@xmacinfo: I've spent considerable effort to choose my words. I don't know which one(s) you found harsh. If it's the word "idiots", then that was meant to be an allusion to http://en.wikipedia.org/wiki/Useful_idiot, and in no way meant to offend or deride those who have fallen into that trap. I'm sorry if that was improper.

So here we go, the attached patch contains just the rules integration.
And I added the possibility to stay on the template edit page after saving the template. During testing it drove me crazy that I had to re-open the form over and over again.

...the word "idiots" ... was meant to be an allusion to http://en.wikipedia.org/wiki/Useful_idiot, and in no way meant to offend or deride those who have fallen into that trap.

I believe "naive" would be a better choice and far more subtle in that case, but I honestly feel your frustration about the specific user. Besides... hey, we all have a bad day or two once in every while ;)

Thank you for the update.
I'm on the road with less connectivity than expected.
I'l look at your patch as soon as I can.

@salvis Thanks for the status update, much appreciated!

After almost 3 years someone finally picked this up and done something. It would be really sad to see the door closing on this because whatever reason, when there would be no real problem to get this done.

Guys, take a look this issue #2076827: Add plaintext field

No, the door is not closing on this, but mrded is right: sending HTML only is not so great.

I've just tested this patch with #2076827: Add plaintext field and it seems like the plaintext handling works for rules too.
Unfortunately I found some issues with the rules integration while testing the plaintext handling.
Those issues are fixed in the attached patch.

32: mail_edit-mimemail-integration-and-more-212224-32.patch queued for re-testing.

Changed function to load rules. The previous function call missed reaction rules.
Btw. I've no clue why there's an error with the patch version.

Thank you for the updates.

Btw. I've no clue why there's an error with the patch version.

Did you "Ensure the patch only contains unix-style line endings."?

#16:

Another essential change is the newly added "data" field in the mail_edit table.
The idea of this field is to provide a generic storage for implementation specific data. This is handy for the mimemail integration as it allows us to store the plaintext version of the mail in a very simple and generic way.

Do you mean the plain-text template? Is this still needed after #2076827: Add plaintext field?

The token tree uses the "new" dialog flag to ensure the edit form initially loads fast.

No, this does not work well. The pop-up is too small — With the Subscriptions tokens it's just about unusable.

#18:

I've decided to implement hook_mail_edit_token_types() for the rules and the mimemail integration.

Does it still work with Subscriptions, which adds a load of tokens of its own?

#25: Are we still true to

So here we go, the attached patch contains just the rules integration.

? If yes, then please adjust the name of your patch files.

And I added the possibility to stay on the template edit page after saving the template. During testing it drove me crazy that I had to re-open the form over and over again.

I understand, but I don't think this should go into the production code.

Please keep in mind that not breaking Subscriptions has a high priority.

I have changed the patch to be able to apply it on top of current 7.x-1.x branch, what I did:

• Removed the #dialog change, it was added on #2456719: Change token tree to use the new dialog.
• Adjusted one hunk to follow the function signature change on commit daebf7ac6341c055792fb460b833627927d8b469.
• Changed the N in hook_update_N.

A work-around to avoid the patch if this is only for one mail that need HTML and it is not created from rules:

• Go to mailsystem module configuration, admin/config/system/mailsystem.
• Add a new setting for the module and mailkey of the mail, and save settings.
• A new select box will be available to change the MailSystemInterface class, set the one you would like to use, e.g. MimeMailSystem.

Moving to NR only for tests, some points from comment #38 are still pending.