Nova Ckeditor Laravel Package

Product Decisions This Supports

• Whether to put rich-text authoring in the admin at all. This package answers one narrow question: do we need a WYSIWYG field inside Laravel Nova resource forms for blog bodies, help-center articles, policy docs, product descriptions, or internal comms? If yes, and Nova is already the admin backbone, it is a plausible accelerator. If the content problem is customer-facing authoring, workflow, or publishing, this is not the tool and the decision is really about a CMS.

• Build vs. buy for editor plumbing. "Buy" here means adopting a thin MIT-licensed wrapper instead of owning the Nova field class, asset publishing, upload wiring, toolbar config, and CKEditor 5 bundling ourselves. That is a defensible tactical shortcut for a two-week win; it is not defensible as a platform commitment at 58 stars, zero dependents, and a single maintainer.

• Roadmap sequencing for content operations. Shipping admin-side authoring now lets us defer a full CMS, editorial approval workflows, and DAM/media investment until usage data justifies them. The package supports a "prove demand in the admin panel first" sequence rather than a big-bang content platform build.

• Admin UX investment for non-technical operators. The measurable benefit is fewer developer requests for formatting, links, and embedded media in Nova-managed records. Frame this as support-cost and cycle-time reduction, not as a feature checkbox.

• Content portability as an architecture constraint. Storing portable HTML in longText columns — not an editor-proprietary JSON blob — is what keeps us free to swap the package, fork it, or retreat to a Textarea. That is a PM-level call with long-tail consequences and belongs in the acceptance criteria, alongside longText rather than text in the migration.

• Dependency and licensing risk acceptance. Two separate licensing questions must be resolved before production. The package is MIT; the CKEditor 5 build it ships carries its own terms (GPL, or commercial for commercial builds and premium plugins). Collaboration, comments, and track changes are commercial CKEditor features this field does not provide — if stakeholders assume we are getting those, that expectation needs correcting now.

• Framework upgrade planning. Release 7.9.0 tracks Laravel 13, so this is not an obvious blocker for the next upgrade. Caveat: that support landed via a single external contributor PR — treat it as unverified until our own staging run confirms it, and bump the package in the same PR as the framework bump.

• Standardization vs. bounded pilot. Every Nova resource can chain its own field options, which invites drift: two fields that look identical to an editor can store different HTML. The decision is whether this becomes a supported, centrally-configured pattern (one factory method) or stays a bounded pilot with a written fallback to Textarea.

When to Consider This Package

Consider it when:

• The product already runs Laravel Nova, and the need is a CKEditor 5 field inside Nova resource forms — not a customer-facing or public-facing editor.
• The scope is internal admin authoring, where a broken editor is an inconvenience rather than a customer-visible outage.
• We are on, or planning, Laravel 12/13, which lowers the odds of being stranded by the next framework upgrade — subject to our own staging verification.
• The team can pin the version, review upgrades, and isolate configuration behind a single factory helper, so a low-adoption dependency does not spread across ten resources and become expensive to remove.
• The realistic frame is a time-boxed spike: one content field on one low-risk resource, fileManager(false), no uploads, prove save → persist → render → re-edit round-trips, then expand.
• CKEditor 5 licensing has been confirmed compatible with our distribution model, and Nova's own licensing costs are already accounted for.
• A fallback is written down and accepted — portable HTML in the database, the field behind a factory, and a credible path back to Textarea or a self-maintained fork if the maintainer disappears or a Nova major breaks it.

Look elsewhere when:

• We need collaboration, comments, track changes, or approval workflows — those are commercial CKEditor features this field does not ship.
• We need custom CKEditor plugins. That requires rebuilding and republishing the CKEditor 5 bundle — a standing frontend build obligation nobody currently owns. If that is on the roadmap, plan for it or choose differently.
• We need a customer-facing editor, headless/API-first content, or a multi-channel publishing model. This is an admin form field, not a content platform.
• The team cannot enforce sanitization on write. The field persists whatever HTML the browser sends; without an HTML purifier and an explicit tag/attribute allowlist from day one, retrofitting onto published content is far more expensive than starting clean.
• The environment has a strict CSP with no appetite for relaxing it (style-src 'unsafe-inline', asset origin in script-src, upload domain in img-src). The editor will render blank and the cause is easy to misdiagnose.
• The organization needs vendor support or a maintenance contract. There is none here.

How to Pitch It (Stakeholders)

For executives: We can give non-technical operators rich-text editing inside the admin panel we already run, in days rather than weeks, without committing to a CMS. It is a small, MIT-licensed wrapper around CKEditor 5 — cheap to try, cheap to reverse, because content is stored as plain portable HTML rather than anything editor-specific. The risks are honest and bounded: a single-maintainer dependency with almost no adoption, and a separate CKEditor 5 licensing question we must resolve before production. Recommendation: approve a two-week spike on one low-risk resource, with an explicit go/no-go gate and a documented fallback to a plain textarea.

For engineering: This is a Nova field that wraps CKEditor 5 and handles asset publishing, uploads, toolbar config, and localization. Treat it as a tactical dependency, not a platform bet. Non-negotiables: version-pin and bump alongside framework upgrades (7.9.0's Laravel 13 support is unverified on our codebase); centralize field construction in a one-line factory so adoption stays reversible; use longText, never text; run all HTML through a purifier on write and at render; decide the upload policy — disk, path namespacing, MIME allowlist enforced server-side, size cap — before enabling the file manager; put storage:link and asset re-publishing in the deploy script, because stale bundles fail silently. Validate at the HTTP layer (post HTML, assert persistence, assert the sanitizer strips <script>) rather than with brittle browser tests. Write down the exit plan: portable HTML plus a single factory means swapping to Textarea or a fork is a one-method change.