Potential regression between 0.132 and 0.134

support
1

In Hugo 0.134, a blog post that has the following content:

![Morning group check-in](checkin.png)

Now produces a public/index.html file that has:

<img src="checkin.png" alt="Morning group check-in">

(instead of /full/path/to/checkin.png)

This used to work under 0.132, so I’m wondering if it is considered a regression?

2

It should render to:

<img src="checkin.png" alt="Morning group check-in">

I’m not sure why you expect a different image path. Perhaps you had an image render hook that did something different, or you added an image render hook, or something.

As always, a link to your repository would simplify troubleshooting, and save us both some time.

3

This is the repo:

Here is the issue tracking the problem:

I expect a different path, because the site index file is in a different folder from the blog post.

4

I built your site with v0.132.0.

Then I browsed to http://localhost:1313/scientific-python/dev-summit-1/.

Then I opened the browser’s dev tools to inspect the HTML.

image
image871×187 100 KB

5

OK, I just rebuilt using 131, 132, and 134, and it looks like the difference is in the way the post summary is generated (completely different summaries under 131/132 vs 134).

0.132:

v0.132 summary

0.134:

v0.134 summary
v0.134 summary390×623 44.2 KB

6

https://github.com/gohugoio/hugo/releases/tag/v0.134.0

But the change in .Summary rendering has no impact on the rendering of markdown image to HTML.

7

No, the reason it fails our CI is that, before, the image was not included in the summary.

8

Add this to your site config:

markup:
  goldmark:
    renderHooks:
      image:
        enableDefault: true
      link:
        enableDefault: true

This will resolve image and link destinations relative to the host root.

You could pass .Summary through the plainify function, but that won’t solve the problems with your atom feeds.

9

Thanks, I’ll try that.

From the release notes, it’s not immediately apparent to me why .Summary would be substantially different from before. Is this expected?

10

Yes, this is expected, and very desirable.

11

At first I thought the cut-off points got modified, but it looks like only the type returned was changed (to HTML). I think we can address that on our end by adding appropriate summary markers, so it will cut off earlier.

12

Great idea. In my view, relying on an “automatic” summary is unwise. I would always define the summary using the <!--more--> tag, or by defining a summary field in front matter.

13

Make sure you make the config changes I mentioned to correct the problems with your atom feeds, which you probably weren’t aware of.

1 Like
14

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.