- Is terehinis/mandrill-bundle compatible with Laravel?
- No. It is a Symfony bundle that expects a Bundle class, a DI Extension, and container-managed services, not Laravel's service provider and package discovery model. There is no clean install path into a Laravel application. Treat it as a reference implementation and plan a port rather than an adoption.
- Can I install this Mandrill bundle with Composer in a Laravel app?
- Composer may fetch the code, but it will not register or boot in Laravel. The package targets Symfony's AppKernel or bundles.php registration and Symfony's dependency injection container. Installing it does not give you a working mail transport in Laravel. You would still need to write Laravel-specific integration code.
- Does this package support Laravel 10, 11, or 12?
- No. The bundle predates Symfony Flex, autowiring defaults, and the Symfony Mailer component, and it likely depends on Swiftmailer, which reached end of life in November 2021. Laravel 10 through 12 use the Illuminate mail manager and Symfony Mailer under the hood. Supporting those versions requires a new Laravel transport, not a configuration change.
- How do I configure Mandrill API credentials for Laravel after porting it?
- The original bundle defines credentials and options through a Symfony configuration tree and injects them into container services. In Laravel, put the API key in config/services.php sourced from an environment variable, then bind your transport through a service provider. Never commit the key, and keep provider-specific settings isolated in one adapter.
- How do I send Mandrill template emails from Laravel using this bundle's logic?
- Extract only the API call logic and re-implement it as an Illuminate mail transport or a small adapter around the official mandrill/mandrill SDK or a PSR-18 HTTP client. Call Mandrill's /messages/send-template endpoint with template_name, template_content, and the message payload, and wrap it in a queued job for production use. The core adapter is roughly 150 to 250 lines plus tests.
- What Mandrill features does the bundle support?
- The bundle supports templated and dynamic transactional emails, Mandrill tags, metadata, and merge variables, with credentials injected through Symfony services. It does not document coverage for every Mandrill endpoint such as subaccounts or webhooks. Verify exactly which /messages endpoints are covered before relying on it as a feature checklist.
- Is terehinis/mandrill-bundle maintained and safe for production?
- There are no visible release cadence, security process, or adoption signals such as stars or dependents. It is unmaintained and has no PHP 8 or CVE coverage guarantees, so it belongs on a dependency deny-list or a documented exception. Mandrill itself is governed by Mailchimp terms and quotas, adding another layer outside your control.
- Does the bundle have a test suite, and does it hit the live Mandrill API?
- The available information does not confirm a test suite or whether tests use a fake versus a live API. Before reusing any code, audit the package for tests and check whether they require a real API key. For your Laravel port, contract-test /users/ping with a test key and use fixtures or a fake HTTP client for message-sending tests.
- How much effort is it to port this Symfony bundle to a Laravel mail transport?
- Estimate two to four developer-days to extract the API call logic and add tests. A production-grade port covering configuration, dependency injection, error mapping, retries, and webhook verification is closer to one to two weeks. Model this as a build task, not as adopting an existing Laravel package.
- What is the best alternative to this bundle for sending Mandrill email in Laravel?
- Build a thin custom transport registered through an Illuminate service provider, using the official Mandrill SDK or a PSR-18 HTTP client, and keep all provider-specific code in a single adapter. This avoids inheriting a second abandoned dependency on top of Mandrill. Confirm the license before copying any code from the original bundle.