[SOLVED] - Markdownify not working in templates

support
1

In my config.toml I define the text I want to appear in my footer columns. For example, I might do this:

[params]
footer_quote = ‘’’
### Einstein
* God does not play dice. *
’’’

Then in layouts/partials/footer.html I have:

{{with .Site.Params.footer_quote}}{{ . | print | markdownify }}{{ end }}

This does not work. The quotation is put inside of a … block rather than be rendered by markdown.

Maybe I read things wrong, but i see examples just like the above, so I’m currently confused why it isn’t working.

If that is wrong, then what is the proper way to send params content through markdown in a template?

Well, I know why it isn’t working: For some reason Hugo converts multiline strings into pre and code blocks. If you use a plain string, markdownify works fine.

I guess the solution is either a fix for Hugo so you can use multiline quotes without the automatic pre and code markup, or maybe there is some workaround I don’t know of. I tried using print so far.

2

What is the motivation behind the print?

3

As to what works, you can see a working example here:

4

I read that print would remove HTML codes, so I thought it might remove the pre and code markup to that markdownify would work.

5

No, print just prints … which should do nothing special in this case.

If you have markdown you only need markdownify. On a side note, there is also plainify that removes HTML from strings.

6

SOLVED

OK, I have it working. markdownify was treating the quote as a code block because of leading spaces. Removing them fixes the issue.

I’ll leave the rest of my post unedited.

Unfortunately markdownify isn’t enough in the case I have described.

The source of the generated HTML seems to show the problem. If I create a string like this:

[params]
    quote = "*this is a test quote*"

Then it works fine. The template passes the string to markdownify and it gets formatted. However, if I do this:

[params]
    quote = ''''
# fake quotation
this string
is several
lines
long
'''

The template engine does read the data, but instead of passing it through markdownify, it puts the content in pre and code markup.

Its obvious that when Hugo sees a multi-lilne string, it is treating it like source code for some reason.

I tried {{ . | plainify | markdownify }} but that doesn’t work. planify doesn’t seem to remove pre and code tags.

If I . markdownify does nothing. If you look at the source of the generated HTML, the variable’s content gets wrapped up in pre and code tags. Hugo appears to do that any time you use the multi-line string in TOML.

If I create a single line string, then it works fine. markdownify gets the text and formats it, no issue.

But if the variable in your TOML file is multi-lline, Hugo wraps it up in a code block for some reason.

*** EDIT ***
Well this is interesting, it is markdownify that is wrapping the text in pre and code if it is multi-line. If I remove markdownify then I get the text raw in the HTML output.

So, there seems to be something wrong iwth markdownify… it formats single line strings just fine, but multi-line strings it is not working right.

7

@Shannon have you tried looking at the spec for TOML? It appears you need three quotation marks and not three apostrophes/single quotes. There is also the ability to add carriage returns, etc. See here:

https://github.com/toml-lang/toml#string

If you’re getting pre/code, my guess is that you’re either using triple back ticks or that you’re indentation (ie, leading spaces) reflects that of pre/code in markdown, which would be the desired behavior. FWIW, many of the support issues on the forum related to front matter are solved when users read the spec, so I’m hoping this helps you out. Cheers.

8

Actually, the spec says that you can use double or single quotation marks.

Three single quotation marks are used when you want to avoid having to escape certain characters in your string.

Your second point is spot on, however. I totally forgot that the leading spaces would cause a code block.

9

So is it safe to say there is nothing wrong with markdownify? If this is the case, want to add “[SOLVED]” to your title so as not to mislead others in the forums?

Ah yes, I see. I had just tested the three double quotes locally and it was working A-okay so I thought that might be the issue. My bad.

http://spec.commonmark.org/0.25/#indented-code-block

Cheers :relaxed: