"url: /stuff/captive/captive.htm" behaviour different after Hugo v0.122.0

support
1

I have the following URL generated via Hugo:
https://www.snoogans.co.uk/stuff/captive/captive.htm

All other posts use pretty URL’s, so I have not set “uglyURLs: true”.

It is only this one URL that requires this specific URL format/file extension.

For historical reasons, the requirement is to ensure the URL and image/file paths do not change. I don’t want to add any redirects.

The file config is as follows:

File:
content/posts/captive/index.md

Front matter:

---
title: "Captive"
url: /stuff/captive/captive.htm
type: posts
date: 2022-10-30T11:22:00+00:00
description: Archive of various tips and tricks for the "Captive" computer game. Design, programming and graphics by Antony Crowther. Published by Mindscape in 1990.
menu:
  sidebar:
    name: Captive
    weight: 1
hero: images/captive.gif
sitemap:
  priority: 0.7
  changeFreq: weekly
---

In Hugo versions v0.122.0 and below, this would generate the desired result, as seen in the current live site and here:

https://github.com/eishundo/site-www.snoogans.co.uk/tree/gh-pages/stuff/captive

That is:

/stuff/captive/files/
/stuff/captive/images/
/stuff/captive/jscript/
/stuff/captive/captive.htm

However, in versions higher than v0.122.0, it creates the following directory structure (additional “captive” subdir is created containing the images/files/jscript directories, but not the captive.htm file):

/stuff/captive/captive/files/
/stuff/captive/captive/images/
/stuff/captive/captive/jscript/
/stuff/captive/captive.htm

This means all the links required for images/files/jscript are different which is not desired.

I can almost solve this by leaving the front matter as-is, but moving the file to:

content/stuff/captive/captive.md

However, the hero image can no longer be found and it instead falls back to the default/stock hero image instead of:

---
hero: images/captive.gif
---

Currently testing via:

$ hugo env                                                                             
hugo v0.123.7+extended linux/amd64 BuildDate=unknown
GOOS="linux"
GOARCH="amd64"
GOVERSION="go1.22.0"
github.com/sass/libsass="3.6.5"
github.com/webmproject/libwebp="v1.3.2"

Thanks in advance,
eishundo

2

Have you tested with v0.125.6?

3

I haven’t, no. I’m using Manjaro packages which haven’t updated yet. I could compile locally and try if you think it may help?

I’ve been following the release notes and haven’t seen anything related to this issue.

I wasn’t sure if this is a bug or related to some of the breaking changes introduced in 0.123.0 that means I need to restructure the config in some way. I also haven’t seen anyone else report a similar issue (here or on GitHub).

4

To summarize…

Your content structure looks like this:

content/
├── posts/
│   ├── captive/
│   │   ├── files/
│   │   │   └── a.txt
│   │   ├── images/
│   │   │   ├── a.jpg
│   │   │   └── captive.gif
│   │   ├── jscript/
│   │   │   └── a.js
│   │   └── index.md
│   └── _index.md
└── _index.md

With v0.122.0 your published site has this structure:

public/
├── posts/
│   └── index.html
├── stuff/
│   └── captive/
│       ├── files/
│       │   └── a.txt
│       ├── images/
│       │   ├── a.jpg
│       │   └── captive.gif
│       ├── jscript/
│       │   └── a.js
│       └── captive.htm
├── favicon.ico
└── index.html

With v0.123.0+ your published site has this structure:

public/
├── posts/
│   └── index.html
├── stuff/
│   └── captive/
│       ├── captive/
│       │   ├── files/
│       │   │   └── a.txt
│       │   ├── images/
│       │   │   ├── a.jpg
│       │   │   └── captive.gif
│       │   └── jscript/
│       │       └── a.js
│       └── captive.htm
├── favicon.ico
└── index.html

Is all of that correct?

If yes, see https://github.com/gohugoio/hugo/issues/12472.

5

That’s about it, yes.

Thanks for raising the issue in GitHub.

I won’t get chance for a few days but will see if I can confirm if the issue occurs only when using .htm extension vs .html.

If there are any issues reproducing the problem, I can take a look at cloning my repository and making it available for testing.

6

Already tested… makes no difference.

Thanks, but it’s trivial to reproduce.

Also note that, while the current behavior is different than it was in v0.122.0, I’m not convinced it’s wrong. The current behavior prevents asset collisions; the old behavior did not.

I’m not really sure what you’re doing, and I don’t want to know, but you might consider moving the assets to the same path within the static directory for this one page that needs an ugly URL. I use this approach for a collection of sample files.

In the interest of tracking forum topics related to v0.123.x that do not have a corresponding GitHub issue, I am marking this resolved.

7

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