- Can I install ornj/markdown-bundle in a Laravel application?
- No. ornj/markdown-bundle is a Symfony2 bundle, and it depends on the Symfony kernel bundle registry, the Symfony DI container, the Form component's type system, and Twig. Laravel exposes none of those surfaces, so there is no drop-in integration path. For a Laravel app, use league/commonmark for rendering plus an HTML sanitizer such as mews/purifier, and build the editor UI as a Blade, Livewire, or Inertia component.
- Which Symfony versions does ornj/markdown-bundle support?
- It is a Symfony2-era bundle, and Symfony 2.8 LTS reached end of life in 2018. Its Composer constraints, Twig syntax, and asset model are pinned to PHP 5.x/7.0 generation tooling. Installing it on Symfony 5, 6, or 7 will likely produce dependency conflicts at best, so check composer.json before considering it for anything other than a legacy Symfony2 keep-the-lights-on project.
- How do I render Markdown inside a Twig template with this bundle?
- The bundle registers a Twig filter that converts a Markdown string to HTML, so you pipe a template variable through it rather than calling the service directly. Because the output is HTML, the bundle ships escaping controls so you can decide whether the rendered result is treated as safe. Confirm the exact filter name and escaping flag against the repository README, since there are no maintained releases to rely on.
- Is ornj/markdown-bundle safe against XSS in rendered Markdown output?
- Markdown rendering is a classic XSS vector, because raw HTML passthrough and unsafe link schemes are easy to leave enabled. The bundle advertises safe HTML output with escaping controls, but with zero dependents and no downstream testing there is no safety net behind that claim. Whichever renderer you pick, run output through a sanitizer such as mews/purifier or HTML Purifier, and restrict dangerous extensions and protocols in your CommonMark configuration.
- How do I configure CommonMark extensions and options in this bundle?
- Configuration goes through the standard Symfony bundle config, typically in config.yml for Symfony2 or config/packages for later versions, where you declare enabled extensions and renderer options. Those keys map onto the underlying CommonMark environment and its extension set. Because the package has no active maintenance, verify each option key against the source rather than assuming it matches current league/commonmark configuration.
- Is ornj/markdown-bundle maintained and safe to use in production?
- There is no evidence of production use: zero stars, zero dependents, and a zero score, on top of a Symfony2 base that has been EOL since 2018. That means you would be the first integrator, and any bug you hit becomes yours to fix with no CVE response upstream. Treat the repository as prior art and a design reference rather than a dependency you install.
- What are the maintained alternatives to ornj/markdown-bundle for Laravel?
- For server-side rendering, league/commonmark is the actively maintained PHP CommonMark implementation, paired with mews/purifier or HTML Purifier for sanitization. On the front end, EasyMDE and Toast UI Editor provide the toolbar, split-pane, and live-preview interaction that this bundle's widget merely imitates. That combination delivers the same feature set with current releases and security response, which the bundle cannot offer.
- Can I reuse this bundle's editor widget in a Blade component?
- Not directly. The Symfony FormType and the Twig widget are framework-bound and have to be discarded and re-implemented. What is portable is the interaction model: a markdown textarea with debounced client-side preview, an optional server-side preview endpoint when render parity is required, and a renderer bound to a form field. Catalogue those behaviours from the bundle's JavaScript and templates, then rebuild them as a self-contained front-end asset in Blade, Livewire, Vue, or React.
- Do I need a server-side preview endpoint for a Markdown editor in Laravel?
- Only if preview output must match stored output exactly, for example when custom extensions or sanitization rules are applied server-side. Otherwise a debounced client-side preview with a sanitizer is acceptable and cheaper. If you do build one, add a Laravel route and controller, or a Livewire action, that accepts Markdown and returns sanitized HTML through the same commonmark plus purifier pipeline used on read.
- How do I migrate from ornj/markdown-bundle to a maintained Laravel Markdown stack?
- Extract, do not install. Read the bundle's JavaScript and templates to catalogue its preview interaction model, including debounce behaviour, toolbar layout, split-pane versus toggle, and full-screen support, then re-implement that as your own front-end asset. Add a preview route or Livewire action if server parity is required, bind the component to the model's markdown column, and render stored content through the same renderer and sanitizer. Keeping a single rendering path is non-negotiable, because preview and published output diverging is a well-known and embarrassing bug class in Markdown editors.