Summary generated with explicit <!--more--> tag is wrapped in unnecessary <p> tag
While automatically generated summaries are fine and generated without extraneous <p> tag.
The behavior of whether to wrap in <p> tags should be consistent. Otherwise the layout of homepage becomes chaotic/non-symmetric due to inconsistent <p> tags.
Here's some test functions from the existing code that confirms the same:
Please look at inconsistent <p> tags in the following snippets:
1. checkPageSummary(t, p, "<p>Summary Next Line</p>\n")
2. checkPageSummary(t, p, "Summary Next Line. . More text here. Some more text")
file hugolib/page_test.go
func TestPageWithDelimiter(t *testing.T) {
...
checkPageTitle(t, p, "Simple")
checkPageContent(t, p, "<p>Summary Next Line</p>\n\n<p>Some more text</p>\n")
checkPageSummary(t, p, "<p>Summary Next Line</p>\n")
...
}
func TestPageWithShortCodeInSummary(t *testing.T) {
...
checkPageTitle(t, p, "Simple")
checkPageContent(t, p, "<p>Summary Next Line. \n<figure >\n \n <img src=\"/not/real\" />\n \n \n</figure>\n.\nMore text here.</p>\n\n<p>Some more text</p>\n")
checkPageSummary(t, p, "Summary Next Line. . More text here. Some more text")
...
Original Discussion Thread: http://discuss.gohugo.io/t/summary-generated-with-explicit-more-tag-is-wrapped-in-unnecessary-p-tag/1345
I've noticed the same issue using highlight shortcodes, the <pre> block is wrapped in <p> tags, which shouldn't be happening.
@EMarshal related, maybe, but a different issue.
Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.
If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
Is this not going to be addressed?
This issue still exists in v0.24.1
Confirmed that this seems to still be true with 0.53, was just about to open an issue for it. This makes it very hard to write formatting for a list that wants to use .Summary, because only some articles have the paragraph tags around the summary.
Okay, so, looking at this, I can't tell which behavior is the bug. As a user, I would strongly prefer the behavior from the auto summary case.
When a user-defined summary delimiter is found, Hugo splits the text around that delimiter after markup has been converted to HTML. Thus, for the example in page_test.go, the original source is markdown or something like that, but by the time setUserDefinedSummary is called, we have HTML.
If no user-defined summary is found, Hugo generates "plain" text so the word count will make sense, and converts it to HTML without any additional markup. Thus, no p or div tags added around the content.
As noted in the workaround pull above, this makes it impossible for something with a user-defined summary to have inline content follow it. You can't make {{ .Summary }}... work, because the "..." will be in a new paragraph.
But either way, you currently can't make something that produces good results for both cases, so it's almost certainly a bug.
A workaround: wrap the summary in another element, and set display:contents to both that element and element > p. This will render consistently regardless of whether or not the p is there.
div.no-p {
display: contents;
}
div.no-p > p {
display: contents;
}
In the template:
<div class="no-p">{{- .Summary -}}</div>
Browser support is thin as of this writing.
This issue still exists in Hugo v0.75.1. Really wish there was a way to fix this without relying on CSS...
Most helpful comment
Okay, so, looking at this, I can't tell which behavior is the bug. As a user, I would strongly prefer the behavior from the auto summary case.
When a user-defined summary delimiter is found, Hugo splits the text around that delimiter after markup has been converted to HTML. Thus, for the example in
page_test.go, the original source is markdown or something like that, but by the timesetUserDefinedSummaryis called, we have HTML.If no user-defined summary is found, Hugo generates "plain" text so the word count will make sense, and converts it to HTML without any additional markup. Thus, no p or div tags added around the content.
As noted in the workaround pull above, this makes it impossible for something with a user-defined summary to have inline content follow it. You can't make
{{ .Summary }}...work, because the "..." will be in a new paragraph.But either way, you currently can't make something that produces good results for both cases, so it's almost certainly a bug.