Redactor Bundle Laravel Package

Product Decisions This Supports

• Corrects a framing error before it costs us: kraksoft/redactor-bundle is a Symfony2 bundle, not a Laravel package. There is no service provider, facade, or config publishing, so it cannot be composer required into a Laravel app — the expected "quick win" of a drop-in rich-text field does not exist. Any roadmap item or backlog ticket assuming Laravel compatibility should be closed rather than estimated.
• Reframes "adopt a package" as "buy a license + own an integration": the bundle is thin glue around Redactor, a commercial WYSIWYG editor from Imperavi that is not bundled here. The real decision is a vendor contract, a procurement cycle, and bespoke integration code we alone would maintain — not a Composer dependency decision.
• Editor "build vs. buy vs. assemble" call: supports converging on a maintained, framework-agnostic editor (TipTap/ProseMirror, Lexical, Quill, CKEditor 5, TinyMCE) shipped through our standard asset pipeline, with content stored as semantic HTML/JSON rather than editor-specific blobs. That keeps the choice reversible and decoupled from the PHP framework version.
• Dependency-review calibration: 3 stars, 0 dependents, composite score 0.015, target framework end-of-life since 2018 — a textbook "abandoned integration shim." Useful as a reference case when agreeing thresholds for what may enter our dependency tree.
• Legacy portfolio triage: if we inherit a Symfony2 app already using this bundle, it becomes an input to a keep vs. migrate decision; even in the "keep" case the recommendation is to vendor/fork the handful of form-type and Twig lines and freeze the upstream pin.

When to Consider This Package

Consider it only in this narrow case:

• You maintain an existing Symfony 2.x application that already runs this bundle in production, you need to keep the lights on, and forking the small amount of form-type/Twig glue is more disruptive than leaving it in place. Even then: pin the commit, vendor the code, and treat it as frozen and unsupported.

Look elsewhere — or build directly — when any of the following is true:

• You are on Laravel. Wrong ecosystem entirely. Ship the editor JS through Vite and manage content as HTML/JSON; that is a small, self-contained internal wrapper, not an integration of this package.
• You are on Symfony 4/5/6/7+. The bundle assumes Symfony2 conventions; expect incompatibility and no upstream fixes.
• You need security patching, PHP 8.x support, or an actively maintained dependency. None of that is on offer.
• You assumed the editor was included. It is not; Redactor requires a separate paid Imperavi license, and the terms (per-seat, per-domain, self-hosted vs. cloud) are a procurement decision.
• You want a decoupled or headless frontend. A Symfony form-type wrapper is the wrong abstraction — you want the editor as a standalone component talking to an API.
• Rich text is a real requirement with security scope. The bundle provides no sanitization, upload validation, or XSS protection; all of that is ours to build regardless of which editor we pick.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Use it as a design reference at most.

This package is a small, unmaintained integration layer that wires the commercial Redactor editor into Symfony2 — a framework generation long past end-of-life. It is frequently mislabeled as a Laravel/PHP package, but it offers no Laravel integration whatsoever, so the expected fast path does not exist. On a modern stack, composer require will almost certainly refuse to resolve, and if forced, the first composer update is likely to break the build.

The true commitment is larger than the package implies: a paid vendor contract for Redactor, a bespoke integration only we would maintain, and a hard dependency on an obsolete framework branch. Community signal — 3 stars, zero dependents, negligible health score — means no one is coming to help patch it. Budget ~1–2 engineer-days per quarter for a wrapper, plus tracking Imperavi releases and license renewals. The highest-severity exposure is stored XSS from unsanitized rich-text content, which this package does nothing to prevent.

What I'd propose instead: decide the editor on product grounds — authoring UX, extensibility, accessibility, and content portability (store semantic HTML/JSON, not editor-specific blobs) — and ship a maintained, framework-agnostic editor through our standard frontend build. That keeps the choice reversible, decouples content tooling from the PHP framework version, and lets us fund a 3–4 week internal wrapper with sanitization and upload security as first-class scope. If a stakeholder specifically wants Redactor's authoring experience, evaluate that as a licensing and procurement decision in parallel, with the integration owned explicitly — not as a Composer dependency.