- Does MailHookBundle work with Laravel?
- No. MailHookBundle is a Symfony bundle built on Symfony's bundle, DI extension, and TreeBuilder config system, and the repository shows no Laravel service provider, facade, or config-publishing surface. Running composer require in a Laravel app and relying on package auto-discovery will not give you a working mail interceptor. If your stack is Laravel, look for a maintained Laravel mail-capture package or scope an adapter as a separate work item rather than folding it into the base integration estimate.
- How do I install and register MailHookBundle in a Symfony application?
- Install it with Composer, pinning ^3.0.2 for the Symfony 5 compatible line, then register the bundle in your kernel or bundles.php and route your mailer through the bundle's transport so outbound Swiftmailer mail flows into MailHook. The 3.0.2 release adds no new configuration options or commands, so follow the README for the exact transport settings and API route. After registering it, send a test email and query the API to confirm the capture is working before wiring it into your team workflow.
- Which Symfony and PHP versions does MailHookBundle 3.0.2 support?
- The 3.0.2 changelog explicitly claims Symfony 5 support and fixes the deprecated TreeBuilder::root call, but it does not publish a full compatibility matrix. Read the symfony/* and php constraints in composer.json directly instead of trusting the release notes. Note also that a patch-level bump carrying a new framework major-version support claim is an unusual packaging choice, so verify nothing else broke before adopting it.
- How does MailHookBundle capture emails without a real SMTP server?
- It hooks into the mailer subsystem and intercepts messages sent through Swiftmailer, redirecting them to the MailHook service instead of an external transport. That means no Mailtrap or MailHog dependency and no outbound network requirement during development. You send mail from your application exactly as you normally would and the bundle catches it.
- How do I read the emails that MailHookBundle catches?
- The bundle exposes a REST API that lets you list and read captured messages, so any HTTP client can pull headers, recipients, and message bodies. Trigger the mail flow you want to debug, then query the API endpoint to inspect the result. This is useful for checking rendered templates, links, and notification copy before anything reaches a real inbox.
- How do I keep MailHookBundle limited to dev and test environments?
- Only load the bundle in your dev and test environments, for example by gating its registration in config/bundles.php on the environment, the same way other debug bundles are handled. Also make sure your mailer transport configuration is environment-scoped so production still uses real delivery. Keeping the bundle out of prod avoids accidentally capturing and swallowing outbound mail.
- What changed in MailHookBundle 3.0.2?
- Version 3.0.2 adds Symfony 5 support, fixes the deprecation around TreeBuilder::root, and includes an SES provider update plus a CI process update. It is a compatibility and hygiene release with no new commands, configuration options, or public API announced. Three of the four pull requests come from a single maintainer, so review the diff yourself rather than assuming broad coverage.
- Can I use MailHookBundle in production?
- It is not recommended. MailHookBundle is intended for local and pre-production mail capture, and the project guidance is to restrict it to dev and test environments. Capturing production mail means outbound messages never reach recipients and message contents may be exposed through an unauthenticated API. Keep it disabled in production and leave real delivery to your production transport.
- How do I assert on captured emails in functional tests?
- Because the transport is pluggable, you can point the mailer at the bundle in your test environment, trigger the code that sends mail, and assert against the messages returned by the REST API instead of sending anything real. That lets you verify recipients, subjects, and rendered bodies without an SMTP sandbox. A small test helper that wraps the API calls keeps those assertions readable. Confirm the bundle is loaded in your test config and that the mailer override is actually taking effect.
- Is MailHookBundle actively maintained, and what should Laravel developers use instead?
- Maintenance is thin: 3.0.2 is a compatibility release driven mainly by one maintainer, so bus factor is effectively one and there is no documented release cadence or 3.x support window. Verify the composer.json constraints and the CI matrix before committing to it. For Symfony teams wanting lightweight local mail capture with no external service it is a reasonable fit, but Laravel teams should use a maintained Laravel mail-capture package or Laravel's built-in mail fake and log driver instead.