Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate using symfony/mailgun-mailer transport #8

Open
JamesDPC opened this issue Feb 14, 2022 · 0 comments
Open

Investigate using symfony/mailgun-mailer transport #8

JamesDPC opened this issue Feb 14, 2022 · 0 comments
Assignees

Comments

@JamesDPC
Copy link
Contributor

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:

  1. Create an email in the standard way (Email::create)
  2. Assign parameters at send time, via extension or via configuration
  3. Send the email via the configured transport, now or later.

If BC could be ensured, it could be tagged as v1.x

@JamesDPC JamesDPC self-assigned this Feb 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant