User-supplied content needs to be passed into the blade component unescaped, otherwise blockquotes which use > will not work correctly. This PR aims to set secure defaults that prevent reflected XSS attacks.

Hi,

I noticed when trying to add a custom renderer that there was no way to pass a priority option through (meaning that if a renderer for the element type had already been registered and returned a non-null result, the renderer added to the config wouldn't be used).

This PR allows a priority key to be set for block / inline renderers, but falls back to 0 if not found. (0 is the default priority, so without adding the new key nothing should change),

I have also updated the comments in the config file to have the correct array key (class instead of blockClass) and bought the installation setup documentation page to be inline with the config file (as many of the comments were already out of date before I made my own changes to the config file).

As an complete aside, locally I went to run the tests just to be sure nothing I changed caused any issues, but I was getting a number of failures even when I reverted my changes and I'm really not sure why.

This update accounts for changes made in the spatie/commonmark-shiki-highlighter as well as those further upstream in League\CommonMark 2.0 as that had some significant ones. The other change this accounts for is that Shiki upstream changed color schemes to keep current with their sources too.

The inline parsers are very useful.

For example if one wanted to add a hashtag system, or a "mention" system using match for @somename like here in github, they could make an inline parser as in the example on commonmark: https://commonmark.thephpleague.com/2.3/customization/inline-parsing/#inline-parser-examples

This pr simply adds the option to the config

Hello!

I recently made a PR in shiki php repo to add docs around using Node Version Manager.

I have made a similar PR here to update the documentation to provide some information to people using NVM to hopefully help them avoid the issues I had with not understanding why it was not working properly.

Thanks :)

This caught me off guard (Shouldn't have, but I'm tired!). I thought it would be worth a little footnote. If you use default blade statement:

{{ $article->markdown }}

The markdown is passed through PHP's htmlspecialchars function and all the HTML specific tags < > ' etc are replaced with their ASCII equivalent. To stop this (And for your lovely package to work) a user would need to use the unescaped, effectively raw blade statement:

{!! $article->markdown !!}

Per title, this PR creates a test that identifies a bug and fixes said bug.

Up until commit https://github.com/spatie/laravel-markdown/pull/26/commits/3154c0dba645522a61f51176d654013e6888d9d5 the PR has intentioally failing builds. However at commit https://github.com/spatie/laravel-markdown/pull/26/commits/2da77b7253cc05f9a486d592d941450d7a0d0487 the underlying bug was fixed and the subsequent PR adds a method parameter to bring the addBlockRenderer and addInlineRenderer methods in parity with the new funtionality.

Saw one of @freekmurze 's tweets referring to this (newer) package, which I'd not yet heard of, so I took a look. I just noticed a few links that weren't working, so came in to make a couple corrections. I haven't tested the links, but just made what I assume are the right changes. 😜

Please let me know if there are any questions/concerns.

Thanks again for your work...! 🚀

hey @freekmurze - this change makes a quick fix for the 2.0 release related to extensions to help ensure things work properly. There were parts of the initial changes I made that were not covered by tests to catch the logic issue.

Quickfix

Make sure extensions can be given as class names (strings) or instances. So i've made adjustments to ensure extension load properly.

Specifically these lines would be affected: https://github.com/spatie/laravel-markdown/blob/991ff79926e3eb6667ed0c2e6793a63825516cf6/src/MarkdownRenderer.php#L149 https://github.com/spatie/laravel-markdown/blob/991ff79926e3eb6667ed0c2e6793a63825516cf6/src/MarkdownRenderer.php#L78

New feature

This also adds a method that mimics the league convertToHtml method for users. Adding this method and covering it with tests was what caused me to encounter the error to begin with. Otherwise I would have opted to split them up.

This addition is important for users that want the FrontMatterExtension (or similar). Since these shouldn't return a string directly like existing methods do. So the new method returns a RenderedContentInterface object specific to the renderer. For instance, they can use any potential extension specific results. Like:

$result = app(\Spatie\LaravelMarkdown\MarkdownRenderer::class)->renderMarkdown($markdown);

// Grab the front matter:
if ($result instanceof RenderedContentWithFrontMatter) {
    $frontMatter = $result->getFrontMatter();
}

• [x] Added the omitted line of code.
• [x] Fixed tests that weren't running properly with testbench.
• [x] Add tests covering extensions (both the renderer and the component).

Details here: #14

without this change, the commonmarkOptions parameter documented here has no effect. I assumed that all options on this page should be exposed and updated the example accordingly.