I have a partial that provides a preview of a blog post.
I’m using the .Summary variable to provide a preview of the blog post.
None of markdown is rendering. I just get a big long string with the paragraphs and headings mashed together.
As you can see, I’m trying to use the markdownify function to render the markdown, but it doesn’t seem to be working.
It works with or without markdownify if I swap .Summary in for .Content. I’m not sure what I’m missing about how .Summary is different from .Content? Shouldn’t .Summary basically just be .Content but shorter and no images?
Regardless of which summary method you use, do not pass it through markdownify.
The easiest way for you to have markdown in summary not stripped of tags is to use manual summaries, by placing <!---more--> to identify where the summary should end.
---
title: This is a Blog Post
date: 2023-03-01T09:52:19-06:00
draft: false
---
# This is a heading.
Consectetur consequatur magnam vitae omnis magni tenetur, perferendis ut, animi! Sed quisquam dolor dolorum tempora eum, deserunt earum Iure maiores maiores facere iste aspernatur, sint ipsum vero Laboriosam molestias ducimus nulla veniam atque. Harum voluptate maiores earum omnis reiciendis illo.
<!--more-->
Got it. That does fix it, but it is less than ideal as I’d rather be able to let the summary length be chosen automatically.
Now that I understand what’s happening, I have done some more thinking and I will probably instead start using {{ .Content | truncate 500 }} and in my CSS I can do:
.summary img {
display: none;
}
to strip out the images. That way I don’t have to worry about <!--more--> tags and neither will any content authors.
Would it be worthwhile for me to submit a pull request to add the table in your github issue to the docs page for content summaries? I don’t feel like it’s addressed anywhere in the docs. It certainly had me scratching my head.
I would prefer an issue over a PR. And I agree the existing documentation for this topic needs some love.
As an aside, I always define both description and summary in front matter. Why?
The description is used for meta data, is short, and has a call to action, whether implicit or explicit. I think most people spend 1 second, maybe less, when deciding whether or not a search result is worth their time. These take a long time to write, even though they’re short (15 word-ish).
The summary is used on a list page. It’s a teaser that can stand on it’s own, without requiring additional context. More detail than the description, with an explicit call to action, even if it’s just “Learn more.” These also take some thought/time.
The problem with automatic summaries is that first paragraph of an article is almost never a good choice for either search results or a teaser.
But writers get lazy, relying on the first paragraph instead of putting in the time to optimize a meta description or teaser, and this is a huge mistake. We want readers to click on the search result, read the teaser, and click again to get to the full thing (whatever that is).
Creating an “init” partial that is only called by the home page, we can range through all of the pages and throw a warning or error if description and/or summary is missing in front matter.
I also chose this approach. Had to do it manually for 200 posts at the time since the WP SEO plugin fields were not copied over to the front matter. It’s more efficient and its pros outweigh the cons.
On top of list pages, I also use the Summary for RSS fields. Hence, defining it manually via the front matter helps.