Tinymce Nova Laravel Package

Getting Started

• Install with composer require the package and run php artisan vendor:publish to pull out its config (look for a tinymce/nova-tinymce config file) and any local editor assets. Register the field on a Nova resource in the usual way: a TinyMCE-style field class added to fields() for the attribute that holds the HTML body.
• Look first at two places: the published config file (it controls whether TinyMCE is loaded from a local build or a CDN, plus the editor defaults forwarded to tinymce.init) and the field class itself, which is where per-field option overrides and the detail/index rendering live.
• The first use case is almost always a Body/Content column on a resource. Add the field, leave the default source alone, save a record with a paragraph and a bulleted list, then confirm the content round-trips through the form and renders correctly on the Nova detail page. That single pass exercises loading, init, save and detail rendering — the four things 1.2.2 touched.

Implementation Patterns

• Field configuration over global config. Set sane global defaults (source, height, toolbar) in the config file, then override per field with the field's fluent methods where the package exposes them. This keeps a "simple comment box" and a "full marketing page editor" on the same resource from fighting each other.
• Source selection is a deployment concern, not a per-field one. Local build for air-gapped/offline or CSP-restricted environments; CDN when you want zero asset publishing. Keep the choice in config (or env), and make sure the same choice applies to every field on the app — 1.2.2 specifically aligns defaults and forwarded options between the two modes, so mixed setups are the risky path.
• Multiple fields per form. Rely on the release's init-when-ready and teardown behaviour: create one field instance per attribute, don't manually call tinymce.init in a custom script, and let the field own the lifecycle. This matters most with Nova's client-side navigation between resources.
• Detail rendering. Default detail output is escaped text with paragraph/list line breaks preserved — good for audit views and for content authored by people you don't fully trust. If you need fully rendered HTML in a detail view, use a custom detail component or Text-style resolver rather than expecting the field's default row to emit raw markup.
• Storage and output. The field stores HTML in a normal text/longText column; 1.2.2 changes nothing about stored content, so existing casts and accessors keep working. When you render that HTML outside Nova (Blade, API), sanitize it (e.g. HTML Purifier) if authors aren't trusted, and wrap with {!! !!} deliberately.
• Index/list views. Rich text in an index column is noise — generally hide the field from the index or provide a truncated plain-text accessor.
• Tests. Mirror the package's own approach: Nova field tests for form/detail behaviour, plus a browser smoke test that loads the form and asserts the editor mounts (and that the fallback textarea appears when the script is blocked).

Gotchas and Tips

• Fallback textarea is a feature, not a bug. On slow or blocked script loads the field now degrades to an editable textarea after a timeout. If users report "the toolbar disappeared", check the network tab for the TinyMCE script first, then the configured timeout — don't chase it as a field bug.
• Local source means published assets. After upgrading, re-publish/rebuild the local editor assets (vendor:publish --force for the tagged assets, or your asset build step). A stale local build silently mismatches the field's expected TinyMCE version after a package bump.
• Config forwarding is data-only. Options passed through from PHP config get handed to tinymce.init, so keep them JSON-serializable — closures, enums and PHP objects won't survive the trip.
• Detail line breaks rely on escaping. The default detail row preserves paragraphs/lists by escaping the stored HTML, so tags like <strong> will appear literally there. That's intentional; don't "fix" it by disabling escaping globally.
• Cleanup and navigation. Nova's SPA-style navigation previously leaked editor instances. If you have custom JS touching window.tinymce, guard with an existence check and don't hold references across page transitions; the field tears down its instance on navigate-away.
• CSP and self-hosting. If you serve assets locally behind a Content-Security-Policy, allow the published asset path, and be aware TinyMCE pulls skins/icons/CSS as separate requests — a partially-allowed path yields a mounted but unstyled editor.
• Extension point. If you need behaviour the field doesn't expose (custom buttons that mutate content, rendered detail HTML), subclass the field or ship a custom Vue detail component instead of patching vendor files — the field's save path reads the editor's current content, so out-of-band DOM edits need to go through the editor API.
• Upgrade risk is low. v1.2.2 is a patch: no breaking changes, no deprecations, no data migration. Validate on your Nova/Laravel versions (the release was tested against Nova 5 / Laravel 13) and do one manual pass over a form with a list and a paragraph to confirm detail rendering.