Weave Code
Mailables Viewer Laravel Package
statamic/mailables-viewer
Browse and preview Laravel mailables inside Statamic's control panel. Mailables Viewer surfaces your mailable classes, renders each email, and lets you inspect HTML and text output without leaving the CMS, making it easier to review templates, spot layout issues, and confirm content before mail goes...
Preview Laravel mailables from the Statamic Control Panel.
Frequently asked questions about Mailables Viewer
- How do I install statamic/mailables-viewer?
- Install it with Composer using composer require statamic/mailables-viewer. The addon registers itself through package auto-discovery, so there are no migrations, no schema changes, and no required config publication. For most teams the right call is to install it as a require-dev dependency so it cannot ship in production artifacts.
- Which Statamic, Laravel, and PHP versions does it support?
- The package is a Statamic addon, so it requires a Statamic application running on Laravel; it is not a drop-in for plain Laravel projects. The exact constraint range for version 1.1.0 should be verified in the package's composer.json before you commit. Confirm it resolves against your property's current Statamic major during a dev-only install rather than assuming compatibility.
- How does Mailables Viewer find my mailable classes?
- It auto-discovers mailables from your configured paths, which means standard Laravel structures such as app/Mail work with zero configuration. You only need to touch configuration if your mailables live somewhere non-standard. That zero-config discovery is the main ergonomic win over hand-rolling a preview route.
- Is it safe to run in production?
- Treat it as an internal review surface, not a public one. Previewing a mailable renders real content, which can include recipient data or internal-only copy, so the viewer route must sit behind Statamic Control Panel authorization or a local/staging guard. Verify the guard from outside the Control Panel rather than by reading config, and prefer a require-dev install with an environment check.
- Does the ?mailable= parameter accept a raw class name, and is it validated?
- Version 1.1.0 adds a query parameter on top of the existing route, and resolving a class from a user-supplied string means instantiating whatever class the request names. That is only safe if selections are validated against an allowlist or a namespace prefix derived from registered mailables. If raw fully qualified class names are accepted on a reachable route, it becomes an object-instantiation surface and an information-disclosure vector, so test this before rollout.
- What happens with mailables that have constructor dependencies, like models or DTOs?
- Mailables that require constructor arguments may fail to resolve, which will look like a broken feature inside the Control Panel rather than an error in your code. Before adopting, check whether such classes are resolved with container injection, skipped from the list, or throw a hard error. A short allowlist of simple, argument-free mailables is a pragmatic way to keep the viewer useful.
- Is this a replacement for Mailpit, Mailtrap, or Laravel mailable assertions?
- No. Mailables Viewer is a browse-and-preview surface inside the CMS, not a testing or deliverability tool. Inbox rendering fidelity across Outlook and Gmail quirks, plus automated regression assertions, still belong to Laravel's mailable assertions and a catcher such as Mailpit or Mailtrap. Calling it QA tooling rather than testing tooling avoids a mismatch at sign-off.
- Can I use it in a plain Laravel app without Statamic?
- No, it is built as a Statamic addon that adds a panel to the Control Panel, so a non-Statamic Laravel application cannot use it. For plain Laravel, a small bespoke preview route with a controller and a Blade wrapper is the better investment. The durable value here is the workflow, not the implementation.
- What does an invalid or stale mailable value return?
- This should be confirmed by testing rather than assumed; an unknown, abstract, or stale class name could produce a 404, a framework exception page, or a silent fallback to the list. Graceful handling matters because saved links are brittle and will break when a mailable class is renamed. Validate the parameter before showing previews to non-engineers.
- Is the package actively maintained, and what are the alternatives?
- The package is small in surface area but also small in adoption, with roughly 11 stars, zero dependents, and a single external contributor on the 1.1.0 feature, so it should never become load-bearing. Pin to ^1.1 and keep it dev-only. The fallback is straightforward: a route, a controller, and a Blade wrapper that renders a mailable on demand.
Weaver
How can I help you explore Laravel packages today?