发布于 2015-08-27 16:46:19 | 178 次阅读 | 评论: 0 | 来源: 网络整理
When developing an application which sends email, you will often not want to actually send the email to the specified recipient during development. If you are using the SwiftmailerBundle with Symfony, you can easily achieve this through configuration settings without having to make any changes to your application’s code at all. There are two main choices when it comes to handling email during development: (a) disabling the sending of email altogether or (b) sending all email to a specific address (with optional exceptions).
You can disable sending email by setting the disable_delivery option
to true. This is the default in the test environment in the Standard
distribution. If you do this in the test specific config then email
will not be sent when you run tests, but will continue to be sent in the
prod and dev environments:
# app/config/config_test.yml
swiftmailer:
disable_delivery: true
<!-- app/config/config_test.xml -->
<!--
xmlns:swiftmailer="http://symfony.com/schema/dic/swiftmailer"
http://symfony.com/schema/dic/swiftmailer http://symfony.com/schema/dic/swiftmailer/swiftmailer-1.0.xsd
-->
<swiftmailer:config
disable-delivery="true" />
// app/config/config_test.php
$container->loadFromExtension('swiftmailer', array(
'disable_delivery' => "true",
));
If you’d also like to disable deliver in the dev environment, simply
add this same configuration to the config_dev.yml file.
You can also choose to have all email sent to a specific address, instead
of the address actually specified when sending the message. This can be done
via the delivery_address option:
# app/config/config_dev.yml
swiftmailer:
delivery_address: dev@example.com
<!-- app/config/config_dev.xml -->
<!--
xmlns:swiftmailer="http://symfony.com/schema/dic/swiftmailer"
http://symfony.com/schema/dic/swiftmailer http://symfony.com/schema/dic/swiftmailer/swiftmailer-1.0.xsd
-->
<swiftmailer:config delivery-address="dev@example.com" />
// app/config/config_dev.php
$container->loadFromExtension('swiftmailer', array(
'delivery_address' => "dev@example.com",
));
Now, suppose you’re sending an email to recipient@example.com.
public function indexAction($name)
{
$message = Swift_Message::newInstance()
->setSubject('Hello Email')
->setFrom('send@example.com')
->setTo('recipient@example.com')
->setBody(
$this->renderView(
'HelloBundle:Hello:email.txt.twig',
array('name' => $name)
)
)
;
$this->get('mailer')->send($message);
return $this->render(...);
}
In the dev environment, the email will instead be sent to dev@example.com.
Swift Mailer will add an extra header to the email, X-Swift-To, containing
the replaced address, so you can still see who it would have been sent to.
注解
In addition to the to addresses, this will also stop the email being
sent to any CC and BCC addresses set for it. Swift Mailer will add
additional headers to the email with the overridden addresses in them.
These are X-Swift-Cc and X-Swift-Bcc for the CC and BCC
addresses respectively.
Suppose you want to have all email redirected to a specific address,
(like in the above scenario to dev@example.com). But then you may want
email sent to some specific email addresses to go through after all, and
not be redirected (even if it is in the dev environment). This can be done
by adding the delivery_whitelist option:
# app/config/config_dev.yml
swiftmailer:
delivery_address: dev@example.com
delivery_whitelist:
# all email addresses matching this regex will *not* be
# redirected to dev@example.com
- "/@specialdomain.com$/"
# all emails sent to admin@mydomain.com won't
# be redirected to dev@example.com too
- "/^admin@mydomain.com$/"
<!-- app/config/config_dev.xml -->
<?xml version="1.0" charset="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:swiftmailer="http://symfony.com/schema/dic/swiftmailer">
<swiftmailer:config delivery-address="dev@example.com">
<!-- all email addresses matching this regex will *not* be redirected to dev@example.com -->
<swiftmailer:delivery-whitelist-pattern>/@specialdomain.com$/</swiftmailer:delivery-whitelist-pattern>
<!-- all emails sent to admin@mydomain.com won't be redirected to dev@example.com too -->
<swiftmailer:delivery-whitelist-pattern>/^admin@mydomain.com$/</swiftmailer:delivery-whitelist-pattern>
</swiftmailer:config>
// app/config/config_dev.php
$container->loadFromExtension('swiftmailer', array(
'delivery_address' => "dev@example.com",
'delivery_whitelist' => array(
// all email addresses matching this regex will *not* be
// redirected to dev@example.com
'/@specialdomain.com$/',
// all emails sent to admin@mydomain.com won't be
// redirected to dev@example.com too
'/^admin@mydomain.com$/',
),
));
In the above example all email messages will be redirected to dev@example.com,
except messages sent to the admin@mydomain.com address or to any email
address belonging to the domain specialdomain.com, which will be delivered as normal.
You can view any email sent during a single response when you are in the
dev environment using the Web Debug Toolbar. The email icon in the toolbar
will show how many emails were sent. If you click it, a report will open
showing the details of the sent emails.
If you’re sending an email and then immediately redirecting to another page, the web debug toolbar will not display an email icon or a report on the next page.
Instead, you can set the intercept_redirects option to true in the
config_dev.yml file, which will cause the redirect to stop and allow
you to open the report with details of the sent emails.
# app/config/config_dev.yml
web_profiler:
intercept_redirects: true
<!-- app/config/config_dev.xml -->
<!--
xmlns:webprofiler="http://symfony.com/schema/dic/webprofiler"
xsi:schemaLocation="http://symfony.com/schema/dic/webprofiler
http://symfony.com/schema/dic/webprofiler/webprofiler-1.0.xsd">
-->
<webprofiler:config
intercept-redirects="true"
/>
// app/config/config_dev.php
$container->loadFromExtension('web_profiler', array(
'intercept_redirects' => 'true',
));
小技巧
Alternatively, you can open the profiler after the redirect and search
by the submit URL used on the previous request (e.g. /contact/handle).
The profiler’s search feature allows you to load the profiler information
for any past requests.