- How do I install getodden/mail in a Laravel app?
- Install the package with Composer, then publish the front-end editor assets using the documented vendor:publish tag mail-builder-assets. If you use the optional Filament field, run php artisan filament:assets as well. The package is a standard Laravel/Composer integration and does not require a Node build step on your side.
- Why does odden-mail-editor.js fail with a 404 after upgrading getodden/mail?
- In v2.4.0 the editor bundle imports icons.js at module top level, so a missing icons.js breaks the whole editor rather than degrading a single icon. This usually means the published assets are stale or icons.js was never published. Republish the editor assets with the mail-builder-assets tag and verify that icons.js ships alongside odden-mail-editor.js.
- Do I need to republish assets after composer update getodden/mail?
- Yes. Published assets are a manual step and are not updated by Composer alone. Run the documented republish command with --force, or rebuild Filament assets if you use that integration. A deploy that skips this leaves the old odden-mail-editor.js in public/ and can cause asset drift.
- Is getodden/mail v2.4.0 safe to upgrade without database migrations?
- Yes. The release does not change stored documents, compiled email output, or the database surface, and there are no migrations or data-format changes. The schema export changes are additive. Rollback is a version pin plus republishing the prior asset set.
- How does getodden/mail integrate with Filament?
- It provides an optional Filament field and uses filament:assets for the front-end assets, so it slots into an existing admin panel without touching your asset pipeline. Differentiated block icons also flow into the Filament block forms. You can use the package without Filament if you prefer the standalone web component.
- What is the schema export version in getodden/mail and is it backward compatible?
- The v2.4.0 schema export is version 3 and is described as backward- and forward-compatible. New keys such as groups, short_label, group, and description are additive, existing keys are unchanged, and the editor degrades gracefully when they are absent. The evaluation flags whether the version number is exposed as a machine-readable field, so feature-detect optional keys unless your build confirms one.
- Can getodden/mail import MJML or existing HTML emails?
- Yes. The package supports MJML and HTML import alongside its modular block editor. That lets you bring existing templates into the slot-based builder instead of rebuilding them from scratch. Check imported output through the compiler and pre-send audits before production use.
- Does getodden/mail support AMP and plain-text email fallbacks?
- Yes. The package includes AMP support and a plain-text fallback as part of its email compilation workflow. The email output itself is unchanged in v2.4.0, so upgrading does not alter AMP or text rendering behavior. Use the pre-send audits to verify all output formats before sending.
- How do I test getodden/mail emails before sending?
- Use the package's pre-send audits and inspect the compiled email output, including AMP and plain-text variants. Because v2.4.0 does not change compiled output or stored documents, you can test the upgrade against existing templates without backfilling data. Run the republish step in staging first to catch missing editor assets.
- What are the main production risks and maintenance concerns with getodden/mail?
- The dominant risk is asset drift: a deploy that runs composer update but skips the --force republish can leave an old editor bundle in public/. Overwriting locally patched published assets is also a concern, and the Heroicons inlining adds a modest bundle-size increase. Licensing is clean under MIT, but the package's semver policy for schema export versions is not stated in the provided material, so pin versions and treat schema keys as additive.