Update SwiftMailer from v5 to v6 #10031
Conversation
danaenz
force-pushed
the
pulls/swiftmailer-v6-support
branch
from
8d35281
to
4b9248e
Compare
- Fixes silverstripe#9834 - Update default Swift_Transport to use Swift_SendmailTransport - Update version restraint for Swiftmailer - Address new parameter type for Swift_Message::setDate() - Update class references in docblocks
danaenz
force-pushed
the
pulls/swiftmailer-v6-support
branch
from
4b9248e
to
4b3cebc
Compare
|
Post-Innovation Day notes: Acceptance Criteria needs to be checked off, and new tests identified and created (if required). After that, this PR will be ready to come out of draft mode. |
| @@ -14,7 +14,7 @@ covers how to create an `Email` instance, customise it with a HTML template, the | |||
| SilverStripe provides an API over the top of the [SwiftMailer](http://swiftmailer.org/) PHP library which comes with an | |||
| extensive list of "transports" for sending mail via different services. | |||
|
|
|||
| Out of the box, SilverStripe will use the built-in PHP `mail()` command via the `Swift_MailTransport` class. If you'd | |||
| Out of the box, SilverStripe will use the built-in PHP `mail()` command via the `Swift_SendmailTransport` class. If you'd | |||
There was a problem hiding this comment.
This isn't what the sendmail transport does, it interacts with the sendmail binary on the operating system - https://swiftmailer.symfony.com/docs/sending.html#transport-types
I think we will either need to pull in transport that uses mail() or write our own :/
There was a problem hiding this comment.
There was a problem hiding this comment.
Yeah this isn't so great
We cannot guarantee if a server has the sendmail binary is available nor if it's enabled in php.ini sendmail_path e.g. some webhosts will use postfix as the backend for mail()
It means that when a site upgrades to say framework 4.9 (assuming this change is merged in) then a site that sends email may suddenly (and probably silently) stop sending email
I think we will either need to pull in transport that uses mail() or write our own :/
Pretty much, I don't see any way around having add back support for the mail() function
| @@ -269,7 +272,7 @@ public function getSwiftMessage() | |||
| */ | |||
| public function setSwiftMessage($swiftMessage) | |||
| { | |||
| $swiftMessage->setDate(DBDatetime::now()->getTimestamp()); | |||
| $swiftMessage->setDate(new DateTime()); | |||
There was a problem hiding this comment.
This breaks our ability to mock the datetime centrally.
|
Closed in favor of #10048 - I've kept the original commit in this PR, thanks for your contribution :-) |
Parent issue #9834
Issues addressed
We noticed issues with SwiftMailer v5 and encrypted file attachments. We implemented a fork successfully with our (WIP) SMIME encryption module.
Configuration updates
Default
Swift_Transportchanged fromSwift_MailTransporttoSwift_SendmailTransport. No configuration changes are required in project code—it is assumed that any variation on configuration in the affected area is by using an alternative SwiftMailer transport class (eg,Swift_SmtpTransport) which does not use a new classname. The docs have been updated to reflect this change.Release version
Since this is a major version change for Swiftmailer and includes a configuration update, I would suggest this to be a minor release.
Deprecation notes
I did not find any additional deprecation notices across PHP 7.4 and 7.3, and will rely on CI to catch other notices.