Netlify-cms: Markdown works in Content Editor, displays un-parsed on my site

[edadams]

- Do you want to request a feature or report a bug?
Suspected bug.

- What is the current behavior?
I can type Markdown in the Content Editor but it is not being parsed on my compiled site. The unparsed Markdown is being outputted on my site instead.

- If the current behavior is a bug, please provide the steps to reproduce.
In my Netlify CMS config.yml file, I've set name: 'body', widget: 'markdown' as per the docs.

- What is the expected behavior?
The Markdown should be parsed, bold, italics, etc.

- Please mention your versions where applicable.

Netlify CMS version: 1.9.2
Browser version: Chrome 67

Node.JS version: n/a
Operating System: n/a

- Please link or paste your config.yml below if applicable.

Config file is very long so it can be found in full here (lines 28-30). Relevant section included below:

          - {label: "Text Area", name: "textbox", widget: "object", fields: [
              {label: "Title", name: "title", widget: string},
              {label: "Body", name: "body", widget: markdown}]} 

This is the partial. The title, which is a simple string, is outputted correctly.

This is my test site on Netlify. As you can see about half way down the page after it loads, the Markdown code displays unparsed. This is my repo.

I've read in the Netlify CMS docs for the Markdown widget that the field with Markdown must be called body, which mine is.

I'm very new to Netlify CMS so I'm probably getting something wrong... Thank you! 👍

[tech4him1]

There are a few things here that need to be clarified, but thank you so much for providing all the links -- it makes it way easier to debug!

On the CMS side, body is only special if it is a top-level widget in the markdown file (i.e. not nested under another object like textbox). If it is top-level, it gets put into the body of the markdown file, not the frontmatter. Otherwise, body doesn't mean anything. There is no difference in markdown parsing that occurs either way, simply a location difference.

On the Hugo side of it, anything that is in the markdown file body get's parsed to HTML and put into the .Content page variable. Frontmatter values (like your textbox.body, do not get parsed at all unless you specifically do it yourself (i.e. {{ .textbox.body | markdownify }}).

As always, if you think we could change the wording in the docs to be more clear, please submit a PR!

[edadams]

Thank you so much, @tech4him1! I've added the markdownify filter and my Markdown is parsed as expected. 😄

This isn't a bug but I feel the docs are unclear about needing to use this filter or .Content to actually parse Markdown. For every other widget that I've tried, I've just been able to call its frontmatter value which is why I didn't consider it might be different.

Given that I started working with both Netlify and Hugo only yesterday I don't think I should do that PR just yet, but I'd quite like to in the future.

I still have some confusion on what it means to be a top-level Markdown widget versus nested in frontmatter. I'd appreciate you elaborating on that if possible...

My use case here is an _About Us_ text section on a client's homepage, surrounded by other sections but not the sole focus. In this case, the text section is not the entire content of the page (like it would be in a blog post). I'm not sure if it would be better to store my Markdown as a top-level widget or nested. I guess my question stems from me not understanding the difference between the two - if there are any.

I did try changing my partial to <div class="text-block-body">{{ .Content }}</div> but then my Markdown didn't display at all. I'm guessing that's because my Markdown is currently nested and not stored as top-level. the moment is nested and not top-level. Am I correct?

Thanks again. :+1:

[tech4him1]

This isn't a bug but I feel the docs are unclear about needing to use this filter or .Content to actually parse Markdown. For every other widget that I've tried, I've just been able to call its frontmatter value which is why I didn't consider it might be different.

Given that I started working with both Netlify and Hugo only yesterday I don't think I should do that PR just yet, but I'd quite like to in the future.

The reason the Netlify CMS docs don't mention it is because it is a Hugo-specific detail that markdown in frontmatter is not parsed by default. You would need to use different settings for different site generators, and some will parse markdown in frontmatter by default. It varies so much that the most we could add would be a reminder to check your site generator's documentation. If there is a way you think we can clearly note that, feel free to create a PR now!

I still have some confusion on what it means to be a top-level Markdown widget versus nested in frontmatter. I'd appreciate you elaborating on that if possible...

Ambiguous? 🙄 I just made the term up myself. All I mean by top-level is that it is a field in the CMS config is directly on the file or folder, not nested under a list or object widget.

My use case here is an _About Us_ text section on a client's homepage, surrounded by other sections but not the sole focus. In this case, the text section is not the entire content of the page (like it would be in a blog post). I'm not sure if it would be better to store my Markdown as a top-level widget or nested. I guess my question stems from me not understanding the difference between the two - if there are any.

I would probably do it like you have it set up -- in the front-matter.

I did try changing my partial to <div class="text-block-body">{{ .Content }}</div> but then my Markdown didn't display at all.

Exactly, .Content points to the body of the markdown file -- below the frontmatter.

Thanks again. :+1:

No problem, hopefully I didn't make it more confusing! 😃

[edadams]

All I mean by top-level is that it is a field in the CMS config is directly on the file or folder, not nested under a listor objectwidget.

This has cleared it up for me. When you said "top-level" you mean it's... at the highest level of the config file. I'm not sure why this wasn't clicking for me before but it is now.

I'll get started on trying to write that PR then! Thanks one last time. Closing this issue as my issue is properly resolved now.