Code fence issue on upgrade from 0.59.1 to 0.60.0+

support
1

On our site (which doesn’t use themes, but custom layout from a third party) we’re looking to upgrade from the now quite aged 0.59.1 release.

However our code fence blocks get rendered into HTML really weirdly. The first chunk of code is always OK, but anything after the first blank link gets rendered as multiple <p> elements, sometimes with nested <pre> elements. In these blocks white space isn’t preserved, and the odd nesting of elements also completely messes with our CSS (although I could resolve that).

Bizarrely, if I build a brand new Hugo site and throw the same markdown content at it with any version I’m unable to recreate the problem - each line of code gets the expected <span> element.

As far as I can see we’ve no render-specific options in our config files except for markup.goldmark.renderer.unsafe = true

What could there possibly be in our site’s configuration that causes the code fence output to alter so radically?

Hugo 0.84.2

hugo-0.84.2
hugo-0.84.21836×1564 158 KB

2

Here’s how it looked in 0.59.1 (without syntax highlighting)

hugo-0.59
hugo-0.591836×1370 155 KB

3

Given that, I think it’s a tall order to expect anyone to guess what’s up with your old site without seeing the source. The devil is in the details.

4

I believe I’ve found the problem.

It appears to be due to our third party “designer” always using:

{{ .Content | markdownify }}

with my understanding of that being that all page contents were being fed through the markdown engine twice.

This might also explain why rendering was broken on pages that didn’t even have raw HTML when unsafe was set to false.

Is that pipe into markdownify something that was actually required in earlier versions, or was this always incorrect markup?

5

markdownify was never a requirement in Hugo templates, it simply:

Runs the provided string through the Markdown processor.

Markdown and HTML are both acceptable content file formats in Hugo, HTML files do not get processed by the Markdown processor and Markdown files can contain raw HTML syntax if the unsafe flag is provided in a project’s config.

Also {{ .Content | markdownify }} is not an incorrect construct per se, it all depends on the project’s context.

6

Sure - we have plenty of other templates that do pass individual chunks of data (from with, or range, etc) into markdownify. The problematic ones seem to be the ones where the entire .Content derived from a .md file was being processed twice.