Lcn Wysihtml5 Bundle Laravel Package

Product Decisions This Supports

• Feature scope for user-generated HTML. Every roadmap item that lets users submit formatted content — comments, CMS pages, support macros, product descriptions, email templates — needs the same pairing this bundle documents: a constrained client-side editor plus mandatory server-side allow-list sanitization (WYSIHTML5 + HTMLPurifier here). The pattern is a product requirement; the package itself is not a candidate.
• Build vs. buy on editor widgets. Use this as a reference spec, not a vendor option. Its integration shape — editor assets as a form field type, a configurable toolbar, a sanitizer profile fixed at the form/validation boundary — is the checklist to apply when evaluating modern replacements (TipTap/ProseMirror, Quill, Editor.js, or a Filament rich-text field) alongside mews/purifier or ezyang/htmlpurifier.
• Dependency intake policy. A concrete artifact that fails a stack-fit gate on its face: a Symfony2 bundle in a Laravel codebase, with Composer constraints (symfony/* ~2.3, PHP 5.3–5.6) that cannot resolve against Laravel 9+/PHP 8.1+. Good worked example for "framework fit" and "maintenance signal" gates, so future intake tickets resolve in minutes rather than a discovery spike.
• Tech-debt / abandonment narrative. 2 stars, 0 dependents, no meaningful release cadence, and an upstream editor (WYSIHTML5) abandoned for years. A clean illustration for an "abandoned dependency" policy: what counts as unmaintained, what the replacement path looks like, who owns the migration.
• Security posture for stored rich text. Reinforces the standing decision that user HTML is sanitized server-side by a maintained allow-list library and never delegated to the editor's client-side filtering. This is a compliance/audit-visible product requirement, not an implementation detail.
• Scoping the "replace our editor" initiative. The capability is a small, well-understood build — editor component + purifier config + XSS regression test, roughly half a day to a day — not a vendor-evaluation project. Supports de-scoping it accordingly.

When to Consider This Package

Default answer: do not adopt it for a Laravel product. It is a Symfony2 bundle — wrong framework, wrong DI container, wrong form layer — and Symfony 2 is long past end-of-life. Even in a legacy Symfony shop it fails on age: WYSIHTML5 is unmaintained upstream and the wrapper is pinned to an obsolete major version.

Adoption criteria would have to include all of the following:

• You maintain a live Symfony 2.x application on PHP 5.x/early 6 that still boots this kernel and form component.
• You need a WYSIWYG form type quickly and accept dev-master-style installation (no meaningful stable release posture).
• You have read the actual sanitizer allow-list in Resources/config/ and accept it as your content contract.
• You have assigned a named internal owner for security patching, and the HTMLPurifier definition cache path is writable.

Look elsewhere when:

• The target is Laravel (any modern version): no service provider, no Blade/Vite integration, unresolvable dependency graph.
• You need any maintenance guarantee, CVE response, or PHP-major upgrade path — none exist.
• You need accessibility, mobile/paste handling, collaborative editing, or modern CSP compatibility — beyond what WYSIHTML5-era tooling provides.
• Security or compliance review is in scope — unmaintained editor plus unmaintained glue in the stored-XSS path is an automatic finding.
• You want the capability without owning a fork: maintained editor + ezyang/htmlpurifier (or mews/purifier), sanitize on write, re-sanitize on render, test that <script> and onerror= payloads are stripped.

How to Pitch It (Stakeholders)

Executive summary: This package is not viable for us and should not be adopted. It is a Symfony2 integration for a WYSIWYG editor while our stack is Laravel — the dependency graph will not even resolve — and both the bundle and its upstream editor library are effectively unmaintained (2 GitHub stars, zero dependents, editor abandoned years ago). Adopting it would place unmaintained code directly in our highest-risk input path — stored XSS via rich-text fields — with no offsetting benefit.

What it is genuinely useful for: One durable product requirement it illustrates well — any feature accepting user-authored HTML must pair a constrained editor with server-side sanitization through a maintained allow-list library. We keep that requirement; we satisfy it with HTMLPurifier (or mews/purifier) and a maintained editor on the client.

Recommended decision: Reject for adoption; classify as reference-only. Ship the rich-text capability as a small internal build delivered as a shared component: maintained editor, sanitizer configured at the write boundary, re-sanitization on render for defense in depth, and a regression test asserting script and event-handler payloads never survive. File this repository as a worked example in our dependency-intake and abandoned-dependency policies.

Ask: No budget required. Two decisions — one engineering (editor selection) and one process (add framework-fit and maintenance-signal gates to dependency review) — plus a named owner for the sanitizer configuration. Porting the pattern is cheaper and safer than owning a fork of dead code.