Nova Tinymce Laravel Package

Product Decisions This Supports

• Rich-text authoring inside Nova: Decides whether content editors (marketing, support, catalog) can draft and format HTML directly in the admin instead of asking engineering for copy changes.
• Build vs. buy for WYSIWYG: A thin Nova field integration that saves the custom-field work of wiring TinyMCE, toolbar options, and inline image upload. The build alternative is a bespoke Nova field plus media endpoint.
• Content operations roadmap: Helps choose between extending Nova as a lightweight CMS versus investing in a dedicated/headless CMS. This package is appropriate for low-volume, internal authoring; it is not a content-platform strategy.
• Media handling policy: Forces decisions on where inline images are stored (local disk vs. S3), who can upload, file size/type limits, retention, and whether images need transforms/CDN delivery.
• Feature scoping: Useful for admin-only capabilities such as blog drafts, product descriptions, email templates, help-center articles, and internal documentation — not customer-facing page builders or collaborative editing.
• Risk posture: With 3 stars and 0 dependents, adopting it is a tactical, reversible decision rather than a platform commitment; plan to vendor/fork if the feature proves valuable. v2.3.2 is the minimum acceptable version — earlier releases register assets under capitalised names that 404 on hosts or middleware that lowercase URLs, which silently kills every Nova form using the field (saves fail client-side with no server-side error).
• Operational debuggability: The v2.3.2 incident is a reminder that this field can fail entirely in the browser without a request ever reaching the app. Budget for client-side verification (console checks, an end-to-end "can an editor save?" smoke test) as part of rollout, not just server-side monitoring.

When to Consider This Package

Consider it when:

• The product already runs Laravel Nova and the team wants TinyMCE specifically — familiar editor UX, configurable toolbar/plugins, paste behavior — rather than Nova’s default Trix or Markdown fields.
• The authoring audience is small and internal, content is stored as HTML in a text column, and a few days of integration effort matters more than long-term vendor support.
• Inline image upload to the application server is acceptable, with the team able to add validation, authorization, storage configuration, and HTML sanitization around it.
• The team is willing to pin the version (v2.3.2 or later), review the source, and own maintenance — there is no meaningful community safety net at this adoption level.

Look elsewhere when:

• You need an SLA, security review artifacts, enterprise support, or a maintained package with a dependent ecosystem.
• Requirements include multi-tenant media isolation, image transformations/CDN, collaborative editing, versioning, or strict content sanitization guarantees.
• TinyMCE premium plugins or TinyMCE Cloud are required; those are separate commercial decisions even though the package itself is MIT.
• Nova’s native field or a more actively maintained Nova editor package satisfies the need with less supply-chain risk.
• The content is customer-facing or regulatory-sensitive; a low-adoption admin package should not become the control point for public content integrity.
• Your delivery path normalises URL case (SEO/canonicalisation middleware, some CDNs and proxies, certain managed hosts). On such stacks the pre-2.3.2 failure mode is total and silent; only adopt on v2.3.2+ and verify a save end-to-end before wider rollout.

How to Pitch It (Stakeholders)

Executives: This is a low-cost, MIT-licensed add-on that gives editors a familiar Word-like writing experience inside our existing Nova admin, including inline image upload. It can reduce engineering interruptions for copy changes and improve content velocity without buying a new CMS. The trade-off is maturity: tiny adoption and a single-maintainer profile mean we should pilot it for one internal content type, not make it a platform dependency. The latest patch (v2.3.2) fixes a defect that silently broke all admin form saves on hosts that lowercase URLs — a good signal the maintainer is responsive, and a reminder to pin versions and smoke-test saving. Success looks like editor adoption, fewer copy-change tickets, and no security or upgrade incidents.

Engineering: The integration surface is small — a Nova field wrapper around TinyMCE plus an image upload path. Install v2.3.2 or later; earlier versions register the Nova-TinyMCE assets under capitalised names, which 404 when a host, CDN, or middleware (e.g. SEO canonicalisation 301s) lowercases URLs, leaving the Vue component unregistered and every affected form failing on submit with TypeError: t.fill is not a function — with no server-side request or log line. The upgrade is drop-in: only the three asset names changed; component names and the $component contract with the built dist/ bundle are untouched. Beyond that, harden the upload endpoint (auth, MIME/size validation, storage disk, filename handling), sanitize stored HTML on render, pin the package version, and add tests covering field configuration, media cleanup, and an end-to-end "editor can save the form" check to catch client-side-only failures. Because there are no dependents, budget for forking or wrapping the package if Nova upgrades break it. Estimate: hours to integrate, a few days to harden, document, and add the save smoke test.

Recommendation: Run a time-boxed pilot on one low-risk content type, on v2.3.2+, with an end-to-end save test in CI. Measure author adoption, support tickets, and maintenance effort. Revisit the build-vs-buy decision if content volume, compliance requirements, media complexity, or repeated silent-failure classes outgrow what a small Nova field can safely support.