Weave Code
Symfony Djot Laravel Package
php-collective/symfony-djot
Symfony integration for Djot, the lightweight markup language. Provides bundle configuration, service wiring, and Twig rendering so you can parse and display Djot content in Symfony applications with minimal setup.
Symfony bundle integration for php-collective/djot
Frequently asked questions about Symfony Djot
- Can I use php-collective/symfony-djot in a Laravel application?
- Yes, but treat it as the underlying Djot converter rather than a Laravel package. Laravel will not auto-discover the Symfony bundle or its container configuration, so you bind the converter manually in a service provider. The bundle's Twig rendering and dependency injection wiring are not useful in Laravel; the framework-agnostic parser is the part you want.
- How do I install and wire up Djot rendering in Laravel?
- Install it with Composer, then create a singleton binding in a service provider that instantiates the converter with options read from config/djot.php. Expose a Djot::toHtml() facade or a Blade directive behind your own DjotRenderer interface so templates never touch the package directly. Budget for a small adapter rather than expecting a zero-config install.
- Does symfony-djot require Symfony HttpKernel or DependencyInjection to work?
- The bundle itself depends on Symfony components, but the Djot converter is PHP-native and usable standalone without the framework. Before committing, check the package's PHP and Symfony constraint ranges against the Symfony packages your Laravel version already requires. A transitive pin conflict is the most likely install-time blocker, so run composer why symfony/* in the target app first.
- Why does my Djot output look escaped or mangled after upgrading to 0.2.0?
- In the 0.2.0 line safe_mode defaults to true, which escapes raw HTML that previously rendered. It is a silent output change rather than an error, so affected pages look visibly mangled instead of failing loudly. This is exactly the kind of breaking change 0.x versioning allows in any minor release.
- How do I upgrade to 0.2.0 without breaking existing Djot content?
- Land 0.2.0 with safe_mode set explicitly to false to preserve current output, and ship that upgrade with zero user-visible change. Then audit: render the full corpus under both configurations and diff the HTML. Every diff is either content that was relying on raw HTML and needs a decision, or content that was already being escaped and is a no-op.
- Is djot_raw safe to use, or does it reintroduce XSS risk?
- djot_raw and djot_raw() output trusted input only and will reintroduce the XSS exposure the safe default just closed. It is the obvious fix a developer reaches for when rendering breaks, so decide the policy before rollout, not after. Reserve it for a named allowlist of admin-only fields and enforce that allowlist in the renderer profile rather than in templates.
- Which Djot converter options and extensions can I configure?
- Constructor and config options include significant_newlines, soft_break_mode, and xhtml, plus the six extensions added in the 0.2.0 line. Because they are all configuration-level, they map well to a Laravel config file with per-context profiles such as comments, docs, and CMS. Confirm each extension is opt-in and independently scoped before enabling it, since new 0.x surfaces are lightly tested.
- Should I render Djot at write time or read time in production?
- Prefer render-at-write with cached HTML for anything on a hot path, and keep render-at-read for low-volume or draft content. Djot parsing is pure PHP with no external service, so caching the HTML output is straightforward. Isolating the parser behind a single renderer seam also lets you swap or fork it later without touching call sites.
- Is Djot a drop-in replacement for Markdown, and can I convert my existing Markdown content?
- Djot is a plausible successor format for user-authored and CMS content, but it is a separate markup language, not a drop-in Markdown swap. Adopting it is a content-pipeline decision about storage format, authoring UX, and render path, and the package is the smallest part of that decision. Before committing, confirm whether a conversion tool exists and whether round-tripping between Djot and Markdown is lossless.
- Is symfony-djot maintained, and how do I keep the parser swappable if the 0.x line stalls?
- The project is 0.x, maintained by a single collective with no commercial support path, so breaking changes and stalled releases are realistic risks. Bind the converter behind a single DjotRenderer seam that takes source text in and returns HTML out, and keep settings in config/djot.php with named profiles. That isolation makes a future swap or fork a one-file change instead of a rewrite.
Weaver
How can I help you explore Laravel packages today?