search

billhorsman / inline_styles_mailer

Inline Styles Mailer Gem
MIT License
14 stars 11 forks source link

Parts order is ignored with inline_styles_mailer gem #3

Closed zinkkrysty closed 12 years ago

zinkkrysty commented 12 years ago

I want to specify an explicit parts order for my email, because Gmail seems to take the plain/text version even if both are present.

It can be done, according to the Rails API by adding a 

default :parts_order => [ "text/plain", "text/enriched", "text/html" ]

to either the Mailer class or as a setting in the mailer initializer file.

Neither work with your gem. When I disable the gem, it works.

billhorsman commented 12 years ago

That makes sense. I'll make a change to support that behaviour.

billhorsman commented 12 years ago

This seems simple enough, until you start digging into how rails interprets template names and mime types. Like a file called

foo.html.erb

uses a mime type of text/html. If you ask the template what formats it uses it just responds "html", not the mime type.

foo.text.erb

uses text/plain and just reports "text". I'm thinking the best route might be to just hard code the order that GMail likes....

nateberkopec commented 12 years ago

Got bit by this when working with Roadie. Same behavior - the mime part order gets switched from text => html to html => text, which cause Gmail (and Apple Mail as well I think) to display only plaintext.

nateberkopec commented 12 years ago

OK, so after some digging, I found the relevant RFC. From RFC 1341:

In general, user agents that compose multipart/alternative entities should place the body parts in increasing order of preference, that is, with the preferred format last. For fancy text, the sending user agent should put the plainest format first and the richest format last. Receiving user agents should pick and display the last format they are capable of displaying.

So Gmail is actually following the spec as written, and this is ActionMailer's default order. Which suggests, to me, that hard-coding it would be fine.

billhorsman commented 12 years ago

Nate, thanks for looking into that. I think your suggestion makes a lot of sense. Feel free to send me a pull-request or I'll get it done myself as soon as I can.

billhorsman commented 12 years ago

Dang. Messed up that pull request. See issue #6.

billhorsman commented 12 years ago

Fixed in issue #6. Sorry for the confusion.