- Can I install m6web/draftjs-bundle in a Laravel application?
- No. It is a Symfony bundle, not a Laravel package: it ships a bundle class, Symfony DI service definitions and a Twig-oriented rendering path, and Laravel has no bundle loader, no services.yml config and no Twig by default. Composer constraints also pin Symfony 2.x/3.x components and PHP ^5.6 || ^7.0, which conflict with Laravel 10/11 running on PHP 8.2+. Treat it as a reference implementation and specification rather than a dependency.
- How do I convert Draft.js raw ContentState JSON to HTML in Laravel?
- You have three realistic options: port the converter core into a Laravel service provider behind a DraftJsRenderer contract that returns HtmlString, vendor the converter source under a private VCS repo after stripping the Symfony DI layer, or reimplement the transformation from scratch. The actual surface is small — block types to tags, entity ranges to anchors and images, inline styles to strong and em — roughly 200 to 400 lines of code well specified by the Draft.js raw schema. Reimplementing is often cheaper than reconciling a 2017 fork.
- Which Laravel and PHP versions does m6web/draftjs-bundle support?
- None in any official sense. The bundle was last released on 2017-02-21 and targets PHP ^5.6 || ^7.0 with Symfony 2.x/3.x components, so it is incompatible with Laravel 9, 10 or 11 on PHP 8.1+. There will be no PHP 8.x compatibility fixes, no security patches and no issue responses. Any Laravel integration has to be a fork or a reimplementation you own.
- Is m6web/draftjs-bundle still maintained?
- No. The repository is archived and deprecated, last released in February 2017, with 7 stars and zero dependents. Upstream Draft.js itself was deprecated by Meta in 2023, so the whole rendering model is on a legacy trajectory. Plan an exit condition, such as replacing the renderer when you migrate editors, before adopting any of its logic.
- How do I replace the bundle's Twig filter with a Blade directive or helper?
- Drop the Twig layer entirely and expose the converter as a renderer class with a method like DraftJsRenderer::toHtml(array $raw): string, resolved from the container and optionally wrapped in a Blade component or helper. Output should be returned as Illuminate\Support\HtmlString so Blade escapes consistently, or explicitly rendered with unescaped output plus sanitization. Keeping the interface narrow means nothing in your app depends on the M6Web namespace and you can swap implementations later.
- Is m6web/draftjs-bundle a good alternative to draft-js-export-html for server-side rendering?
- Only as a specification. draft-js-export-html works client-side and lets you produce HTML at write time and store it in a body_html column, which avoids server-side rendering altogether for new content. The bundle's value is server-side conversion of already-stored raw JSON, which matters for historical rows or when the editor cannot be trusted to render. Ask first whether you need server-side rendering at all before porting anything.
- What Draft.js block types and entity types does the converter handle?
- The rendering logic uses a block-renderer map plus entity decorators, covering common cases such as paragraphs, headers, lists, blockquotes and link and image entities, with inline styles mapped to strong and em. Review the source for how inlineStyleRanges and entityRanges are applied and ordered, and how nested lists are numbered, because those details are where output diverges. Audit your own content corpus to confirm every block and entity type in production is covered before relying on it.
- How should I test that my Laravel Draft.js renderer matches the original bundle output?
- Spike it once: install the bundle in a throwaway PHP 7.4 container via a fork or --ignore-platform-reqs and run your own content samples through it to capture golden output. Then freeze a fixture set of 200 to 500 real rawContentState documents covering every block and entity type, with expected HTML, and run those fixtures against your Laravel implementation. The fixtures are the durable asset; the code is replaceable.
- How do I safely render Draft.js HTML with unescaped Blade output?
- Never output {!! !!} on raw converter results without sanitization, since entity ranges and attributes can carry arbitrary URLs and markup. Run the generated HTML through a whitelist sanitizer such as HTMLPurifier and restrict allowed tags and attributes to what your block renderers actually emit. Also sanitize once at write time if you backfill a body_html column, so the read path stays cheap and idempotent.
- How much work is it to port m6web/draftjs-bundle to Laravel?
- Roughly one to two developer days for a thin port of the converter core into a service provider plus a DraftJsRenderer contract, replacing Twig templates with Blade or HtmlString. The risk is mostly non-technical: Composer conflicts with the Symfony components Laravel already pulls in, an unmaintained 2017 codebase and no upstream security response. Budget additional time for fixtures, a dual-write column and a backfill if you need to migrate historical content.