- Can I install locaine/lcn-wysihtml5-bundle in a Laravel application?
- No. It is a Symfony2 bundle, not a Laravel package: it registers through AppKernel::registerBundles(), ships a FormType extending Symfony\Component\Form\AbstractType, and renders with Twig form themes, none of which Laravel's request lifecycle reaches. Composer also blocks it, because the bundle pins symfony/form ~2.3 and PHP ~5.3–5.6, which cannot resolve alongside current Laravel. The glue code is roughly 200 lines, so porting the pattern costs less than adapting the package.
- Is this bundle compatible with Laravel 10 or Laravel 11?
- No. Laravel 10 and 11 require symfony/* ^6/^7 and PHP 8.1+, while the bundle resolves to symfony/framework-bundle ~2.3 and PHP ~5.3–5.6. Forcing the install with --ignore-platform-reqs trades an install error for a runtime Class not found failure. There is no supported path to running it on a current Laravel release.
- How do I add a WYSIWYG rich-text field to a Laravel form instead?
- Use a maintained editor such as TipTap/ProseMirror or Quill wrapped in a Blade component that renders a hidden textarea and submits sanitized HTML. Sanitize on write in a FormRequest or model mutator with mews/purifier (or ezyang/htmlpurifier directly), then re-sanitize on render as defense in depth. Cache the purified output rather than purifying on every read. This reproduces the bundle's design without any of its Symfony wiring.
- What does this package actually contain under the hood?
- It bundles the wysihtml5 editor assets, a Symfony dependency-injection extension loaded via AppKernel::registerBundles(), a FormType extending AbstractType, Twig form themes, and Assetic-era asset publishing. The genuinely portable part is the design: a constrained client-side editor paired with mandatory server-side HTMLPurifier allow-list sanitization. Everything around that design assumes the Symfony kernel and cannot be reached from a Laravel request without reimplementation.
- Is wysihtml5 still maintained and safe to use in production?
- No. WYSIHTML5 is abandoned upstream, and its browser and CSP assumptions predate current practice. The bundle also pins an ancient HTMLPurifier integration and configuration surface, so the technical risk lands directly on rich-text input, the primary vector for stored XSS. With 2 stars and 0 dependents there is no community triage and no security response path. Treat it as a reference implementation, not a dependency.
- What is the safest way to prevent stored XSS from rich-text input in Laravel?
- Sanitize on write with an explicit allow-list of tags, attributes, and URI schemes using mews/purifier or ezyang/htmlpurifier. Re-sanitize on render as defense in depth and cache the purified result. Add feature tests asserting that script tags, onerror handlers, javascript: URIs, and style-based vectors are stripped. HTMLPurifier itself remains maintained and is usable directly without this bundle.
- Can I reuse this bundle's sanitizer configuration in a Laravel app?
- Yes, the configuration is the salvageable component: copy its allowed-tags, attribute, and URI-scheme posture into a Laravel purification profile. Do not copy the code, because the HTMLPurifier integration is pinned and dated and the surrounding Symfony wiring is not portable. Recreate the profile in mews/purifier config and test the exact payload classes you must strip. That answers the only argument for keeping the package.
- How do I test that rich-text HTML is sanitized in Laravel?
- Write feature tests that submit payloads through the form endpoint and assert the stored value has dangerous constructs removed. Cover script tags, event handlers such as onerror=, javascript: URIs, and style-based vectors, asserting the exact expected output. Also assert that legitimate formatting such as links, lists, and bold survives. Re-run the suite against the render path to confirm defense-in-depth purification.
- What are maintained alternatives to this bundle for Laravel rich-text editing?
- Pair a maintained editor such as TipTap/ProseMirror or Quill with mews/purifier (or ezyang/htmlpurifier) and a Blade component. That covers assets, form submission, and sanitization using conventions Laravel already supports: Vite for assets, Blade for rendering, FormRequest for validation. Avoid running Symfony bundle conventions alongside Laravel's in one process, since that is the failure mode rather than a migration strategy.
- Who should own a vendored fork of this package, and for how long?
- Vendoring is hard to justify: the glue is small, the editor is abandoned upstream, and the pinned dependencies block current PHP and Symfony. If the requirement is genuinely to preserve this exact sanitizer configuration, copying the config into a Laravel purification profile is a one-day task with a clear owner. Otherwise, port the pattern and drop the dependency entirely. Decide the owner and the sunset date before any fork is created.