Redactor Bundle Laravel Package

Technical Evaluation

Architecture fit — Despite the intake label, tp/redactor-bundle is a Symfony bundle, not a Laravel package. Its shape is a classic thin Symfony integration: a Bundle class, a DI extension, and a AbstractType form type that renders a textarea and attaches Redactor's JS initialization (plus, typically, a Twig form theme and published assets). That is a good architectural fit for Symfony — the Form component's type/extension model is exactly where a WYSIWYG widget belongs, and the bundle stays out of the domain layer. It is a poor fit for Laravel: there is no service provider, no Blade/Form parity, no vendor:publish asset pipeline, and no reason to bridge Symfony's Form component into Laravel to get a rich-text field.

Integration feasibility — Mechanically low-friction if the target is a Symfony app that already ships the Redactor editor assets and license. The realistic work is not "install the package" but: confirm the form type's option surface (toolbar/config passthrough vs. hardcoded defaults), confirm whether the editor JS/CSS is vendored or expected from the host app, and wire asset publishing (assets:install / importmap / encore) to our convention. Expect to write the Twig theme or a view override.

Technical risk — High, and driven almost entirely by the ecosystem signals: no stars, no score, zero dependents. That means zero downstream verification — nobody has told us this bundle renders correctly against a supported Symfony version. Concretely:

• Unmaintained bundles typically break on Symfony 5+/6/7 because of typed configureOptions/buildView signatures, getContainerExtension() returning ?ExtensionInterface, and autowiring-era service definitions.
• PHP version floor is unknown; likely PHP 5.x/7.x era constraints.
• Redactor itself is a commercial editor (Imperavi); the bundle almost certainly does not convey a license, and older versions had a hard jQuery dependency.
• WYSIWYG output is raw HTML. Sanitization is our responsibility, and a stale bundle is a plausible vector for stored XSS.

Key questions

1. What do composer.json require constraints say (PHP, symfony/form, symfony/framework-bundle)?
2. Is the Redactor editor vendored into the bundle, or supplied by the host app — and which major version (Redactor 10 / II / X)?
3. Are editor settings exposed as form options/bundle config, or hardcoded?
4. Does it depend on jQuery, and can init be done via a modern import map?
5. Who owns it upstream — is there a commit in the last 24 months, any tests, any CI?
6. What is the license path for Redactor in our org?

Integration Approach

Stack fit — Treat as Symfony-only. If the estate is Laravel, this is the wrong tool: implement the same widget as a Blade component with a direct editor JS init (or a Livewire/Alpine wrapper), and skip the Symfony Form indirection entirely. If the estate is Symfony, it fits the admin/form surface cleanly; keep it confined to back-office forms, not public-facing content entry.

Migration path — Do not take a Packagist dependency on an unvetted, zero-dependent bundle. Preferred order:

1. Reimplement in-house (~50–100 LOC): an AbstractType extending TextareaType that sets a data-redactor attribute, plus a small JS module that initializes the editor on DOMContentLoaded. This is very likely cheaper than adopting and owning the bundle, and it eliminates the supply-chain question.
2. If reimplementation is rejected, fork and vendor via a VCS/path repository, pin to a commit SHA, and own it.
3. Adopting upstream directly as a floating constraint is the option to reject.

Compatibility — Validate against our actual PHP and Symfony minors before committing. Expect to patch: return types on configureOptions/buildView/buildForm, OptionsResolver usage, service definition syntax (YAML vs. attributes), and asset paths. If jQuery is a hard dependency, either accept it scoped to admin pages or replace the init with a framework-agnostic snippet.

Sequencing

1. Timeboxed spike (1–2 days): read the bundle, render it in a scratch Symfony app on our version, capture the diff between "works" and "works on our stack."
2. Decide build-vs-adopt off the spike, not off the README.
3. Security/licensing gate: dependency audit, Redactor license procurement.
4. Sanitization layer: symfony/html-sanitizer or HTML Purifier on write and on render; define an allowed-tags policy per content field.
5. Pilot on one admin form → observe → generalize.

Operational Impact

Maintenance — Assume we own the code from day one. Budget a standing line item: fork, add a phpunit smoke test that renders the form type and asserts the data- attributes, add PHPStan at a low level, and track it in the dependency-upgrade backlog alongside the Symfony major upgrades. Upstream release cadence should be assumed to be zero.

Support — No community, no issue triage, no CVE response for the wrapped editor. Internal ownership with a named maintainer is mandatory; the only vendor relationship available is with Imperavi for Redactor itself, and that covers the editor, not the bundle.

Scaling — Runtime footprint is negligible: one form type, one DI extension, a client-side script. The scaling concern is page weight and editor boot cost in admin UIs — load editor assets only on routes that render the field, and lazy-init on focus for forms with many rich-text fields.

Failure modes

• Silent breakage on the next Symfony minor (signature or DI incompatibility) discovered at deploy time.
• Editor assets 404 after an asset-pipeline change; the form degrades to a bare textarea with no error visible to authors.
• Unsanitized HTML stored in the DB → stored XSS in admin or public rendering.
• License expiry or CDN/key rotation disables the editor without an application-level signal.
• No upstream patch path for a vulnerability in the pinned editor version.

Ramp-up — Half a day to read the bundle; one to two days to fork (or reimplement), test, and wire assets. The disproportionate effort is not the bundle — it is the sanitization policy, the license procurement, and the standing ownership commitment, which together outweigh the integration by an order of magnitude. For a Laravel target, ramp-up is zero because the correct action is not to use it.