Cached Mailer

Cached Mailer simply stores a copy of all the email you send with ActionMailer to the database. The template used is also stored so you can run queries on the database for specific emails.

Note: This gem was almost completely taken from ar_mailer. ARMailer basically does the same thing, but instead actually sends the emails at a later date. This doesn’t work on Heroku or other environments where you can’t run background executables, so cached_mailer simply stores the emails for record keeping purposes while also sending them the same way it always did.

Installing Cached Mailer

First, if you haven’t already:

$ sudo gem install gemcutter
$ sudo gem tumble

Then

$ sudo gem install cached_mailer

For Rails >= 2.1, in your environment.rb:

config.gem "cached_mailer", :lib => 'action_mailer/cached_mailer', :source => 'http://gemcutter.com'

For Rails 2.0, in an initializer file:

require 'action_mailer/cached_mailer'

Usage

Go to your Rails project:

$ cd your_rails_project

Create the migration and model:

This shows the options which are only the model name, which defaults to Email

./script/generate cached_mailer -h

Then run with defaults

./script/generate cached_mailer

Or specify a custom model name

./script/generate cached_mailer Newsletter

Rake your database and you’re done! All the emails you send with ActionMailer will automagically be cached to the database for later reference.

Settings

Storing Email Contents

By default cached_mailer does not store the encoded body of the email in the database. Emails can be long, and this is to make sure your database doesn’t grow wildly out of control. If you really want to store the entire content of the emails, you can do so by adding this to an initializer:

ActionMailer::Base.cache_content = true

Alternate Mail Storage

By default cached_mailer assumes you are using an ActiveRecord model called Email to store the emails created before sending. If you want to change this you alter it in an intializer like so:

ActionMailer::Base.email_class = Newsletter

Note on Patches/Pull Requests

  • Fork the project.

  • Make your feature addition or bug fix.

  • Add tests for it. This is important so I don’t break it in a future version unintentionally.

  • Commit, do not mess with rakefile, version, or history. (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)

  • Send me a pull request. Bonus points for topic branches.

Copyright © 2009 Scenario4. See LICENSE for details.