Nova Tinymce Field Laravel Package

Technical Evaluation

Architecture fit

• Ships as a standard Nova field: a PHP Field subclass plus a compiled Vue component that mounts TinyMCE against the field's value. That is a well-understood, low-surface integration model — no new tables, no migrations, no service provider magic beyond asset registration.
• Fit is conditional on Nova version. Nova is a paid, closed-source product, so compatibility must be verified against the specific Nova major in use (Nova 4 vs 5) rather than assumed from the README. This is the single largest gating question.
• Content is persisted as raw HTML in an existing column. That keeps the front-end rendering path unchanged and makes the field a drop-in replacement for a Textarea/Trix field, but it pushes all sanitization responsibility onto our application.
• TinyMCE itself is the real dependency. Self-hosted TinyMCE 6/7 is distributed under GPL-2.0-or-later (previously LGPL-2.1), which matters if we distribute the admin application or bundle assets commercially. If the field points at TinyMCE Cloud, we inherit an API key requirement and an external runtime dependency.

Integration feasibility

• composer require bythepixel/nova-tinymce-field plus a one-line field declaration in a Nova resource is the entire happy path. Expect roughly half a day to a working prototype for a developer already fluent in Nova.
• Real effort sits outside the field: HTML sanitization policy, media/file upload handling (TinyMCE's image and link plugins need an upload endpoint or they degrade to URL paste), and sanitizing/escaping on output.
• Because the integration surface is one field class plus one JS component, the fork cost is low. That materially de-risks the vendor decision — we can vendor or reimplement without a rewrite.

Technical risk

• Metadata integrity is the headline risk. The supplied sources are internally inconsistent: the package is a Nova rich-text field, yet the release note ("Fix: Incorrect Post Path") and the entire implementation-guidance document describe a post/slug routing package with route model binding, sitemaps, and 301 redirects. Those notes cannot be used to plan this integration. Treat them as unreliable and re-derive behavior from composer.json and the component source before committing.
• Adoption and maintenance. Zero stars, a 0.3 composite score, and a single release in April 2024 signals a single-maintainer, low-traffic project. There is no plausible support relationship here; plan for ownership transfer to us on day one.
• Security patch latency. The editor version is pinned inside the package's compiled assets. When TinyMCE ships a CVE fix, we get it only when the maintainer cuts a release — which the release cadence suggests may be slow.
• Stored XSS. HTML-typed content authored in admin and rendered on the public site is a classic stored-XSS vector. This is ours to solve regardless of what the package does.

Key questions

1. Which Nova majors does composer.json constrain, and does it support Nova 5? What are the PHP/Laravel minimums?
2. Which TinyMCE build and version is bundled — self-hosted, CDN, or Cloud with an API key? What is the license and the upgrade path?
3. Does the field sanitize on save, on output, or not at all? Is there any config surface for allowed tags?
4. Are file/image uploads supported, and if so against what endpoint? Or is it URL-paste only?
5. Is there a published config file, and are assets publishable to public/vendor?
6. Is there a test suite? How does the field render in index (read-only) and detail views, and is output escaped there?
7. What is the package's own license, and is the Vue component source shipped or only compiled?

Integration Approach

Stack fit

• Target is Laravel + Nova with PHP 8.1+ and Composer. The package slots in as a Nova field with no database footprint, which means it can be trialed on a single resource without schema changes or data migration.
• The only hard external coupling is to Nova's field API and to TinyMCE's asset pipeline. Both are well-documented and stable within a major version.

Migration path

• From an existing Nova Textarea or Trix field: effectively zero data migration, since both already store HTML. Swap the field declaration and verify a round-trip on an existing record.
• From a non-HTML format (Markdown) there is no automatic path; that would require a conversion step and is out of scope for a first rollout.
• Exit path if the package is abandoned: subclass the field in our own namespace immediately (App\Nova\Fields\RichText extends TinyMce) so resource declarations reference our class, not the vendor's. Swapping the implementation later then touches one file.

Compatibility

• Pin ^3.0.1. The changelog describes a targeted fix with (apparently) no new API surface, so there is no reason to accept an earlier 3.x.
• Explicitly test the Nova major and minor we run, plus the PHP version, in CI. Add a smoke test that renders a resource form and asserts the field component registers.
• Verify asset publishing: Nova fields that ship compiled JS must publish to public/vendor/<package> and be re-published on deploy. Confirm the deploy script covers nova:publish / vendor:publish.

Sequencing

1. Spike (1–2 days): install in a scratch branch, confirm Nova version compatibility, mount the field on a single resource, inspect the bundled TinyMCE version and license.
2. Decide the editor config contract: toolbar, plugins, allowed tags, and whether to route through TinyMCE Cloud. Publish and own the config file.
3. Sanitization layer (do this before any pilot): choose an allowlist-based sanitizer (e.g., HTMLPurifier) applied on save and defensively on render. Define the tag/attribute policy independently of the editor.
4. Media handling decision: either implement an upload endpoint for the image plugin or explicitly disable it and document URL-paste as the workflow.
5. Pilot on one content-heavy resource with a small author group. Capture editor-config complaints.
6. Roll out resource by resource; add the field subclass indirection at the same time.
7. Regression harness: a feature test that round-trips a record with representative HTML through the field and asserts persistence and rendering. Given the metadata inconsistencies, this is our only reliable source of truth.

Operational Impact

Maintenance

• Assume we own this. With a single release in April 2024 and negligible adoption, there is no realistic expectation of upstream responsiveness to a Nova 5 compatibility break or a TinyMCE CVE.
• Budget a recurring line item: one engineer-day per quarter to review upstream commits and TinyMCE advisories, plus the cost of patching or forking. If that budget isn't available, plan to reimplement the field in-house from the start — the work is small.
• TinyMCE upgrade cadence is decoupled from ours. If a security fix lands upstream, we may need to rebuild the compiled assets ourselves, which means we should retain a build path rather than depending on pre-compiled vendor JS.

Support

• Community-only: GitHub issues from a single maintainer. No SLA, no security disclosure process we can rely on.
• Internal support burden shifts to whoever owns the sanitization policy and the editor configuration. Document the config contract so content authors raise issues with us, not upstream.

Scaling

• Editor assets are admin-only and loaded per form page. Bundle size (TinyMCE is heavy) affects admin page weight and first-paint for editors on slow connections — a UX concern, not a throughput one.
• Content is stored as HTML blobs. Validate the column type (MEDIUMTEXT/LONGTEXT) against expected content size, and check MySQL max_allowed_packet if pasted base64 images are permitted — otherwise saves fail at scale.
• Serving HTML to the public site means the content benefits from existing page/HTTP caching; no new scaling surface there. If we add full-text search over the raw HTML, expect to index markup noise and plan to extract plain text.

Failure modes

• Stored XSS — malicious or pasted HTML rendered unescaped on the public site. Highest-severity, highest-likelihood failure. Mitigate with allowlist sanitization on save and escaped rendering.
• Silent content loss on save — invalid toolbar/plugin config can leave the editor uninitialized, and the field then submits an empty or stale value. Require a save-and-reload assertion in the regression test.
• Nova upgrade break — field stops rendering after a Nova minor bump with no upstream fix. Detection: CI smoke test on the resource form.
• Asset publish drift — stale compiled JS in public/vendor after deploy yields a blank editor. Mitigate via deploy-script enforcement and a cache-busted path check.
• CDN/TinyMCE Cloud outage — if configured against Cloud, the admin editor fails closed for all authors. Prefer self-hosting for resilience, subject to the licensing review.
• Sanitizer/editor mismatch — the editor allows tags the sanitizer strips (or vice versa), producing content that looks correct in admin but renders wrong publicly. Keep both policies in one documented place.

Ramp-up

• Developer ramp-up is short: roughly half a day for anyone conversant with Nova fields; the TinyMCE config API is widely known.
• Author ramp-up is near zero — it is a familiar WYSIWYG surface — but requires a short written note on the supported formatting set and the media workflow, since the toolbar is our configuration and can drift from expectations.
• The genuinely unfamiliar work is the sanitization and licensing review, which needs a security-minded reviewer rather than a Nova specialist. Schedule that before the pilot, not after.