You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current process for sending email via the Mailgun API involves registering a Mailer (MailgunMailer) and connecting to the mailgun php sdk via a connection client (Connector\Message).
The Mailer handles stand to/from/subject and also the passing custom parameters from project code to the Mailgun API. The connector can make some decisions about how and when the message should be sent based on those parameters + project configuration. Sending out-of-band as a job, for instance.
Silverstripe framework >= 4.9.0 moved to swiftmailer v6 support BUT swiftmailer/swiftmailer has been archived with a note to move to symfony/mailer. There is a related open issue: silverstripe/silverstripe-framework#10097
symfony/mailer provides a Mailgun transport: https://github.com/symfony/mailgun-mailer which we could investigate using as it could reduce duplication of effort, provided the transport supports what can be done currently.
The current process for sending email via the Mailgun API involves registering a Mailer (MailgunMailer) and connecting to the mailgun php sdk via a connection client (
Connector\Message
).The Mailer handles stand to/from/subject and also the passing custom parameters from project code to the Mailgun API. The connector can make some decisions about how and when the message should be sent based on those parameters + project configuration. Sending out-of-band as a job, for instance.
Silverstripe framework >= 4.9.0 moved to swiftmailer v6 support BUT swiftmailer/swiftmailer has been archived with a note to move to symfony/mailer. There is a related open issue: silverstripe/silverstripe-framework#10097
symfony/mailer provides a Mailgun transport: https://github.com/symfony/mailgun-mailer which we could investigate using as it could reduce duplication of effort, provided the transport supports what can be done currently.
That said, any change would need to support:
The end result should be:
If BC could be ensured, it could be tagged as v1.x
The text was updated successfully, but these errors were encountered: