Ckeditor Widget Bundle Laravel Package

Technical Evaluation

Architecture fit — poor. Despite being catalogued among Laravel/PHP packages, stinger/ckeditor-widget-bundle is a Symfony2 bundle, not a Laravel package. Its integration contract is Symfony-specific: a Bundle class registered in AppKernel, a DependencyInjection extension that merges configuration, service definitions, and (typically for this era) an Resources/public asset tree published via assets:install or Assetic. Laravel has no equivalent bundle lifecycle — no kernel registration, no automatic config merge, no Twig-by-default, no Assetic. Nothing about the package's PHP surface is reusable in a Laravel app. The only portable payload is the vendored CKEditor 4 "Widget" plugin (plugin.js, icons, dialog/CSS assets) plus whatever config.extraPlugins / allowedContent boilerplate the bundle sets.

Integration feasibility — feasible only as asset vendoring. We are not integrating a library; we are extracting static JS/CSS. That is a half-day of work and does not justify a Composer dependency. Real integration questions sit on the CKEditor side, not the Symfony side: Widget (CKEditor 4) requires nested editable regions and relies heavily on Advanced Content Filter configuration (allowedContent, extraAllowedContent), and misconfiguration causes silent markup stripping — a class of bug that looks like data loss to end users. If the product requirement is "WYSIWYG editing of structured custom content blocks," CKEditor 5's native block/widget architecture or a maintained editor (Tiptap, Lexical) is the better target; CKEditor 4 reached end-of-life in June 2023.

Technical risk — high, concentrated in abandonment and EOL.

• Unmaintained: 1 star, 0 dependents, no downstream users to surface regressions. Effectively single-author, last-touched in the Symfony 2 era (Symfony 2 itself EOL since 2018).
• PHP constraint: a Symfony2 bundle almost certainly declares php >=5.3 (or at best ^5.3|^7.0) and Symfony ~2.x requirements; Composer will refuse to install it alongside a modern Laravel (php ^8.1+, Symfony 6/7 components pulled in transitively). Conflict resolution would require --ignore-platform-reqs — an unacceptable signal in a production dependency graph.
• Security surface: no maintainer means no advisories, no patches. CKEditor 4 has a known XSS history; carrying an unpinned EOL editor into an authenticated admin UI is a finding our security review will raise.
• License: MPL-2.0 is file-level copyleft. Vendoring unmodified files is fine; any modification to those files obliges us to publish the modified source. Acceptable, but it must be registered in OSS compliance and tracked if we fork — which, given abandonment, is the likely outcome.

Key questions for the team:

1. What is the actual requirement — inline editing of custom content blocks, or generic rich text? (If generic, this entire package is irrelevant.)
2. Which CKEditor major version is in the product today, and is there an approved path off 4.x?
3. Is the bundle contributing anything beyond static assets — a data transformer, a form type, persistence hooks? (Almost certainly not, but confirm before dismissing.)
4. Who owns the editor integration long-term, and is a fork acceptable under MPL-2.0?
5. Does the "opportunity" signal (13.18) reflect demand for widget-style editing rather than for this package? If so, we should solve the requirement, not adopt the artifact.

Integration Approach

Stack fit — none at the framework layer. Treat this as a reference implementation to read, not a dependency to install. Concretely: clone the repo, diff its Resources/public against the upstream CKEditor 4 Widget plugin distribution, and take the plugin assets plus the configuration snippets. Do not add stinger/ckeditor-widget-bundle to composer.json; the platform requirements will not resolve and the Symfony wiring is dead weight.

Migration path (vendor, don't install):

1. Extract the Widget plugin asset tree into resources/js/vendor/ckeditor-widget/ (or public/vendor/), preserving MPL headers verbatim.
2. Register through Laravel's asset pipeline — Vite (or Mix on older apps) with explicit entry points; version filenames for cache-busting. Keep the plugin outside the app bundle so a future editor swap is a single import change.
3. Wire the editor via CKEDITOR.plugins.addExternal('widget', '/vendor/ckeditor-widget/', 'plugin.js') and config.extraPlugins = 'widget', then define widget templates and the matching allowedContent rules in one centralised, reviewed config module — not scattered across Blade views.
4. If server-side assistance is genuinely needed (e.g., sanitising widget HTML on save, rendering block templates), implement it as a thin first-party Laravel package: service provider, publishable config, a Blade component wrapping the editor, and a HTML sanitiser (e.g., mews/purifier) enforcing an allowlist that mirrors the editor's ACF. This is roughly 200–400 lines and is fully owned by us.

Compatibility. Pin CKEditor 4 to the final patched 4.x release and record it in the SBOM. Verify behaviour across the browsers we support; CKEditor 4's dialog/iframe internals are increasingly fragile under modern CSP — test with our production Content-Security-Policy early, since inline styles and unsafe-eval-adjacent patterns are common failure points.

Sequencing. (1) Two-day spike: read the bundle, confirm what it actually contributes, reproduce widget editing in a Laravel branch with vendored assets. (2) Decision gate: adopt vendored-assets-with-first-party-wrapper vs. re-platform to CKEditor 5 / Tiptap. (3) If we proceed with 4.x, build the sanitiser and ACF config before exposing to users. (4) Only after that, harden: CSP, XSS regression tests, upgrade note in the runbook.

Operational Impact

Maintenance — we inherit everything. No upstream commits, no issue triage, no releases. Budget an owner and a recurring review slot (at minimum quarterly) to check for CKEditor 4 advisories and browser regressions. MPL-2.0 means our fork's modified files must be made available; if we patch the plugin, publish the patch — cheap to comply with, expensive to discover late during diligence.

Support. Zero community: 1 star and 0 dependents means no Stack Overflow corpus, no third-party patches, no one else hitting our bugs. Internal documentation is the only support tier. Contrast this with a maintained editor where an upgrade path exists at all.

Scaling. Genuinely low risk: static assets only, no runtime server cost, CDN-friendly, no database or queue involvement. The scaling concern is not load, it is content volume — thousands of widget-bearing documents make any future editor migration a content-transformation project, not a code change. That cost compounds with every month of adoption, which argues for deciding the editor direction now rather than after rollout.

Failure modes to instrument:

• Silent ACF stripping corrupting saved markup — mitigate with server-side sanitise-and-diff on save, plus a fidelity test suite of representative documents.
• Plugin load-order or asset-path breakage on deploy — catch with a smoke test in CI that boots the editor headlessly and asserts the widget button renders.
• CSP violations blocking dialogs — assert in staging with production headers.
• If anyone does attempt to load the Symfony bundle: Composer platform conflicts and container-registration errors, which will read as opaque dependency failures. Pre-empt by documenting "do not install" in the ADR.
• Unpatched editor XSS in an authenticated admin surface — treat as a standing risk item with a named acceptor.

Ramp-up. Low for the asset extraction (hours); moderate for the parts that actually matter — CKEditor 4's widget API, nested editable regions, and ACF semantics constitute roughly one to two developer-weeks to reach productive proficiency, and that knowledge is scarce and depreciating. Recommend a single named owner rather than spreading it across the team, and capture the config decisions in writing so the knowledge does not leave with them.

Bottom line. The package is not the asset; the underlying CKEditor plugin is. Recommend reject as a dependency, evaluate as a reference — vendor the assets under a first-party wrapper, and run the re-platform decision in parallel, because the real cost here is the EOL editor we would be adopting along with it.