ActionMailer Mailer Views and Content Type

Hi Vidal,

is this still a problem on master (past v2.3.2.1 tag)?

I'll just chime in and mention that I've been fighting some issues with implicit multipart email, layouts, and content type. I'm seeing the *.text.html.erb layout being used for the "text/plain" part. Issue seems to be around ActionView::PathSet#find_template returning the wrong template when called for format :text.

Strangely, the problem only occurs in a staging environment -- everything works as expected in my dev environment.

I'm using v2.3.2.1 tag.

If I can get a repro, I'll update here and/or file a new ticket.

• Blake

I'm also seeing this problem... and also strangely only in our production environment.

Even weirder is this: In our production environemnt, the mailer is creating proper multipart emails when I trigger them using a rake task, but when they are fired off by our background workling process... I get the text/plain problem.

Still trying to diagnose.

Update: I can get my emails to use the text/html content-type, by ensuring that my emailing process runs with the current directory set to RAILS_ROOT.

Now... however, I'm seeing the same problem as Blake. My emails are coming through with 2 parts: my HTML layout as text/html, and my HTML layout as text/plain.

(...despite having a .text.plain.erb layout in /layouts)

OK... I tracked this down for me at least. Unfortunately, I don't have time to check out rails, run the tests, and submit a proper patch.

To get this working for me... I modified ActionMailer::Base#default_template_format as follows:

def default_template_format
   if @current_template_content_type
      @current_template_content_type.sub('/','.')          
      # Mime::Type.lookup(@current_template_content_type).to_sym
   else
      :html
   end
end

As best I can tell, the problem is that the Mime::Type.lookup returns :text for "text/plain". Unfortunately, the template loading code maps paths such as:

layouts/my_mailer.text.html.erb
layouts/my_mailer.text.html
layouts/my_mailer.text
layouts/my_mailer.html

for template.paths like: layouts/my_mailer.text.html.erb

So, the my_mailer.text mapping is created for :html as well as :text. When the Mime::Type method is used, the :text symbol is not sufficient to distinguish the text.plain template from text.html.

I'm not sure what the purpose of Mime::Type.lookup is... but my fix seems to work for me anyway.

Looks like this is because ActionMailer::Base uses #template_path to build the list of templates to render. This interpolates an ActionView::Template::Path, which calls #to_s, which turns the path relative (instead of absolute) if RAILS_ROOT is defined. If you're like us and have mailer jobs run from cron, this relative path probably doesn't mean much to Dir.glob, and ActionMailer can't find its templates.

The attached patch changes template_path to use Path#to_str instead of #to_s, which fixed our problem by making template_path return an absolute path.

Justin, I posted a similar patch in #2263 more than a month ago. Good luck :).

I am so glad I found this! I thought I was losing my mind! I am having the exact same problem, but ONLY when the emails are generated from Workling on my production server. The HTML template is used to populate a single-part plain text email.

Justin, thanks for the patch. It solved my problem where emails didn't work right when sent from Workling.

The question now is whether this will make it into Rails 2.3.3.

Justin's patch does solves the problem. But shouldn't be .to_s return the same result as to_str? Sounds like a source for future bugs to me.

Experiencing the same bug in 2.3.2, but it only happens sometimes, a situation making me mad since I send over 200.000 emailings a week and I sometimes have to restart the rails application to make the template detection work !!

I've had this problem for quite some time now. Thanks everyone for putting in the work to figure it all out. I hope it gets stomped out for 2.3.5. Seems like such a huge bug, I'm not sure how there couldn't have been tests for it :)

Just thought I'd add, I tried the patch above and HTML emails still get sent as plaintext.

FYI, I upgraded to 2.3.5 and these problem persist. Please fix in 2.3.6 as this has been open a long time. Thanks.

I agree, this bug has been around for a long time. And I would think it'd affect a whole lot of people? I've been holding off deploying until a fix arrives but have given up. Just in case anyone wants to get their setup going again, it's actually pretty easy to just explicitly declare the different templates like so:

content_type    "multipart/alternative"

part "text/plain" do |p|
  p.body = render_message("invoice.text.plain", :order => order)
end

part :content_type => "text/html",
  :body => render_message("invoice.text.html", :order => order)

So instead of having your body hash as an option, you just pass that hash into each of the render_message functions. Make sure you put the HTML one last if you want to show that one by default in an email client.

By the way, I appreciate all the hard work the team members are putting to Rails 3 and know that that is their number one priority :)

Guys, we have two patches, but we cannot ensure that the problem won't come back again, because they don't have tests. If someone attach a patch with tests, I will apply it and try to solve the problem ASAP.

I'm on 2.3.8 and still experiencing this. Why hasn't this been patched yet in trunk? Super annoying.

I've been able to reproduce this bug on 2.3.10, using delayed_job to deliver a multipart email.

1. start delayed_job from Rails.root
2. schedule an email delivery via delayed job. wait for delayed_job to process and verify that the email is delivered as multipart/alternative
3. move/rename your Rails.root directory
4. schedule an email delivery via delayed job. wait for delayed_job to process. When testing in development I receive a template missing error, when testing in production the email is delivered as text/plain, using the html template as the body.

I'm guessing that the email is still delivered in production because the multipart templates are cached. However, the code that determines the mimetype looks for files on disk, doesn't find anything, and defaults to text/plain. I don't know enough about ActionMailer internals to know if this is a correct assessment. Should create! check the cache when searching for templates to add to @parts?

I forgot to mention that we use Capistrano for deployment on production. I believe when Capistrano recreates symlinks to point to the current release that it is causing a situation similar to my above steps.