Nova Ckeditor4 Field Translatable Laravel Package

Technical Evaluation

Architecture fit

yeswedev/nova-ckeditor4-field-translatable is a Nova field package, not a general Laravel package. Its entire value surface is a Vue component registered as a Nova field plus a PHP field class that hands rendered HTML to the model. That makes fit binary and narrow:

• Applicable only if the target application is on Laravel Nova and needs a WYSIWYG for one or more translatable text attributes (e.g., title, body, description per locale).
• Not applicable to Blade/Livewire/Inertia-based admin panels, Filament, or public-facing forms. There is no reusable service, facade, or storage layer to salvage — the CKEditor integration is entangled with Nova's field lifecycle.
• Translatability is the differentiating claim, but it is a thin wrapper over an existing translation mechanism (Nova's native translatable field, nova-translatable, or spatie/laravel-translatable). That means the package's real dependency graph is Nova + CKEditor 4 + a translation package, three independent upgrade cadences the TPM inherits.

Integration feasibility

Integration is mechanically simple — composer require, register in NovaServiceProvider::fields(), php artisan vendor:publish for assets, then swap Text::make() for the new field. Estimate half a day for a working spike in a single resource.

The blockers are not mechanical:

1. CKEditor 4 end-of-life. CKEditor 4 is out of active development; the vendor's extended/LTS security program has a finite horizon (currently targeted at end-2026). Adopting it in 2025 means shipping a component with a known expiry date baked into the editor layer.
2. Licensing. CKEditor 4 ships under GPL/LGPL/MPL for open source. Embedding it in a proprietary admin panel without a commercial license is a legal question that must be answered by counsel, not by the package README. This package almost certainly does not carry a commercial CKEditor license, so the obligation passes to you.
3. Nova version coupling. Nova 4 → Nova 5 (Inertia/Vue 3) broke a large fraction of field packages. With zero stars and zero dependents, there is no crowd-sourced evidence that this package was updated. The composer.json laravel/nova constraint is the single most important artifact to read before anything else.

Technical risk

Key questions to resolve before any commitment

• What are the exact composer.json constraints for laravel/nova, php, and the translation package? Does it support Nova 4, Nova 5, or both?
• Is CKEditor 4 loaded from a bundled/published asset, a CDN, or a configurable path? CDN loading conflicts with strict CSP and creates an availability dependency.
• Does the package perform any server-side sanitization, or does it persist raw HTML verbatim?
• Which translation contract does it implement — Nova native, nova-translatable, or Spatie — and does it handle per-locale dirty state (unsaved edits when switching locale tabs)?
• Is there any image/file upload integration, or is it text-only?
• What is the license of the package itself, and does it purport to license CKEditor 4?
• When was the last commit, and is the Framagit repo public and issue-enabled?

Integration Approach

Stack fit

Verdict: conditional reject as a dependency; accept as a fork-and-own candidate given the score of 0 and no dependents.

• If the app is on Nova 4 or 5 and translatable rich text is a genuine product requirement, the capability fits. The package does not, at this maturity level.
• If the app is not on Nova, close the evaluation here — the effort is better spent on a first-party editor integration.

Recommended stack position: treat the repo as a reference implementation for the PHP field class + Vue component, copy it into nova-components/ as an in-house field, and take direct ownership of the CKEditor dependency and the sanitization layer.

Migration path

1. Read the source first. Clone from Framagit, diff against the Nova field API for your Nova version, confirm the translation contract and the asset-loading strategy. This is a 2–4 hour review, not a spike.
2. Vendor it. Rather than composer require from Framagit (which pins you to a Git VCS repository with no tag guarantees), copy the field into a local nova-components/rich-text-translatable package under your own namespace and CI. This converts an abandoned dependency into maintained first-party code.
3. Sanitize on write. Wrap the field's fill/resolve with an HTMLPurifier policy (allowed tags, allowed attributes, rel="noopener" on links). Never trust the editor's client-side filtering.
4. Plan the editor exit. If CKEditor 4 is required for editorial familiarity or legacy content, isolate it behind your own component so swapping to CKEditor 5, TipTap, or Lexical later is a single-component change rather than a data migration.

Compatibility

• Confirm Nova major version and Vue version before writing any code; Nova 5's Vue 3 shift is the most likely failure point.
• Confirm PHP version against the field class (typed properties, return types) and against HTMLPurifier.
• Confirm the translation package version matrix; a three-way pin (Nova × translation × editor) is where upgrade friction concentrates.
• Check that published assets are versioned and fingerprinted; unversioned vendor/ publishes cause stale-editor bugs after deploys.

Sequencing

1. Source review + license opinion (legal) — gate 1
2. Branch spike: one resource, one translatable attribute, one locale pair — gate 2
3. Sanitization policy + tests for stored-XSS vectors — gate 3
4. Rollout to all rich-text resources behind a feature flag; keep the old Text/Textarea field code path until editorial sign-off
5. Document the owned fork: upgrade runbook, CKEditor 4 EOL date, and the migration trigger to CKEditor 5

If any gate fails, the fallback is a plain markdown/textarea field plus server-side rendering — cheaper than owning an EOL editor.

Operational Impact

Maintenance

This package is maintenance-negative out of the box. With no stars, no dependents, and a Framagit-only presence, you should assume the effective maintainer count is zero and plan for the fork in step 2 of the integration approach. Budget roughly 2–5 engineer-days per year for dependency bumps (Nova major, PHP minor, PHPUnit/HtmlPurifier) plus reactive work when Nova ships breaking changes. The CKEditor 4 EOL horizon means a mandatory editor migration project inside 12–24 months — that is a real line item, not a risk footnote.

Support

No commercial support, no SLA, no security disclosure process on the repo. Internal support burden lands on whoever owns Nova. Editor behavior questions ("paste from Word breaks formatting," "image upload doesn't work") will come from content editors to your team, not to an upstream maintainer. Set expectations with the editorial team early; a short internal FAQ reduces ticket volume more than any code change.

Scaling

Backend impact is negligible — the editor is client-side, and the persistence path is an HTML string into an existing column. The scaling concerns are elsewhere:

• Payload size. Rich-text HTML inflates rows substantially. Watch LONGTEXT usage, replication lag on large updates, and full-row SELECT * patterns.
• Search. HTML in the DB defeats plain LIKE/full-text search. If translated content must be searchable, plan a stripped-text projection column or an external index (Meilisearch/Scout) at the same time as adoption — retrofitting it later is a backfill.
• API surface. If the same content is served via JSON to a front end, sanitization must happen on the way out too, or you are trusting stored state.
• Asset delivery. Published editor assets add ~1–2 MB to the admin bundle; keep them off public-facing routes.

Failure modes

Ramp-up

• Developers: Low-to-moderate. The field API is familiar; the cost is the source review and the sanitization work, not the integration. Half a day for a Nova-fluent engineer to a working spike, plus 1–2 days for hardening and tests.
• Content editors: Low. CKEditor 4's toolbar is widely recognized and is arguably its strongest argument over CKEditor 5 or a markdown field.
• Ops: Low. One publish step, one asset path, no new services.

Recommendation

Adopt only as a vendored, first-party Nova field with server-side sanitization and a documented CKEditor 4 exit plan. Do not add it as a VCS composer require dependency. If the team cannot commit to owning the fork and the editor migration, prefer a maintained alternative (a CKEditor 5 Nova field, a TipTap-based field, or a plain translatable textarea) — the capability is cheap to re-source; the EOL editor is not.