Flag indicating manual vs auto summary generation

I love the ability to split a blog post into the .Summary and more content. I dislike the unformatted automatically generated summary when I haven’t explicitly used

On my home page, I want to show the .Summary and a [Read more…] link if I manually split the post. But, if I did not manually split the post, I want to show the whole thing, well formatted, with no [Read More…]

I think I’m looking for a variable like the (made up) .ManuallyTruncated in the following snippet:

{{ if .ManuallyTruncated }}
  {{ .Summary }}
  <div class="read-more-link">
    <a class="pure-button" href="{{ .RelPermalink }}">Read More…</a>
  </div>
{{ else }}
  {{ .Content }}
{{ end }}

Is there a way to do this?

If not, what’s the best way to submit a feature request?

A config setting that suppressed automatically generated summaries would also work well. In that case .Truncated would not be set unless was used in the post.

I can see the use of something like this myself, but that is typically for very short posts where it’s naturally to show everything on the home page.

But what works for me is to just leave the <!--more--> with nothing below it.

The .Summary then becomes all the content, and .Truncated returns false.

GitHub is the place for feature request, but I’m not totally convinced …

The fact that both of the current methods assume you want the very top of your content down to either an automatically set point (summary) or a manually set point (read more code), is the problem in my eyes. What if you want more granularity?

I’d like to be able to mark the text for summary with some kind of “start-summary” and “end-summary” tags.

1 Like

@bjornerik: I could use that idea if it worked, but unfortunately, when I put < !–more–> (with no space) at the end of the content post markdown file, the .Truncated still returns true.

Hugo Static Site Generator v0.14-DEV BuildDate: 2015-05-05T18:03:09-07:00

So, I have a hundred more posts to go through manually, finding an appropriate breaking point. Unless we think that the .Truncated might get fixed when there is no following content, or an option will be added to not auto-generate summaries.

@esh - both of your suggestions are really easy to implement, create a GitHub issue with your “most prefered” choice.

I will also fix .Truncated.

The .Truncated fix works great, thanks!

I’m not going to create a feature request, because this approach seems like it would be easy enough for most purposes and I’d rather not clutter variables and config options unless they’re really valuable.

I’m not happy with current behavior.
Adding <!--more--> into every post doesn’t look like the right way to go for me.

If you write mostly long posts, than it seems OK to add <!--more--> into archetype file.

If I expect to have mostly short posts, I do not want to clutter them with meaningless markup.

In the current situation, all I can do is to define additional parameter in front matter of the posts where I need to use <!--more--> and put this into template:

{{ if .Params.withsummary }}
  {{ .Summary }}
{{ else }}
  {{ .Content }}
{{ end }}

Other solution is to put all summary text into front matter parameter, when needed, and use it like this:

{{ if .Params.postsummary }}
  {{ .Params.postsummary | markdownify }}
{{ else }}
  {{ .Content }}
{{ end }}

P.S.:
First I was thinking about when faced with this issue: there should be the way to switch default summary generation behavior through a variable in site config. Not sure if it is a good idea, since current method of summary creation is not flexible enough anyway.

After a bit more thinking on this:

Current behavior is bad designed, because it’s conflicting with principle of least astonishment. In some cases you get fancy markdown and in other cases you get ugly flattened text as output. Very frustrating.

Use case: post list in blog. I need to show posts in a fancy way, and still being able to cut them when needed.

Use case: archive/sitemap or feed of announcements. I need a flattened text of given length.

Solution as I see it:

  • .Summary or .TruncatedContent or something like that - returns full content or part of it before <!--more-->;

  • Function, similar to Render, that returns flattened text of given length in words or symbols.

Still not solved an issue when people need more control on what part of a post should be cut. After using PmWiki for a while, I get used to idea of marking up ranges of content and accessing them by names. Not sure how it will work on top of markdown. Something like <!--range mysummary start--><!--range mysummary end-->.

Quite a timely post, I just raised an issue regarding summaries, a couple of days ago [see below].

Being a lazy git*, I’m quite happy to leave {{ .Summary }} to do it’s thing for the most part, rather than have the additional hassle of manually truncating posts. But I think it could be a bit ‘cleverer’ about what it includes.

[* pun unintentional]