CommonMark Markdown renderer for PHP with the capability to define pre- and post-processors with custom syntax.
use Mistralys\Markdown\MarkdownRenderer;
$markdown = <<<MD
# Markdown test
Some text with **formatting**.
MD;
echo Renderer::factory($markdown)->render();
use Mistralys\Markdown\MarkdownRenderer;
use \AppUtils\FileHelper\FileInfo;
$file = FileInfo::factory('/path/to/markdown.md');
echo Renderer::factory($file)->render();
Any number of processors can be added with the addProcessor()
method. They are executed in the order that they are added.
Example: Adding the bundled video processor.
use Mistralys\Markdown\MarkdownRenderer;
use Mistralys\MarkdownRenderer\Processors\Bundled\VideosProcessor;
$file = FileInfo::factory('/path/to/markdown.md');
echo Renderer::factory($file)
->addProcessor(new VideosProcessor($renderer))
->render();
The library is based on a simple syntax for defining custom commands, which follow the following scheme with pseudo HTML attributes:
{commandName: "value" name="named value" property}
The parsing of these commands is handled automatically by the library, and the attributes can easily be accessed via a helper class when rendering the matching content.
If you want to do your own syntax parsing, create a class based on
BaseProcessor
. Use the BaseCommandBasedProcessor
class if you want
to use the library's command syntax (easiest to implement). Simply
implement all abstract methods, and you're good to go.
Every abstract method has documentation on what you are supposed to do.
You can create your processor class anywhere in your project, and add
it to the renderer with the addProcessor()
method.
use Mistralys\Markdown\MarkdownRenderer;
use My\Custom\CommandProcessor;
$file = FileInfo::factory('/path/to/markdown.md');
echo Renderer::factory($file)
->addProcessor(new CommandProcessor($renderer))
->render();
I had created similar Markdown filters in several of my personal and professional projects. Each project had different enough requirements for syntax and content, and were easy enough to implement, so for a long time I did not take the step to move the common functionality to a separate library.
Another recent project made me take the step. As is often the case, I was annoyed enough by having to create regexes to parse the commands that I decided to do it right.
I have read quite a few discussions on what kind of information should be included in a Markdown file. Image widths are one thing that the community is divided on. I agree that the width of an image is layout information, not content. The requirement is real however, and appears often enough for me to take a pragmatic approach.
My philosophy is that as long as the Markdown content stays easily readable, and that the added syntax does not interfere with reading the document, I don't mind.