{{ should not be rendered in a post #3259
Comments
|
Try {% include_code %} with skip_render config as a workaround. |
|
The only workaround that works is to include gist or external file. |
|
I'm having the same issue on I have a file To which Hexo complains: In Markdown sources (at least) we shouldn't render Nunjucks within literal blocks. Compare to John Gruber's introduction to the original Markdown, which states that "In a regular paragraph, you can create code span by wrapping text in backtick quotes. Any ampersands (&) and angle brackets (< or >) will automatically be translated into HTML entities. This makes it easy to use Markdown to write about HTML example code" -- even though Markdown supports HTML in the main body copy, the message is clear: text inside back-ticks (either inline as in Now, how should we implement this? Perhaps in hexo-renderer-marked we could examine the output and manually escape Any thoughts? Edit: I tried patching hexo-renderer-marked, and by the time it gets to the file, it's already been run through Nunjucks, which is unfortunate. Maybe we can reorder that in |
|
This should work with any markdown renderer and not only marked. There should be a way to disable helper (and so nunjucks) via the frontmatter at least (low quality solution) or dynamically recognize that when This is a complex thing to do because it has to be done after markdown to HTML rendering. Also so cases are trivial like Example of real-life nunjunks crash: Here it was easy to spot because it was only a linked But re-tring now I have a fatal error which don't tell me where does it comes from: which is far harder to spot. |
curbengh
changed the title
|
I'm thinking of parsing only |
curbengh
changed the title
Why not if nunjucks is used only for tag helpers and tag helpers are using only
This is not even a workaround, this will work only for the link case. As I said earlier there are two solutions:
like #2593 (comment) suggested. It is easier to implement but that require users to manually change their frontmatter when they encounter a conflict.
Actually not detect in markdown but in rendered HTML so it will works with any renderer. This can be done with a regex or a HTML DOM parser to check if |
|
PS : see here all the changes I needed to do to my post to make is pass the nunjucks logic. It cost me one hour. Only to properly escape everything and test and trying to get the output the less ugly possible. |
|
@curbengh is it planned to fix this bug that requires breaking changes for 5.0.0 milestone ? |
Environment Info
Node version(
node -v): v10.9.0Hexo and Plugin version(
npm ls --depth 0):For BUG
I think I get this error message an hundred times:
Because I used
{{or}}in my markdown files. Because I'm writing technical stuff about templating languages for example.This is making the EJS template engine crash.
But instead of trying to compute all files blindly, Hexo should make the EJS engine aware of the markdown context.
I mean if there is
}}or%}ok try to do something with it but if the same pattern is inside markdown inline or fenced block just ignore it, it's not for you silly EJS engine.Same for other languages (other than markdown) and stuff inside a comment.
The EJS engine is blind, make him some eyes please.
Sometimes even using the
{% raw %}tag I can't write the code I want to.An additional mechanism can be to make a switch to turn off EJS parsing 1) globally in _config.yml and 2) locally inside the file frontammeter.
Not a marked problem. Marked render that as expected.
Related issue: #2030
The text was updated successfully, but these errors were encountered: