smailer 0.4.2 → 0.4.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- data/README.md +18 -11
- data/lib/smailer/models/queued_mail.rb +2 -0
- data/lib/smailer/version.rb +1 -1
- metadata +4 -4
data/README.md
CHANGED
@@ -8,17 +8,19 @@ It is intended to be used within a Rails project. It has been tested with Rails
|
|
8
8
|
|
9
9
|
## Install
|
10
10
|
|
11
|
-
### Install the
|
11
|
+
### Install the gem
|
12
12
|
|
13
|
-
For Rails 3 projects,
|
13
|
+
For Rails 3 projects, add the following to your `Gemfile`:
|
14
14
|
|
15
15
|
gem 'smailer'
|
16
16
|
|
17
|
-
Then run `bundle install`. For Rails 2.x projects which do not use Bundler, add `config.gem 'smailer'` to your `environment.rb` file and then run `rake gems:install` in your project's root.
|
17
|
+
Then run `bundle install`. For Rails 2.x projects which do not use Bundler, add `config.gem 'smailer'` to your `environment.rb` file and then run `rake gems:install` in your project's root. Also, if you use Rails 2.3.5, you may need to explicitly require a newer version of the `mail` gem, because `mail 2.2.x` has a dependency on ActiveSupport 2.3.6. For example, you can add this to your Rails 2.3.5's `environment.rb`:
|
18
|
+
|
19
|
+
config.gem 'mail', :version => '~> 2.3' # we need 2.3.x which does not depend on ActiveSupport 2.3.6
|
18
20
|
|
19
21
|
### Generate and run the migration
|
20
22
|
|
21
|
-
To create the tables needed by Smailer to operate, run the `smailer:migration` generator after installing the
|
23
|
+
To create the tables needed by Smailer to operate, run the `smailer:migration` generator after installing the gem. For Rails 3, you can do this:
|
22
24
|
|
23
25
|
rails g smailer:migration && bundle exec rake db:migrate
|
24
26
|
|
@@ -41,11 +43,11 @@ Sending out newsletters consists of a couple of steps:
|
|
41
43
|
* At least one record should exist in `Smailer::Models::MailingList`. This record can then be used for unsubscribe requests if your system supports multiple newsletter types.
|
42
44
|
* For each newsletter issue you intend to send, you should create a `Smailer::Models::MailCampaign` record. This record contains the subject and body contents of the newsletter you will be sending out.
|
43
45
|
* Given a list of active subscribers your application provides, you then enqueue mails to be send via the `MailCampaign#queued_mails` list (see the example below).
|
44
|
-
* Finally, you should call `Smailer::Tasks::Send.execute` repeatedly to process and send-out the enqueued emails.
|
46
|
+
* Finally, you should call `Smailer::Tasks::Send.execute` repeatedly to process and send-out the enqueued emails, probably via a Cron daemon.
|
45
47
|
|
46
48
|
### Issuing a newsletter
|
47
49
|
|
48
|
-
|
50
|
+
Here is an example how you could proceed with creating and issuing a newsletter:
|
49
51
|
|
50
52
|
# locate the mailing list we'll be sending to
|
51
53
|
list = Smailer::Models::MailingList.first
|
@@ -75,7 +77,7 @@ This is an example how you could proceed with creating and issuing a newsletter:
|
|
75
77
|
|
76
78
|
### Managing unsubscriptions
|
77
79
|
|
78
|
-
|
80
|
+
Among the few unsubscription methods supported, probably the most widely used one is unsubscription via a unsubscribe link in the email.
|
79
81
|
|
80
82
|
In order to help you with implementing it, Smailer provides you with some interpolations you can use in the email's body:
|
81
83
|
|
@@ -89,9 +91,9 @@ In order to help you with implementing it, Smailer provides you with some interp
|
|
89
91
|
Here is an example text you could include in the HTML version of your email to show a unsubscribe link (this also demonstrates how interpolation in the email's body works):
|
90
92
|
|
91
93
|
<p>If you wish to be removed from our mailinglist go here: <a href="http://yourcomain.com/unsubscribe/%{email_key}">http://yourcomain.com/unsubscribe/%{email_key}</a>.</p>
|
92
|
-
<p>You are subscribed to the list with the email address: %{escaped_email}</p>
|
94
|
+
<p>You are subscribed to the list with the following email address: %{escaped_email}</p>
|
93
95
|
|
94
|
-
|
96
|
+
In this case, you will have to add a route in your Rails app to handle URLs like `'/unsubscribe/:email_key'`. For example, it could lead to `UnsubscribeController#unsubscribe`, which you could implement like so:
|
95
97
|
|
96
98
|
@email = Smailer::Models::MailKey.find_by_key(params[:email_key]).try(:email)
|
97
99
|
raise ActiveRecord::RecordNotFound unless @email
|
@@ -101,13 +103,13 @@ You have to implement a route in your Rails app to handle '/unsubscribe/:email_k
|
|
101
103
|
|
102
104
|
### Sending mails
|
103
105
|
|
104
|
-
The emails which have been placed in the queue
|
106
|
+
The emails which have already been placed in the send queue, have to be sent out at some point. This can be done for example with a Rake task which is run periodically via a Cron daemon. Here's an example Rake task you could use:
|
105
107
|
|
106
108
|
# lib/tasks/smailer.rake
|
107
109
|
namespace :smailer do
|
108
110
|
desc 'Send out a batch of queued emails.'
|
109
111
|
task :send_batch => :environment do
|
110
|
-
result = Smailer::Tasks::Send.execute
|
112
|
+
result = Smailer::Tasks::Send.execute :return_path_domain => 'bounces.mydomain.com', :verp => true
|
111
113
|
result.each do |queue_item, status|
|
112
114
|
puts "Sending #{queue_item.to}: #{status}"
|
113
115
|
end
|
@@ -116,8 +118,13 @@ The emails which have been placed in the queue previously, have to be sent out a
|
|
116
118
|
|
117
119
|
This task can be executed via `RAILS_ENV=production bundle exec rake smailer:send_batch` (provided you are running it on your production servers).
|
118
120
|
|
121
|
+
Notice that we pass a `:return_path_domain` option to `Send.execute`. This domain will be used to construct a dynamic `Return-Path:` address, which you could later use in order to process bounced mails and connect the bounce with a concrete mail campaign and sender's email address. The generated return path will have the following format: `"bounces-SOMEKEY@bounces.mydomain.com"`, where `SOMEKEY` will be the same as the `key` field in the corresponding `FinishedMail` record and will uniquely identify this record, and `bounces.mydomain.com` is what you passed to `:return_path_domain`.
|
122
|
+
|
123
|
+
Dynamic return path is generated only when `:return_path_domain` is specified and `:verp` is not false. If you omit the `:verp` option and just pass `:return_path_domain`, `Send.execute` will still use VERP and generate dynamic return path addresses.
|
124
|
+
|
119
125
|
## TODO
|
120
126
|
|
127
|
+
* Bounce processing
|
121
128
|
* Tests, tests, tests
|
122
129
|
|
123
130
|
## Contribution
|
data/lib/smailer/version.rb
CHANGED
metadata
CHANGED
@@ -1,13 +1,13 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: smailer
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
hash:
|
4
|
+
hash: 9
|
5
5
|
prerelease:
|
6
6
|
segments:
|
7
7
|
- 0
|
8
8
|
- 4
|
9
|
-
-
|
10
|
-
version: 0.4.
|
9
|
+
- 3
|
10
|
+
version: 0.4.3
|
11
11
|
platform: ruby
|
12
12
|
authors:
|
13
13
|
- Dimitar Dimitrov
|
@@ -15,7 +15,7 @@ autorequire:
|
|
15
15
|
bindir: bin
|
16
16
|
cert_chain: []
|
17
17
|
|
18
|
-
date: 2011-
|
18
|
+
date: 2011-10-06 00:00:00 +03:00
|
19
19
|
default_executable:
|
20
20
|
dependencies:
|
21
21
|
- !ruby/object:Gem::Dependency
|