Rendering links in Hugo projects using Cloudcannon’s Rich Text Editor

Showcase
1

Using Cloudcannon with Hugo? Struggling to render links in your content using Cloudcannon’s Rich Text Editor? You may find this post helpful.

The problem is that Cloudcannon’s link option inserts HTML into markdown. However, Goldmark – the markdown engine used by Hugo – disallows HTML in Markdown files, by default. This prevents links from rendering as expected.

The simple solution is to add the following two lines to your hugo.toml config file:

# Allow HTML in markdown (use with caution)
[markup.goldmark.renderer]
unsafe = true

Just remember to use with caution, as content editors now have the power to insert HTML in pages.

12 Likes
2

:folded_hands: Thanks for the tip! This is a fairly common support question when setting up a Hugo site on CloudCannon, and it’s great to see it mentioned here with the solution.

In many other SSGs, using raw HTML in Markdown files is enabled by default. It’s not much of a safety barrier here as someone could add HTML to non-Markdown files regardless. It’s also worth noting our Rich Text Editors don’t allow arbitrary HTML unless configured through Snippets or the embed option.

Here’s some context: we’ll save links in Markdown format wherever possible, but as you’ve found, they’re sometimes saved as HTML.

Links in Markdown output to anchor <a> elements in HTML, and anchor elements have attributes that sometimes cannot be preserved using Markdown alone. Users can add these attributes to links during editing.

Here’s an example anchor element that opens in a new tab/window, has a title hover-tooltip, and tells the browser not to send the Referer header:

<a href="https://cloudcannon.com/"
   title="The CloudCannon home page"
   target="_blank"
   rel="noreferrer">CloudCannon</a>

:hugo: Standard CommonMark-style (which Hugo/Goldmark is based on) has no way to keep the attributes other than title, so saving it as Markdown would remove them:

[CloudCannon](https://cloudcannon.com/ "The CloudCannon home page")

For those not using Hugo: :jekyll: Kramdown, :11ty: markdown-it (with extension), and other Markdown processors support attribute lists, meaning we can preserve these attributes here without falling back to HTML. CloudCannon supports several Markdown attribute list formats as well.

[CloudCannon](https://cloudcannon.com/ "The CloudCannon home page"){: target="_blank" rel="noreferrer" }

If attribute lists are not available, and links have attributes that would otherwise be lost, we save them as HTML within the Markdown file.

9 Likes
3

Thanks for these insights Ross, this is helpful to know. I will update my post to make this clear.

4 Likes
4

Hi, Hugo user here. It would be awesome if we could disable these additional link attributes in the UI. Sometimes I’d like to make sure, an editor just produces plain Markdown.

Or is there a configuration already I missed? Also talked to @Tom_Richardson about that a while ago.

2 Likes
5

We agree! There are a couple of plans in the pipeline :test_tube: that sound relevant here, pending timeframe and final planning.

For context: there are other places where your Markdown settings could result in HTML, including (not limited to):

  • Tables (often unsupported in CommonMark-based Markdown engines unless HTML).
  • Images (width and height attributes with the image_size_attributes option enabled).
  • Custom styles/classes with attribute lists disabled.
  • Superscript, subscript and strikethrough without associated options enabled.

It’s been a safe default to fall back to HTML to cover these cases, where otherwise the data would be lost. We’ve found a surprising number of differences between different Markdown engines, even those that are based on CommonMark.

:one:
We have plans to implement: a markdown.options.html option (enabled by default) when configuring your Markdown engine:

  • If enabled, all configured interfaces remain enabled if they could result in HTML (the current behavior).
  • If disabled, we’d hide/disable any interface that would allow content that creates HTML in your file (e.g. “Open link in a new tab/window”). This would match Hugo’s unsafe: false.

:two:
We also have plans to offer: _inputs configuration on the standard link controls pop out seen within the Content Editor, Editable Regions and Rich Text Inputs (for example, hiding “Open link in a new tab/window”, or adding a comment to “URL”).

image
image423×585 11 KB

:information_source: It would be inconvenient to override the default _inputs configuration for each standard pop out though if limiting HTML in Markdown files is your goal, but I thought this could be worth mentioning anyway.

:speech_balloon: Would love to hear either of these sound helpful, or any other feedback you might have!

7 Likes