Fosuserbundle Mandrill Mailer Laravel Package

Getting Started

Read this first: this is not a Laravel package. wrep/fosuserbundle-mandrill-mailer is a Symfony 2-era bundle that plugs a Mandrill-backed implementation into FOSUserBundle's MailerInterface. There is no service provider, no illuminate/* dependency, and no config file Laravel will ever load. Its value to you is the pattern — roughly a hundred lines of glue — not the package itself.

• What it actually is: one class implementing FOS\UserBundle\Mailer\MailerInterface (sendConfirmationEmailMessage, sendResettingEmailMessage), plus a Resources/config/services.xml that registers it and swaps it in for FOSUserBundle's default Swiftmailer mailer. Bodies come from FOSUserBundle's Twig email templates (Registration/email.txt.twig, Resetting/email.txt.twig) and are handed to the Mandrill API (messages/send.json) instead of Swiftmailer.
• Where to look first: composer.json (note the symfony/* and friendsofsymfony/user-bundle constraints), then the mailer class, then services.xml, then FOSUserBundle's own TwigSwiftMailer side by side. The diff between those two mailers is the package.
• Symfony install (if you inherit an app using it): composer require wrep/fosuserbundle-mandrill-mailer, enable the bundle in AppKernel, set the Mandrill key, and point FOSUserBundle at it via fos_user.service.mailer: <bundle mailer service id>. Verify with a password-reset request in dev and check Mandrill's outbound activity log.
• Laravel first use case: password reset and email confirmation — you already have both. Illuminate\Auth\Notifications\ResetPassword plus a signed URL reproduces the FOSUserBundle flow. For Mandrill delivery, either register a custom transport (Mail::extend('mandrill', ...)) or wrap Http::withHeaders(['Authorization' => ...])->post('https://mandrillapp.com/api/1.0/messages/send.json', ...) in a queued Mailable.
• A sane first port: one MandrillUserMailer class with sendConfirmation(User $user) and sendPasswordReset(User $user, string $token), a Blade view each, and a queued job. That is the bundle's entire scope.

Implementation Patterns

• Contract-first mailer. FOSUserBundle's one genuinely good idea: the user workflow depends on an interface, not on a concrete transport. In Laravel, type-hint your own UserMailer contract and bind it, so local and testing environments can swap in a LogMailer. Keeps email decisions out of controllers and out of the User model.
• Text + HTML pairs. FOSUserBundle ships both .txt.twig and .html.twig per message and substitutes %username% / %confirmationUrl% placeholders (plus the FOSUserBundle translation domain) rather than Twig variables. When porting to Blade, keep the text/HTML pair and always render absolute URLs — relative links in email are dead on arrival.
• Rendering: server-side versus Mandrill templates.
  • Server-rendered: build HTML/text in Blade/Twig, send html/text to Mandrill. Simplest, fully testable, works with Laravel's __().
  • Mandrill template: send template_name + template_content and let Mandrill's merge language substitute. Better when copy is owned by non-developers, but the *|MERGE|*/handlebars syntax collides with Twig and Blade delimiters — you end up escaping or using @{{ }}.
• Message shape that matters: message.to[], global_merge_vars vs per-recipient merge_vars, tags for analytics, track_opens/track_clicks, async. Set async: true and/or queue the send — a synchronous API call in the reset-request path is exactly the latency problem you don't want.
• Decorate, don't fork. Symfony's idiom here is decorating fos_user.mailer.default; the Laravel analogue is a container binding ($this->app->bind(UserMailer::class, MandrillUserMailer::class)) plus a Notification that sends through a named mailer.
• Multi-tenant keys. Mandrill subaccounts (X-Mandrill-User header) are the intended mechanism if you send for several brands. Keep keys in config/services.php sourced from env().
• Observability. Tag every message (password-reset, confirm-email) and log the _id Mandrill returns — it's the only handle for "did the user actually get the mail?" Wire the mandrill_events webhook to a queued endpoint if deliverability matters.

Gotchas and Tips

• It will not install anywhere modern. Last release 2015-03-08, Symfony 2-era constraints, PHP 5.x assumptions. On Laravel it's a non-starter (no provider, wrong framework); on Symfony 5/6 both the constraints and the FOSUserBundle dependency fail. 4 stars, 0 dependents, no security process — there is no reason to add this to a real composer.json. Treat it as reference code.
• FOSUserBundle is itself legacy. In Symfony its role is now covered by native security plus symfonycasts/reset-password-bundle and MakerBundle. The mailer abstraction is the only part worth reusing.
• Mandrill the service has moved on. Since 2016 it's a Mailchimp transactional add-on (paid Mailchimp plan required, account-bound keys). If the transport choice is still open, Postmark/Mailgun/SES have first-class Laravel mail transports and need none of this glue.
• Check the body, not the status code. messages/send.json returns HTTP 200 with an array of per-recipient results; status (sent / queued / rejected / invalid) and reject_reason carry the truth. A naive "response was 2xx" check silently drops mail. Same trap with messages/send-template.json.
• Placeholder and translation leaks. Miss the FOSUserBundle translation domain or the %confirmationUrl% substitution and users get raw keys or a literal %confirmationUrl% in the body. Assert on rendered output in tests.
• URLs and proxies. Confirmation and reset links must be absolute, must hit a route behind the correct firewall, and should expire. Behind a proxy without TrustProxies, Laravel emits http:// links and the reset URL 404s.
• Test-mode traps. The Symfony mailer will happily attempt a real HTTP call in test unless you override it — same instinct as Mail::fake() / Notification::fake() / Http::fake() in Laravel. A passing fake with the wrong template_name is a silent production failure, so assert the payload.
• Config caching. env() outside config files returns null after config:cache; put the Mandrill key in config/services.php. This is the same failure class as Symfony's compiled container.
• Retries duplicate. Mandrill has no idempotency key. Guard double-triggered reset emails with a uniqueness lock on the job, and don't send array merge vars where the template expects scalars — Mandrill rejects per-message, again under a 200.
• The extension point worth keeping: a mailer interface, the two message templates, and a binding that can be swapped to log in local/testing. That is the reusable core of this package; everything else is 2015 Symfony plumbing.