Nova Trumbowyg Laravel Package

Technical Evaluation

Architecture fit. alfonsobries/nova-trumbowyg is a classic Laravel Nova custom-field package: a PHP Field subclass (extending Laravel\Nova\Fields\Field) plus a compiled Vue component registered through Nova::script()/Nova::style() in a package service provider. It wraps Trumbowyg, a jQuery-based lightweight WYSIWYG editor, and persists editor output as raw HTML into a standard string/text column. For a codebase on Nova 1.x (circa 2018), this is architecturally idiomatic — it slots into the existing fields() method with no changes to models, migrations, or API layers. For any team on Nova 3.x or 4.x/5.x, the field component contract, asset-registration surface, and Vue major version have all shifted, and this package is not forward-compatible.

Integration feasibility. Composer-installable from Packagist, MIT-licensed, no native extensions. On a matching Nova 1.x install, integration is a composer require, vendor:publish of assets, and a one-line field declaration — hours, not days. The constraint is that it is archived as of the 2018-08-25 release, meaning there is no Nova 2/3/4 support, no Vue 3 / Inertia adaptation, and no jQuery version bump. Realistically the integration effort on a modern stack is a fork and port project, not a package adoption. Feasibility is therefore bifurcated: trivial on legacy Nova, non-trivial (but straightforward for a competent Laravel dev) as a from-scratch replacement on current Nova.

Technical risk. High, concentrated in three areas:

• Unmaintained dependency chain. Trumbowyg + jQuery from 2018 carries known CVEs in that era of jQuery (prototype pollution, XSS via .htmlPrefilter), with no patch path short of forking.
• XSS surface. The field stores and re-renders raw HTML with no sanitization in the package. Any user with field-write access can inject script into the admin UI and, depending on rendering context, the public site.
• Bus factor. 13 stars, single maintainer, archived — zero upstream security response, zero compatibility fixes, no test suite to validate a fork.

Key questions to resolve before committing:

• Which Nova major version is in production, and is a Nova upgrade on the 12–18 month roadmap?
• Is editor output treated as trusted (admin-only authors) or untrusted (multi-tenant, customer-facing)?
• Do we need image upload, embed, or paste-from-Word beyond Trumbowyg core, and who owns the upload endpoint?
• Accessibility (WCAG 2.x) obligations — Trumbowyg's 2018 build has not been audited.
• Who owns the fork long-term, and is a maintained alternative (TipTap, TinyMCE, Nova's Markdown field) a cheaper path than porting?

Integration Approach

Stack fit. Correct fit only for Laravel + Nova 1.x. The field maps cleanly to a text column and requires no model casts beyond optional HTML handling. It assumes jQuery is available in the Nova admin bundle; conflicts are possible if other Nova packages ship incompatible jQuery versions. No backend service, queue, or infrastructure dependency is introduced — it is purely an admin-UI concern.

Migration path. Two viable routes:

1. Legacy-compatible adoption — install as-is on Nova 1.x, pin the commit, vendor the published assets into the repo so builds are reproducible, and treat the package as frozen source under our control.
2. Fork-and-port — fork the repo, upgrade the Vue component to the target Nova field contract (Vue 2 → Vue 3 / Inertia for Nova 4+), and replace Trumbowyg with a maintained editor rather than porting jQuery forward. This is the recommended route for anything on Nova 3+, and it changes the work from "adopt a package" to "build a field," which should be scoped and resourced accordingly.

Compatibility. PHP 7.x-era package; verify against the target PHP runtime (8.x strictness on dynamic properties and null handling is a common break point). Composer constraints will likely need loosening in the fork. Asset publishing must be re-validated after every Nova minor upgrade, since Nova's asset pipeline is the usual breakage point.

Sequencing.

1. Confirm Nova version and editor feature requirements.
2. Spike a 1–2 day fork build against a staging Nova instance to measure port effort.
3. Decide adopt vs. build; if build, evaluate maintained editors in parallel.
4. Land sanitization (HTMLPurifier / mews/purifier) before any content is authored through the field — this must not be deferred.
5. Backfill/sanitize any existing HTML columns written by the legacy editor.
6. Ship behind a feature flag on one content type before broad rollout.

Operational Impact

Maintenance. Effectively 100% internal ownership from day one. Archived status means every upstream fix is ours to write: Nova compatibility, editor security patches, dependency bumps. Budget an ongoing tax of roughly 1–2 engineering days per quarter for the fork, plus a larger spike on each Nova major upgrade. The MIT license makes forking legally clean — this is the package's single biggest mitigating factor.

Support. No vendor, no maintainer, no issue triage. Support is limited to internal expertise and community channels (Laravel Nova Discord, Stack Overflow). Any production incident traces to a one-person 2018 codebase with no test coverage, so mean-time-to-diagnosis is on us.

Scaling. The field itself does not scale horizontally in any interesting way — it is admin-side rendering and a text column. The real scaling concerns are content volume (large HTML blobs in list/detail views inflate admin payloads; consider truncation in index views) and sanitization throughput if HTML is purified on every save or render. Media uploads are not provided out of the box and require a bespoke endpoint, storage policy, and virus/type validation — a nontrivial add-on often underestimated in scoping.

Failure modes to instrument for:

• XSS injection via unsanitized HTML — highest severity; mitigate with server-side purification and a strict CSP.
• Silent asset-publish breakage after a Nova upgrade — field renders as a bare textarea or blank; add a smoke test in the admin CI suite.
• jQuery conflict with other Nova packages — duplicated jQuery loads or version mismatch; detect via console errors in staging.
• Data corruption on save if the editor normalizes HTML differently than expected — snapshot original content before first write.
• jQuery/Trumbowyg CVE exposure — no patch path; track and treat as accepted risk with compensating controls (admin-only access, CSP).

Ramp-up. Installation and first-field wiring: hours for any Laravel developer. Understanding the fork, porting to modern Nova, and building sanitization plus upload handling: 1–2 sprints. The low friction of the happy path is precisely the trap — the package's high "opportunity" score reflects cheap trial, not cheap long-term ownership. Recommend adopting only if the team is on Nova 1.x and accepts the fork obligation; otherwise, treat this package as a reference implementation and build on a maintained editor instead.