Filament Mail Editor Laravel Package

Product Decisions This Supports

• Build vs. buy for in-app email templating. This package replaces a bespoke stack (template CRUD, block-based WYSIWYG, variable merging, previews, export) with a Filament-native implementation. The decision to evaluate is not "can we build this" but "do we want to own it" — adoption converts a build cost into an ongoing upgrade cost.
• Who owns email copy. The drag-and-drop builder, block forms and previews let marketing/ops/support edit transactional and lifecycle emails without engineering tickets. That is a headcount-and-throughput decision, not just a technical one: it changes the operating model for lifecycle messaging.
• Template governance and environment promotion. JSON export/import means templates can live as versioned artifacts in the repo and be promoted staging → production. Worth deciding now whether templates are code (reviewed, versioned, deployed) or content (edited live by non-engineers) — this package supports both, and the answer drives your release process.
• Extensibility as product surface. The new HasPropsSchema contract gives custom blocks a real Filament form in the block library. That turns "we want branded product cards / pricing tables / personalized modules" into a scoped, incremental roadmap item rather than a fork. Each custom block should be budgeted as a small product feature (schema + render template + QA), not a one-off.
• Platform vs. admin-only capability. The 1.1.0 split moves the Laravel core into laravel-mail-editor, with this package keeping only the Filament layer. That is a meaningful architectural fork in the road: if template editing may ever need to appear outside the admin panel (customer portal, API-driven, headless), the core package is the substrate and should be evaluated on its own merits. Decide now whether email templating is a Filament feature or a platform capability.
• Analytics loop. The metrics widget can close the "did this email perform" loop inside the admin. Before putting it on a dashboard roadmap, validate exactly what it measures — if it is a thin wrapper over your own event data, the real work is instrumentation, not the widget.
• QA and approval workflows. Browser-rendered preview and countdown routes (mail-editor.preview, mail-editor.countdown) enable a human approval step before send. They also create a route surface that needs authentication/authorization review — a product decision about who can preview a template containing real customer data.

When to Consider This Package

Adopt when:

• You are already running Filament for your admin panel and want email editing in-panel rather than adding a separate SaaS tool and another login.
• Non-technical stakeholders genuinely need to author emails (this is the core value proposition — if engineers will always write the emails, you are paying maintenance for unused capability).
• You want block-based authoring with variable merge, previews and export for version control, rather than raw HTML textareas or a hosted ESP editor.
• You accept owning upgrades. This release is a breaking change shipped under a 1.x minor version (namespace, config key, route paths, export format id all changed). Treat the package as a moving dependency: pin exact versions, read every changelog, and budget migration work per upgrade.

Look elsewhere when:

• You are not on Filament — the value here is the Filament integration; without it you would be pulling in the core package and building the UI yourself.
• You need sending, deliverability, list management or ESP-level analytics. This is an authoring layer, not an ESP. Pair it with your transactional provider rather than expecting it to replace one.
• You need compiled-template pipelines (MJML / React Email / design-system components) with strict brand enforcement. Block libraries are constrained by design; a compiled pipeline gives you token-level control this package will not.
• You need hard multi-tenancy, audit trails or compliance-grade template change history. Verify current capabilities before assuming; if that is a hard requirement, the churn seen in 1.1.0 suggests the package is still finding its shape.
• Template volume is low. A handful of emails is better served by a hosted ESP template editor; the integration and upgrade cost of an in-house editor needs volume or autonomy to pay for itself.

How to Pitch It (Stakeholders)

For executives — one paragraph: "This buys us a working, block-based email template editor inside our existing admin panel for the cost of an integration rather than a build. Marketing and ops can edit email content without filing engineering tickets, and templates can be exported and version-controlled like code. The trade-off is that we now own upgrades: the latest release restructures the package (namespaces, config keys and routes all change), so we should plan a short migration and pin versions going forward. It is a buy-not-build decision on the authoring layer, not a replacement for our email sending provider."

For engineering — the integration brief:

• Filament-layer plugin. The Laravel core moved to jeffersongoncalves/laravel-mail-editor and is installed automatically; this package now ships resources, the drag-and-drop builder, the metrics widget and block forms.
• Breaking changes in 1.1.0 to plan for: models/enums/events/support/seeder moved from JeffersonGoncalves\FilamentMailEditor\… to JeffersonGoncalves\MailEditor\…; config, migrations and translations now use the mail-editor key (config/mail-editor.php, --tag="mail-editor-migrations", --tag="mail-editor-config"); preview and countdown routes moved from /filament-mail-editor/* to /mail-editor/* (mail-editor.preview / mail-editor.countdown); JSON exports use the mail-editor format id, though files exported under filament-mail-editor still import.
• Upgrade checklist: re-publish config and migrations under the new tag, grep for the old namespace in app code and any custom blocks, grep for hardcoded filament-mail-editor route strings, and re-verify any external links or emails pointing at preview URLs.
• New capability: HasPropsSchema lets custom blocks define their own Filament form in the block library — the intended path for bespoke blocks instead of forking.
• Test posture improved: smoke tests now cover every resource page and the custom table actions, which materially reduces the risk of a regression slipping through this migration.
• Recommendation: pin to an exact version, upgrade in a single dedicated PR with the smoke suite green, and raise the semver hygiene issue with the maintainer — breaking changes under a 1.x minor is the main ongoing risk to our maintenance budget.