Nova Ckeditor5 Classic Laravel Package

Product Decisions This Supports

• Feature scoping for admin-side authoring. This package answers a narrow but recurring question: do we give non-technical editors a WYSIWYG surface inside Laravel Nova, or do we keep forcing Markdown/plain textarea and push rich content into a separate CMS? It is the cheapest possible "yes" to rich text in the admin panel.
• Build vs. buy at the field level. A Nova field is a small, well-bounded artifact — a PHP Field class plus a Vue component. Adopting this package is a "borrow" decision that trades roughly one sprint of build time for inherited maintenance and a dependency you don't control.
• Roadmap: internal tooling vs. content platform. If the roadmap includes a real content platform (headless CMS, structured content, editorial workflows, localization), adopting a field-level editor now can create a migration liability later — content gets authored as opaque HTML blobs rather than structured data.
• Editor standardization. Choosing CKEditor 5 here influences what you use customer-facing, because output HTML fidelity, sanitization policy, and paste behavior should match across surfaces. This package is a commitment to CKEditor 5's HTML dialect in at least one part of the product.
• Nova upgrade planning. Because the package is archived, it is an explicit constraint on your Nova upgrade path — a decision input for "when do we move to Nova 4/5 and what breaks."
• Primary use cases: internal admin CRUD for blog posts, product descriptions, email/notification templates, help-center articles, and any Nova resource where a plain textarea produces poor editor experience for marketing or ops staff.

When to Consider This Package

Consider it when:

• You are on the Laravel Nova version contemporary with its last release (early 2021, Nova 3.x-era, Vue 2 field API) and are not planning a Nova upgrade in the next 1–2 quarters.
• You specifically want CKEditor 5 Classic — its toolbar model, plugin ecosystem, and HTML output — rather than a generic rich-text field.
• The consumer is an internal, low-blast-radius admin with a handful of editors, not a customer-facing surface.
• You are willing to fork it. MIT licensing means you can vendor it, pin dependencies, and patch it yourself; treat adoption as "we now own this code."
• You already have, or are willing to buy, a CKEditor 5 commercial license or have reviewed the GPL implications of shipping CKEditor 5's JavaScript in your admin bundle.

Look elsewhere when:

• You are on Nova 4 or 5 — the field API and front-end tooling changed substantially, and an archived Vue 2 component should be expected to break.
• You require maintained dependencies, security patching, or a support channel. Last release was January 2021 and the repo is archived; there is no upstream fix path.
• You need file/image upload adapters, RTL and multi-language editing, real-time collaboration, or configurable sanitization — the wrapper is thin and will not have kept pace with CKEditor 5 releases.
• Your organization has compliance review over GPL-licensed front-end assets; this needs a legal answer before a technical one.
• You are not on Laravel Nova at all, or you are already leaning toward structured/headless content, where a rich-text field is the wrong abstraction.

How to Pitch It (Stakeholders)

To executives: This is a small, tactical accelerator, not a platform bet. It gives our Nova admin a professional rich-text editor for roughly a sprint less work than building one, at zero license cost (MIT). The catch is that the project is archived and unmaintained — so the real ask is not "adopt a package" but "accept a small piece of permanent internal ownership." That is a reasonable trade for internal tooling and a poor one for anything customer-facing. Frame the decision as: spend one sprint now to save one sprint, and carry a modest maintenance line item thereafter, or skip it and use Nova's built-in Markdown field until we have a real content-platform requirement.

To engineering: It is a thin Vue wrapper around CKEditor 5 Classic plus a Nova Field subclass. Treat it as a fork, not a dependency: vendor the source, pin the CKEditor 5 version, and budget one to two days to validate it against our exact Nova version before committing. Non-negotiables — sanitize the HTML server-side on save and render (never trust editor output), confirm the CKEditor 5 licensing posture before it ships, and write down the exit plan (replace with an in-house field) so the fork never becomes load-bearing without a decision. If validation exceeds two days, stop and build the field ourselves; it is a few hundred lines and we would own it either way.