NEW Move to SwiftMailer powered Emails #6466

dhensby · 2017-01-09T13:57:58Z

This PR rewrites our Mailer and Email classes to be powered by SwiftMailer.

Email now acts as a proxy for Swift_Message and adds our framework's rendering over the top.

Mailer converts an Email object into a Swift_Message and sends it using Swift_Mailer using the Swift_MailTransport by default (php's mail function) just to keep things the same as they are now.

todo:

Docs

kinglozzer · 2017-01-09T14:36:54Z

src/Control/Email/Email.php

        }

+        $message->render();


Do devs have to call this manually now? Shouldn’t this just be called by send()?

render is the replacement of populateTemplate which had to be called to "render" the email in v3.

So yes, devs do have to call this themselves if they don't use the callback method for creating emails, but this is not a change in behaviour IMO.

The problem with send calling render is what if a dev has manually set the body of the email? it'll be overridden and it'd be impossible to send a manually constructed email.

How about if we just check if the body is empty in render()? It looks like the old implementation would’ve overridden the message body: https://github.com/dhensby/silverstripe-framework/blob/4b7d31377bf8e4e5415da8dd9b5f172967a407a9/src/Control/Email/Email.php#L620-L624 and https://github.com/dhensby/silverstripe-framework/blob/4b7d31377bf8e4e5415da8dd9b5f172967a407a9/src/Control/Email/Email.php#L494-L526

Interesting - we could check if the body is populated or not, though I do like the certainty of basically saying "you have to render your email" over the ambiguity of it...

kinglozzer · 2017-01-09T14:37:04Z

src/Control/Email/Email.php

+        $swiftMessage->setDate(DBDatetime::now()->Format('U'));
+        if ($defaultFrom = $this->config()->admin_email) {
+            $swiftMessage->setFrom($defaultFrom);
+        }


Won’t this mean that if you use this method, you’re forced to use admin_email (if set)? i.e. if I set a default from address, how can I override it on a per-email basis? I think this needs to check if a from address has already been set

That's a good point. I'll update this

kinglozzer · 2017-01-09T14:45:49Z

src/Control/Email/Mailer.php

 use SilverStripe\Core\Object;
+use Swift_Mailer;
+use Swift_MailTransport;


There’s a lot of Swift-specific code in this class, which shouldn’t really be inherited by modules that provide other mailers. Would it be better to make Mailer an interface?

interface Mailer { public function send($message); } class SwiftMailer implements Mailer { public function send($message) { $swiftMessage = $message->getSwiftMessage(); return $this->sendSwift($swiftMessage); } // ... other methods } // Email.php Injector::inst()->get('SilverStripe\Email\Mailer')->send($this);

So I've taken a bit of a look at how Laravel does it and it's quite closely coupled - mostly because devs can write their own transports (which is basically the bulk of what they'd probably need to do).

There are a lot of out of the box transports, too, which would likely cover most of what people need.

I second @kinglozzer's suggestion, however I don't think it's critical to fully-decouple from swiftmailer for the sake of the initial implementation. It's not a merge blocker. :)

kinglozzer · 2017-01-09T14:57:34Z

So I’ve just had a look at SwiftMailer in a bit more detail (I’d never used it before), and I’m guessing the idea here is that you’d write or use a transporter for Swift rather than your own Mailer implementation? How easy is that to do?

Edit: doesn’t look hard, most of the big names already exist:

dhensby · 2017-01-09T17:49:23Z

I’m guessing the idea here is that you’d write or use a transporter for Swift rather than your own Mailer implementation?

Yep - pretty much - SwiftMailer is pretty popular and there are transports for all the major mail services.

dhensby · 2017-01-09T18:09:33Z

I've addressed the 2 issues and pushed up

tractorcow · 2017-01-10T23:24:07Z

docs/en/02_Developer_Guides/10_Email/index.md

+like to use a more robust transport to send mail you can swap out the transport used by the `Mailer` via config:
+
+```yml
+Mailer:


Needs the full namespace: SilverStripe\Control\Email\Mailer:

tractorcow · 2017-01-10T23:34:02Z

src/Control/Email/Mailer.php

-        if ($body) {
-            $result .= "\n$body";
+        if (!$this->swift) {
+            $this->setSwiftMailer(new \Swift_Mailer($this->getTransport()));


We could inject this with dependencies, instead of via PHP.

Injector: Swift_Transport: Swift_MailTransport Swift_Mailer: constructor: - '%$Swift_Transport' SilverStripe\Control\Email\Mailer: properties: SwiftMailer: '%$Swift_Mailer'

How about this?

+1. This approach would be in keeping with what we've done for assets and logging.

In addition the plugins could be provided to Swift_Mailer with the Injector's 'calls' option.

I think that SilverStripe\Control\Email\Mailer could be an interface, with the current impelmentation called SilverStripe\Control\Email\SwiftMaileror something.

The interface would probably be very simple:

namespace SilverStripe\Control\Email; interface Mailer { public function send(Email $message); public function getFailedRecipients(); }

That being the case, rather than Mailer::get_inst() we'd probably want to use Injector::inst()->get(Mailer::class).

Alternatively, we could do away with Mailer altogether and use Injector to provide a Swift_Mailer class? We can use the yaml config to add the transport and plugins.

For test mailing we could make a test transport instead?

Alternatively, we could do away with Mailer altogether and use Injector to provide a Swift_Mailer class? We can use the yaml config to add the transport and plugins.

The problem with this is we can't send Email objects directly to the Mailer for sending as we can now.

We'd basically just be implementing raw SwiftMailer without any convenience methods.

tractorcow · 2017-01-10T23:37:12Z

src/Control/Email/Mailer.php

 use SilverStripe\Core\Object;
+use Swift_Mailer;
+use Swift_MailTransport;


I second @kinglozzer's suggestion, however I don't think it's critical to fully-decouple from swiftmailer for the sake of the initial implementation. It's not a merge blocker. :)

tractorcow

Initial review completed. :) Good so far overall.

tractorcow · 2017-01-10T23:39:36Z

src/Control/Email/Mailer.php

-     * @param string $fullBody Prepared message
-     * @param array $headers Prepared headers
-     * @return mixed Return false if failure, or list of arguments if success
+     * @return mixed


Please use @return static or @return Mailer for correct type hinting. :)

tractorcow · 2017-01-10T23:43:45Z

src/Control/Email/Email.php

     */
-    protected $ss_template = 'GenericEmail';
+    private $template = "SilverStripe\\Email\\Email";


Can you please use the full qualified path for the template? The convention is that it should match the same class name.

I.e.

private static $template = 'SilverStripe\Control\Email\Email, or just private static $template = self::class.

Sorry, private $template not private static $template in this case. :)

tractorcow · 2017-01-10T23:46:56Z

src/Control/Email/Email.php


-            // Rewrite relative URLs
-            $this->body = HTTP::absoluteURLs($fullBody);


Very easy to miss, but we need to ensure we still do this somewhere. Perhaps convert absoluteURLs() in Email::render() ? Relative links won't work in email content once sent.

phew - good spot. added

Actually, I've moved it to setBody so we always do this on the body regardless of render. However, maybe the Mailer or even SwiftPlugin should do it to absolutely make sure nothing can get through?

Yep good job.

tractorcow · 2017-01-10T23:48:04Z

src/Control/Email/Email.php


-            // Rewrite relative URLs
-            $this->body = HTTP::absoluteURLs($fullBody);
+    public function addAttachmentFromData($data, $name, $mime = null)


PHPDoc missing. :)

tractorcow · 2017-01-10T23:48:33Z

src/Control/Email/Email.php

    }

    /**
-     * @return string|null
+     * @return array


Should be @return string

it returns an array see my test testGetSetSender

If I look at SimpleMessage::getSender(), it says @return string, so something is wrong here.

I guess SimpleMessage::getSender() is wrong?

I think so!

tractorcow · 2017-01-10T23:49:04Z

src/Control/Email/Email.php

-     * and it won't be plain email :)
-     *
-     * @param bool $isPlain
+     * @param string $path Path to file


Please phpdoc $alias and $mime arguments too.

tractorcow · 2017-01-10T23:52:38Z

src/Control/Email/Email.php

-            if ($this->bcc) {
-                $headers['Bcc'] = $this->bcc;
-            }
+    /**


I think this needs a good description. Also please document the method signature for the $callback

On second thoughts, see my below comment.

tractorcow · 2017-01-10T23:54:33Z

src/Control/Email/Email.php

+     * @param callable|null $callback
+     * @return static
+     */
+    public static function create_from_callback($template, $data, $callback = null)


I'm not sure why this is valuable; All it does is wrap Email::create()->setArg()->setArg()? All of these setters return $this, so there's nothing preventing them from being chained. I think we should just drop this method altogether.

Hmm - originally it was a nice convenience method which would call render for you (it had been mandatory to call render by hand otherwise) but after @kinglozzer's suggestion of checking if the body is empty, this may be less desirable...

tractorcow · 2017-01-10T23:57:10Z

src/Control/Email/Email.php

+    /**
+     * Send the message to the recipients
+     *
+     * @return array|bool true if successful or array of failed recipients


It might be more concise to have a simple boolean response, and document that the user can call $message->getFailedRecipients() to get the list of failed recipients.

The problem is some recipients could be successful and some rejected which means that a true/false return value is misleading. If one recipient is rejected then we should return false, but that doesn't mean a complete failure and so more debugging is needed.

I suppose that just means better documentation is required...

tractorcow · 2017-01-10T23:58:59Z

src/Control/Email/Mailer.php

-        // Send prepared message
-        return $this->sendPreparedMessage($to, $from, $subject, $attachedFiles, $customHeaders, $fullBody, $headers);
-    }
+    private $failedRecipients = array();


I don't think that the service should be storing data related to specific invocations of Mailer::sendSwift(); I suggest to pass this back to Email::send() and have it stored on the email instance instead. Otherwise it dilutes the role of Mailer as a service.

Ok - good point.

sminnee

This is looking really good, but I don't think we need the Mailer class. Let's just get Injector to build us a Swift_Mailer object and have Email.php request that service from Injector.

sminnee · 2017-01-11T04:31:02Z

src/Security/Member.php

@@ -953,17 +954,16 @@ public function onBeforeWrite()

        // We don't send emails out on dev/tests sites to prevent accidentally spamming users.
        // However, if TestMailer is in use this isn't a risk.
-        if ((Director::isLive() || Email::mailer() instanceof TestMailer)
+        if ((Director::isLive() || Mailer::get_inst() instanceof TestMailer)


Would it be better to rely on Injector for these global services?

I'd like to get rid of these references completely. Are tests not run under "live" mode?

sminnee · 2017-01-11T04:33:48Z

src/Control/Email/Mailer.php

@@ -15,513 +13,124 @@ class Mailer extends Object
 {


May as well remove 'extends Object' while we're tidying up this class.

sminnee · 2017-01-11T04:36:25Z

src/Control/Email/Mailer.php

-        if ($body) {
-            $result .= "\n$body";
+        if (!$this->swift) {
+            $this->setSwiftMailer(new \Swift_Mailer($this->getTransport()));


+1. This approach would be in keeping with what we've done for assets and logging.

sminnee · 2017-01-11T04:44:45Z

docs/en/02_Developer_Guides/10_Email/index.md

+
+or in PHP
+
+```php


Don't encourage the use of PHP-based configuration I think.

sminnee · 2017-01-11T04:47:27Z

src/Control/Email/Email.php

-                $subject .= " [from $from]";
-            }
-            $from = $sendAllfrom;
+        $numFailed = Mailer::send_message($this);


Would change this to Injector::inst()->get(Mailer::class)->send($this) if Mailer is to become an interface.

sminnee · 2017-01-11T04:47:53Z

src/Control/Email/Email.php

-            $from = $sendAllfrom;
+        $numFailed = Mailer::send_message($this);
+        if ($numFailed) {
+            return Mailer::get_inst()->getFailedRecipients();


Would change this to Injector::inst()->get(Mailer::class)->getFailedRecipients() if Mailer is to become an interface.

sminnee · 2017-01-11T04:51:12Z

src/Control/Email/Mailer.php

-        if ($body) {
-            $result .= "\n$body";
+        if (!$this->swift) {
+            $this->setSwiftMailer(new \Swift_Mailer($this->getTransport()));


In addition the plugins could be provided to Swift_Mailer with the Injector's 'calls' option.

I think that SilverStripe\Control\Email\Mailer could be an interface, with the current impelmentation called SilverStripe\Control\Email\SwiftMaileror something.

The interface would probably be very simple:

namespace SilverStripe\Control\Email; interface Mailer { public function send(Email $message); public function getFailedRecipients(); }

That being the case, rather than Mailer::get_inst() we'd probably want to use Injector::inst()->get(Mailer::class).

Alternatively, we could do away with Mailer altogether and use Injector to provide a Swift_Mailer class? We can use the yaml config to add the transport and plugins.

For test mailing we could make a test transport instead?

dhensby · 2017-01-11T14:21:03Z

I've implemented pretty much all the feedback.

@sminnee In addition the plugins could be provided to Swift_Mailer with the Injector's 'calls' option.

How could we do this and allow devs to specify many plugins that should be loaded?

This could work for our case, but doesn't provide a nice way for devs to add extra plugins:

SilverStripe\Core\Injector\Injector:
  Swift_Plugin: SilverStripe\Control\Email\SwiftPlugin
Swift_Mailer:
  calls:
    SwiftPlugin:
      - registerPlugin
      - [ '%$Swift_Plugin' ]

todo:

More docs highlighting how to do lots of this stuff with Injector

dhensby · 2017-01-11T14:59:19Z

Looks like https://github.com/silverstripe/silverstripe-behat-extension's TestMailer needs re-writing

sminnee

OK - I noted a couple of method on SwiftMailer that could be removed / protected, and suggested a different yml style recommendation for docs about changing the transport.

In addition, I think we need a mention of this on the upgrade guide. We should also note that $Body in GenericEmail has been renamed to $EmailContent.

sminnee · 2017-01-11T20:26:03Z

src/Control/Email/SwiftMailer.php

+    /**
+     * @return static
+     */
+    public static function get_inst()


Delete this.

sminnee · 2017-01-11T20:26:19Z

src/Control/Email/SwiftMailer.php

+     * @param Email $message
+     * @return int
+     */
+    public static function send_message($message)


Delete this.

sminnee · 2017-01-11T20:27:36Z

src/Control/Email/SwiftMailer.php

+     * @param Swift_Message $message
+     * @return int
+     */
+    public function sendSwift($message, &$failedRecipients = null)


I think it would be tidier if this was protected because it's not part of the interface-provided API. If people start calling it directly it becomes harder for another implementation of the Mailer interface to be dropped in as a replacement.

sminnee · 2017-01-11T20:30:10Z

docs/en/02_Developer_Guides/10_Email/index.md

+
+```yml
+SilverStripe\Control\Email\Mailer:
+  swift_transport: Swift_SendmailTransport


Would it be better to recommend that developers override the Swift_Transport service instead? Otherwise the resulting service definition list will include a service called "Swift_Transport"' that's not actually the swift transport being used...

Swift_Transport: class: Swift_SendmailTransport

Yes, I'll amend

sminnee · 2017-01-11T22:43:58Z

@dhensby if you can rebase to the latest master and fix up src/Dev/TestMailer.php, behat should Just Work(tm)

…d email system

tractorcow · 2017-01-12T03:19:15Z

_config/config.yml

+    constructor:
+      - '%$Swift_Transport'
+    calls:
+      SwfitPlugin:


Typo: SwiftPlugin

Typo still here in your last push :)

tractorcow · 2017-01-12T03:21:48Z

src/Control/Email/Email.php

-            'mimetype' => $mimeType,
-        );
+        $swiftMessage->setDate(DBDatetime::now()->Format('U'));
+        if (!$swiftMessage->getFrom() && $defaultFrom = $this->config()->admin_email) {


Operator precedence; Should the assignment = be surrounded with braces, since it's lower than the &&?

Because the assignment is the last condition it won't be messed up an assign a boolean value, however I'll wrap it in parentheses for clarity.

tractorcow · 2017-01-12T03:25:21Z

src/Control/Email/Email.php

    }

    /**
-     * @return string|null
+     * @return array


If I look at SimpleMessage::getSender(), it says @return string, so something is wrong here.

tractorcow · 2017-01-12T03:27:45Z

src/Control/Email/Email.php

    }

    /**
-     * @return string|null
+     * @return array


I guess SimpleMessage::getSender() is wrong?

tractorcow · 2017-01-12T03:33:36Z

src/Control/Email/SwiftMailer.php

+ * Mailer objects are responsible for actually sending emails.
+ * The default Mailer class will use PHP's mail() function.
+ */
+class SwiftMailer


You forgot implements Mailer interface.

tractorcow · 2017-01-12T03:34:39Z

src/Control/Email/Mailer.php

-
-        return $emailAddress;
-    }
+    public function getFailedRecipients();


Was this going to be moved to Email? SwiftMailer doesn't implement this, so we can just remove this I guess.

yep - removed

tractorcow · 2017-01-12T03:35:17Z

src/Control/Email/SwiftMailer.php

+     * @param Swift_Message $message
+     * @return int
+     */
+    public function sendSwift($message, &$failedRecipients = null)


Missing PHPDoc.

tractorcow · 2017-01-12T03:37:50Z

src/Control/Email/SwiftMailer.php

+    public function setSwiftMailer($swift)
+    {
+        // register any required plugins
+        foreach ($this->config()->get('swift_plugins') as $plugin) {


This needs to be a simple setter. Use YML injection to set these plugins on the injected $swift object.

The question is how does that let site developers add 1 more plug-in in addition to what's currently existing.

@tractorcow see #6466 (comment)

Ok, that's good enough I guess.

tractorcow · 2017-01-12T03:43:33Z

src/Control/Email/Email.php

+        $this->getSwiftMessage()->setContentType('text/plain');
+        if (!$this->getBody()) {
+            $this->render();
+            $this->setBody(Convert::xml2raw($this->getBody()));


This code looks super risky, especially if you are sending an email multiple times, you are at risk of double-encoding.

Why not have separate messages for plain / html (with separate setBody / setPlainBody) and allow them to be set independently? You can always convert between the two if attempting to send one which is blank. :)

Use cases:

Send a HTML message with a html template, I want the system to automatically pick a plain text version for me (as current implementation)

Send a HTML message with a html template, and separate plain text string provided for plain text version

Sending a plain text message only with a setPlainBody().

Sending a html and plain message, I will provide setBody() / setPlainBody() for each.

Yeah, agreed. Perhaps there should be a getPlainBody() / setPlainBody() pair, and this transformation is called is PlainBody isn't set explicitly?

Alternatively getPlainTextSwiftMessage() could be a second getter that transforms the email prior to passing it to the mailers. This, however, would mean that the mailer would need to accept a swift message object rather than our email. I don't have a problem with that, but it's another tweak to the interface.

If the Convert::xml2plain is inside the if (!$this->getBody()) block then there's no risk of double encoding because we render and then take a copy we don't repeatedly set the plain part.

Adding the plain part automatically is all round risky. I don't like that the send method does anything other than send the email (it tries to guess if it should be rendered and then attempts to render a plain part too).

In Laravel you have to set the plain part explicitly and can even define a template for the plain version - perhaps we should do something similar.

We could have something like.

$email = Email::create() ->setHTMLTemplate('MyTemplate') ->setPlainTemplate('MyTemplate_plain') ->send(); //still performs a render

Or if there's no plain template we create a generatePlainPart method that does what we have at the moment.

I think the biggest challenge is with reusing Email objects because I'm not so sure how easy it is to detach the previously generated plain part... I'll look into it.

I have code in HTMLText that generates plain text from HTML if you want to re-use that. :)

/** * Get plain-text version * * @return string */ public function Plain() { // Preserve line breaks $text = preg_replace('/\<br(\s*)?\/?\>/i', "\n", $this->RAW()); // Convert paragraph breaks to multi-lines $text = preg_replace('/\<\/p\>/i', "\n\n", $text); // Strip out HTML tags $text = strip_tags($text); // Implode >3 consecutive linebreaks into 2 $text = preg_replace('~(\R){2,}~', "\n\n", $text); // Decode HTML entities back to plain text return trim(Convert::xml2raw($text)); }

tractorcow · 2017-01-12T20:03:39Z

_config/config.yml

+    constructor:
+      - '%$Swift_Transport'
+    calls:
+      SwfitPlugin:


Typo still here in your last push :)

sminnee

The TestMailer::saveEmail() API change isn't a blocker but it will require another patch to behat-extension.

sminnee · 2017-01-12T22:03:03Z

src/Dev/TestMailer.php

-        ]);
+    public function send($message)
+    {
+        $this->saveEmail($message);


Did you have to change the API for saveEmail? Now the behat test mailer is broken again :-(

:(

An email isn't really suitably represented by the old parameters and I thought best that we just store the email object instead...

This test suite is passing - where are the failures coming from?

$state->emails[] = array_filter($data); in TestMailer::saveEmail() in behat extension. array_filter will fail on an Email instance.

TestSession state needs to be serialized, which is the main reason these were originally array format. I think maybe we should revert this back?

Whatever you thinks best :)

But if they rely on some of the specific data (like Type) then behat tests will need changing because that's not really a thing anymore.... or we'll need to have a "best guess" at type.

All of my guesses are the best.

tractorcow · 2017-01-13T01:25:40Z

@sminnee I've pushed a change to revert api changes to TestMailer.

tractorcow · 2017-01-13T01:30:36Z

Happy to merge once CI passes.

sminnee · 2017-01-13T01:35:20Z

OK I'm happy with this. Say the word and I'll squash & merge

dhensby added the affects/v4 label Jan 9, 2017

dhensby added this to the CMS 4.0.0-alpha4 milestone Jan 9, 2017

dhensby force-pushed the pulls/4/mailer branch from 6bc80bc to b1a9e4c Compare January 9, 2017 13:58

kinglozzer reviewed Jan 9, 2017

View reviewed changes

dhensby force-pushed the pulls/4/mailer branch from b1a9e4c to 944a0a7 Compare January 9, 2017 14:40

kinglozzer reviewed Jan 9, 2017

View reviewed changes

dhensby force-pushed the pulls/4/mailer branch from 944a0a7 to 1a75b8e Compare January 9, 2017 18:09

dhensby force-pushed the pulls/4/mailer branch 6 times, most recently from 04e7ca0 to 7d56db1 Compare January 10, 2017 13:51

tractorcow reviewed Jan 10, 2017

View reviewed changes

tractorcow suggested changes Jan 11, 2017

View reviewed changes

sminnee mentioned this pull request Jan 11, 2017

Move Mailer to SwiftMailer #1366

Closed

sminnee requested changes Jan 11, 2017

View reviewed changes

dhensby force-pushed the pulls/4/mailer branch 2 times, most recently from 7fe018f to 8b51bb7 Compare January 11, 2017 14:07

dhensby force-pushed the pulls/4/mailer branch 4 times, most recently from f01662c to bab27ba Compare January 11, 2017 14:48

sminnee requested changes Jan 11, 2017

View reviewed changes

tractorcow approved these changes Jan 12, 2017

View reviewed changes

dhensby added 3 commits January 12, 2017 00:08

API Replace existing Email and Mailer classes with SwiftMailer powere…

272380a

…d email system

DOCS New Email docs

a0c8026

Initial feedback from Damian

7050be3

dhensby force-pushed the pulls/4/mailer branch 3 times, most recently from a12b5ba to d5127af Compare January 12, 2017 00:16

tractorcow suggested changes Jan 12, 2017

View reviewed changes

dhensby added 2 commits January 12, 2017 10:42

Making Mailer an interface

022d050

Templates relocated

66dd003

dhensby force-pushed the pulls/4/mailer branch 3 times, most recently from 91f7172 to b1482fb Compare January 12, 2017 13:47

tractorcow suggested changes Jan 12, 2017

View reviewed changes

_config/config.yml

constructor:

- '%$Swift_Transport'

calls:

SwfitPlugin:

Copy link

Contributor

tractorcow Jan 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo still here in your last push :)

dhensby force-pushed the pulls/4/mailer branch from b1482fb to d908c76 Compare January 12, 2017 21:20

dhensby added 2 commits January 12, 2017 21:22

Round of feedback

c08386e

More robust approach to plain parts

902fb72

dhensby force-pushed the pulls/4/mailer branch from d908c76 to 902fb72 Compare January 12, 2017 21:22

sminnee approved these changes Jan 12, 2017

View reviewed changes

Revert changes to TestMailer

f2d7c84

tractorcow approved these changes Jan 13, 2017

View reviewed changes

sminnee mentioned this pull request Jan 13, 2017

[2013-02-05] Tighten up usage of dependency injection in core #1678

Closed

sminnee merged commit 3ea5015 into silverstripe:master Jan 13, 2017

This was referenced Jan 13, 2017

Email validation does not allow international email addresses #3057

Closed

Inline image embedding in emails #4745

Closed

dhensby deleted the pulls/4/mailer branch January 13, 2017 07:47


		// Rewrite relative URLs
		$this->body = HTTP::absoluteURLs($fullBody);


		or in PHP

		```php

NEW Move to SwiftMailer powered Emails #6466

NEW Move to SwiftMailer powered Emails #6466

Conversation

dhensby commented Jan 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kinglozzer Jan 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kinglozzer commented Jan 9, 2017 • edited Loading

dhensby commented Jan 9, 2017

dhensby commented Jan 9, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tractorcow left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sminnee left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dhensby commented Jan 11, 2017

dhensby commented Jan 11, 2017

sminnee left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sminnee commented Jan 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dhensby commented Jan 9, 2017 •

edited

Loading

kinglozzer Jan 9, 2017 •

edited

Loading

kinglozzer commented Jan 9, 2017 •

edited

Loading