- What does prinsfrank/markdown-dom actually do?
- It converts Markdown into a traversable DOM structure (document to block and inline nodes to text) instead of returning an HTML string. You can then query, traverse, and manipulate those nodes before rendering, which suits custom transformations and content processing. Importantly, the core package is a DOM abstraction and not a parser, so it requires an adapter such as prinsfrank/markdown-dom-league-common to do the actual Markdown parsing.
- How do I install prinsfrank/markdown-dom in a Laravel application?
- You need PHP 8.x, ext-dom, Composer, and the package itself plus a parser adapter such as prinsfrank/markdown-dom-league-common. There is no service provider, config file, or facade, so you wire everything yourself in a service provider. The usual approach is to bind the MarkdownParser contract to an application-owned renderer service or Blade component.
- Does prinsfrank/markdown-dom support Laravel out of the box?
- No. It ships no service provider, config file, facade, or Blade directives, and it is framework-agnostic by design. The upside is that it does not pin illuminate/* version ranges, so it will not constrain Laravel upgrades. The tradeoff is that all wiring, sanitization, and caching decisions belong to your application.
- What is the difference between markdown-dom and Laravel's Str::markdown()?
- Str::markdown() wraps league/commonmark and returns an HTML string in one line. markdown-dom gives you a structured DOM you can traverse and mutate, which is what enables table of contents generation, link rewriting, image lazy-loading, table wrapping, excerpts, and multi-format output. If you only need HTML from Markdown, this package is redundant overhead.
- Which Markdown dialect and extensions does prinsfrank/markdown-dom support?
- Because the core package does not parse, dialect and extension coverage come entirely from the adapter you choose. Delegating to the league/commonmark adapter pushes responsibility for GFM tables, footnotes, strikethrough, task lists, and CommonMark compliance onto that library and upstream. Be aware that a DOM-based renderer will not byte-match CommonMark reference output, so verify fidelity against your own fixtures.
- Is prinsfrank/markdown-dom safe to use in production?
- The package faithfully represents whatever the parser emits and does not sanitize anything itself. You must set and enforce html_input and allow_unsafe_links on the underlying league/commonmark configuration, and route rendering through an application-owned service. It is also a 0.2.x release with a single maintainer and negligible community validation, so budget for breaking changes in minor version bumps.
- Who is responsible for sanitizing Markdown output when using this package?
- You are. The package is a DOM representation layer and does not clean HTML, so any sanitization must happen in your configuration or your rendering wrapper. Confirm that html_input and allow_unsafe_links are set explicitly on the adapter side, and keep a fail-open fallback for rendering errors. Treating sanitization as an application concern rather than a package feature is the safest posture.
- What is the custom autoloader issue fixed in prinsfrank/markdown-dom v0.2.1?
- v0.2.1 is a one-commit patch over v0.2 that fixes an off-by-one in a bundled custom autoloader, which affects class loading rather than Markdown parsing. The failure mode it produces is an intermittent class-not-found error that can look like Composer cache corruption. Prefer a configuration that bypasses the bundled autoloader entirely, and check that it does not shadow your PSR-4 map.
- How should I test a Markdown to DOM integration in Laravel?
- Use golden-file tests against the output of your chosen adapter, since a DOM renderer will not byte-match CommonMark reference output. Add caching and a fail-open rendering path so a parser failure never breaks a page. A spike is cheap (bind the interface, write one wrapper), but production hardening around sanitization and fidelity takes real effort.
- What alternatives to prinsfrank/markdown-dom should I consider?
- If you just need HTML from Markdown, use Laravel's Str::markdown() or league/commonmark directly, which Laravel already ships transitively for Markdown mail. Choose markdown-dom only when you genuinely need structure, such as tables of contents, link rewriting, image lazy-loading, table wrapping, excerpts, or multi-format output. Avoid it entirely if round-tripping Markdown back to Markdown is a requirement, since that is a much higher bar.