Redactor Bundle Laravel Package

Technical Evaluation

Architecture fit: mismatched at the premise, and the framing needs correcting before any planning happens. kraksoft/redactor-bundle is a Symfony2 bundle, not a Laravel package. Laravel consumes individual Symfony components (HttpFoundation, Routing, Console), but it has no Bundle, Kernel, or DI-Extension system, so a bundle cannot be composer required into a Laravel app and registered. What the package actually contains is thin glue — a bundle class, a DI extension with a config tree, asset publishing for the Redactor JS/CSS, and a Twig form type/theme (roughly a couple hundred lines). None of that glue survives the ecosystem boundary. Only the client-side editor assets would, and those are not really this package's value — they belong to Imperavi's Redactor, which is commercially licensed separately and almost certainly not distributed here.

Integration feasibility: effectively zero as a dependency. Expect symfony/symfony ~2.x and a PHP 5.x constraint, which hard-conflicts with any Laravel 9/10/11 or Symfony 4+ install on PHP 8.x. Symfony 2 reached end-of-life in 2018. Realistic options, in order of preference:

1. Do not adopt. Drop Redactor assets into resources/js/vendor/ and wire manually — if the editor is even still wanted.
2. Fork and port the glue into an internal Laravel package (service provider, publishable config, Blade component, upload endpoint) or into a modern Symfony bundle.
3. Run a separate Symfony app to host the bundle — not justified for a WYSIWYG field.

Technical risk: high, dominated by abandonment rather than active threat. The signal is unambiguous — 3 stars, 0 dependents, composite score 0.015, opportunity score 1.34. This is a 2013–2014-era artifact with no user base to surface regressions, so every defect is discovered by us first. Specific exposures:

• Supply chain: low direct risk (nobody is attacking a three-star repo), but zero downstream validation is its own risk.
• Runtime: PHP 8 fatals, deprecated Symfony APIs, jQuery-era assumptions that clash with a Vite/Tailwind/Livewire front end.
• Licensing: the true commitment is a paid Imperavi contract plus asset placement — a procurement task, not a composer require.
• Content security: the bundle does nothing about sanitization, XSS, or upload validation. Those are ours to build regardless of editor.

Key questions to resolve before funding any work:

• Is Redactor itself still licensed and supported by Imperavi at a version we can run, and at what cost per seat/domain?
• Is there a product requirement for Redactor specifically, or simply "a rich-text field"? If the latter, this package is irrelevant.
• Do we need server-side HTML sanitization, image/file uploads, or a media library? (The bundle provides none.)
• Who owns the fork if we port it, and what is the exit plan when Imperavi changes licensing terms?
• Does our CSP forbid inline scripts or unsafe-eval, which older editors require to mount?

Integration Approach

Stack fit: incompatible at the framework layer, plausible at the asset layer. Laravel's form and Blade layer has no analogue to Symfony's AbstractType + form theme. A port means a Blade component (<x-redactor name="body" />), a publishable config file, an asset push, and a validation/sanitization rule. That is a small, self-contained build — a few days — but it is a new internal package, not an integration of this one. The same logic applies in reverse for a Symfony 4+/6/7 app.

Migration path (recommended): extract, don't depend.

1. Treat kraksoft/redactor-bundle as reference documentation only — read the config tree and form-type wiring to learn which Redactor options were exposed and which defaults matter.
2. Vendor the Redactor distribution (per Imperavi license) into resources/js/vendor/redactor/ and load it through Vite, not assets:install into web/.
3. If Redactor is mandated, build internal/laravel-redactor: service provider, publishable config, Blade component, an upload controller behind auth + policy, and a sanitizer pipeline (HTMLPurifier / mews/purifier) applied on save and render.
4. If Redactor is not mandated, skip 2–3 and evaluate TipTap, CKEditor 5, TinyMCE, or Lexical — maintained, framework-agnostic, with existing community wrappers.

Compatibility: assume Composer refuses the install outright. Do not plan around a fork unless you also accept owning PHP 8 support, constraint widening, and asset-pipeline modernization. The fork surface is small enough to be feasible, but it buys you nothing over a clean-room wrapper.

Sequencing:

1. Week 0 — product and licensing gate. Confirm the editor requirement and the licensing budget. Everything downstream is wasted if the answer is "any rich-text field."
2. Week 1 — throwaway spike. One Blade view, vendored assets, verify CSP compatibility, jQuery-free operation, mobile behavior.
3. Week 2 — security spike. Sanitization round-trip, upload endpoint with type/size checks, stored-XSS test cases.
4. Weeks 3–4 — internal package. Provider, config, component, tests, docs, runbook ownership.
5. Rollout: feature-flag one low-traffic form, measure, then widen.

Operational Impact

Maintenance: we become the maintainer. Upstream is dormant — no PHP 8.3/8.4 fixes, no constraint updates, no security advisories. Budget a standing line item (~1–2 engineer-days per quarter) for the internal wrapper plus the cost of tracking Imperavi releases. If the bundle is installed directly instead of ported, the first composer update on a modern stack breaks the build — that is a near-certainty, not a risk.

Support: none from the package. Purchased Redactor support covers the editor only, never the Symfony glue and never our Laravel layer. Internal runbook and on-call ownership must be assigned before rollout, not after the first production incident.

Scaling: the editor is client-side; server cost is dominated by media uploads and storage, not by the editor itself. If uploads are in scope, plan object storage (S3), image resizing, per-user quotas, and CDN delivery from day one — retrofitting these post-adoption is the expensive path. Sanitization on render adds per-page CPU; cache sanitized HTML rather than re-purifying on every request.

Failure modes to design against:

• Composer resolution failure on upgrade (if installed as a dependency) — blocks all deploys.
• PHP 8 fatals in legacy syntax — silent until a specific form is hit.
• jQuery global collisions with Livewire/Alpine/modern bundles.
• CSP violations from inline init scripts; the editor silently fails to mount.
• Stored XSS from unsanitized rich-text content — highest severity, and the most likely outcome if we treat this package as "the integration."
• Editor abandonment by Imperavi — mitigated by storing semantic HTML, not editor-specific JSON blobs, so a future swap is a render-layer change.
• License lapse — legal exposure on a public-facing property.

Ramp-up: trivial to demo (an afternoon), moderate to productionize (2–4 weeks including sanitization, uploads, tests, docs). The demo-to-production gap is exactly where this package's 0.015 score becomes a real cost: none of the hardening exists upstream, so all of it lands on us.

TPM recommendation: reject as a dependency; use it as a design reference at most. Leverage it in three narrow ways — as a calibration example for dependency-gating thresholds, as a triage input for any inherited Symfony2 application still running it (pin the commit, vendor the glue, freeze it), and as documentation of which editor options were historically exposed if we ever need parity. If rich text is a genuine requirement, fund a 3–4 week internal wrapper or adopt a maintained framework-agnostic editor, and scope sanitization plus upload security as first-class work rather than follow-up tickets.