How to override and customize Devise Mailers with Rails

Written by rmtwrk | Published 2019/01/21
Tech Story Tags: ruby-on-rails | devise | mailgun

TLDRvia the TL;DR App

At RMTWRK we are building the world’s largest remote only jobs board to help match companies hiring remote or distributed teams with people who are looking for a more flexible work environment. As a result our rails app has two user types, Company Users, people doing the hiring and Individual Users, people wanting to be hired and we wanted to have separate confirmation emails for each user type. Additionally we wanted to use Mailgun’s API for sending emails rather than through SMTP (more on this later), and lastly we wanted to use the amazing Premailer gem to inline the CSS styles in our emails before sending.

Devise is one of the long standing and best written ruby/rails libraries around and one of the easiest to customize, workaround, and override. It does so much though that it can sometimes be hard to know where to start.

We are going to go over the 3 methods (or degrees, if you will) of customizing Devise’s emails.

Method 1: Simple customization of Devise’s default emailsMethod 2: Customizing the “layout” and “templates” used by Devise for sending emailsMethod 3: Overriding how Devise sends emails to use an API (Mailgun) instead of SMTP

I’ll briefly touch on and link to other resources for the first 2 methods

Method 1: Simple customization of Devise’s default emails

If you only want to modify a few simple things about the layout of something like the email confirmation email or password reset email then this is the method for you. First run the following in your terminal and then you can edit the views for the emails you are interested in inside of views/devise/mailer

rails generate devise:views

For further details, the best place to look would be the Devise Readme on GitHub.

Method 2: Customizing the “layout” and “templates” used by Devise for sending emails

If you want to go a bit further and customize the layout that each email template is rendered into then you can do so by creating your own Mailer class that subclasses **Devise::Mailer**. Devise also has a great Readme on how to do this here: How To: Create custom layouts.

There are a couple of potential gotchas to be aware of with this method. If you have two resource types, like say User and Individual (the names of our actual models), the simplest way to have two separate mailers is to use the method **devise_mailer** in each resource.rb model file (simplified example below). If you plan to move the location of the mailer templates, be sure to delete the existing templates in “devise/mailer” as they will override your other views.

This is an example of a simple customized Devise Mailer:

class RmtwrkDeviseMailer < Devise::Mailerhelper :application # helpers defined within `application_helper` include Devise::Controllers::UrlHelpers _# eg. `confirmation_url`_ default template_path: 'rmtwrk/devise/mailer default from: 'RMTWRK rmtwrk@wrkhq.com'default reply_to: 'RMTWRK rmtwrk@wrkhq.com'layout 'mailer_rmtwrk'end

And you can tell your Individual model to use this mailer using the devise_mailer method like this:

class Individual < ApplicationRecorddevise :database_autenticatable,..., :confirmable

def devise_mailerRmtwrkDeviseMailerendend

But what if you wanted to do some other things to the email before sending it? That’s where method 3 comes in.

Method 3: Overriding how Devise sends emails to use an API instead of SMTP

Our constraints:

  1. Sending email vis an API rather than SMTP. Most email providers recommend using their API rather than SMTP for a variety of reasons. Here are Sendrid’s and Mailgun’s reasons as examples.
  2. Two resource models; User and Individual, using Devise.
  3. Separate branding, i.e. layout files per model.
  4. Inlining our CSS using Premailer.

In order to accomplish this the essential piece of the puzzle is overriding the Devise::Mailer method(s) you are interested in. For this example we will only focus on the email confirmation email. This is handled by the confirmation_instructions method by default, which uses ActionMailer and SMTP by default.

Here is what our final custom Devise Mailer will look like:

I hope that this has been helpful! Please leave comments or questions and I’d be happy to respond, but let’s be honest the most likely person to stumble on this in 10 months or so looking for an example of how to do this is probably me, hi future me!

Best — Andrew Gertig


Published by HackerNoon on 2019/01/21