Companion page-bundle HTML files not being copied to subfolder of output directory anymore

in content/opinions/peribreakpoints, I have the following files:

after.html
before.html
index.md
peribreakpoints-after-dark.png
peribreakpoints-after-dark.webp
peribreakpoints-after-light.png
peribreakpoints-after-light.webp
peribreakpoints-before-dark.png
peribreakpoints-before-dark.webp
peribreakpoints-before-light.png
peribreakpoints-before-light.webp

Normally, everything shows up on the site, including after.html and before.html. However, after running hugo for the first time in a long time, after.html and before.html aren’t getting copied to the directory where they usually get copied to anymore. This means that people who visit those pages are getting 404s now.

This is what hugo version gets me:

hugo v0.123.3-a75a659f6fc0cb3a52b2b2ba666a81f79a459376+extended darwin/arm64 BuildDate=2024-02-23T17:09:20Z VendorInfo=brew

In index.md, I’m using the simplest links in my Markdown file that could possibly work β€” <a href='before.html'>. It’s in a <figure>, so it’s not like I can use a Markdown-style link:

<figure>
    <a href='before.html'>
        <picture>
            <source srcset='peribreakpoints-before-dark.webp'
                    media='(prefers-color-scheme: dark)'
                    type='image/webp'>
            <source srcset='peribreakpoints-before-light.webp'
                    media='(prefers-color-scheme: light)'
                    type='image/webp'>
            <source srcset='peribreakpoints-before-light.png'
                    media='(prefers-color-scheme: light)'
                    type='image/png'>
            <img src='peribreakpoints-before-dark.png' alt='A screenshot of a browser displaying the need for a peribreakpoint'>
        </picture>
    </a>
    <!-- … -->

I had a look at Build options | Hugo and I don’t appear to need any special build settings to reenable this sort of behavior. I don’t have a build thing in my YAML front matter, and the default for publishResources is true, anyway. I also had a look at Page resources | Hugo and it’s not obvious that I’ve missed something.

…does anyone have any idea why after.html and before.html aren’t getting copied to public/ like they used to?

Thanks in advance.

TLDR: The new behavior is expected/as-designed.

Example

Let’s use the following example to see the difference between v0.122.0 and v0.123.0.

content/
└── p1/
    β”œβ”€β”€ a.jpg
    β”œβ”€β”€ b.html
    β”œβ”€β”€ c.md
    └── index.md

v0.122.0 (incorrect)

Available as a page resource Published (copied to public)
content/p1/a.jpg :heavy_check_mark: :heavy_check_mark:
content/p1/b.html :heavy_check_mark: :heavy_check_mark:
content/p1/c.md :heavy_check_mark: :x:

v0.123.0 (correct)

Available as a page resource Published (copied to public)
content/p1/a.jpg :heavy_check_mark: :heavy_check_mark:
content/p1/b.html :heavy_check_mark: :x:
content/p1/c.md :heavy_check_mark: :x:

Explanation

In v0.122.0 and earlier we inconsistently handled page resources with ResourceType = page. As shown in the v0.122.0 example above, we did not copy c.md, but we did copy b.html. That inconsistent behavior was fixed in v0.123.0.

I understand that some site authors took advantage of this inconsistent and undocumented behavior to blindly copy HTML files when building the site. That, obviously, is no longer possible. Here are your options going forward.

Option A – Use the static directory

static/
└── p1/
    └── b.html

Option B – Use the Publish method

layouts/_default/single.html

1) This will publish all page resources with ResourceType = page.

{{ range .Resources.ByType "page" }}
  {{ $publishPath := urls.JoinPath $.RelPermalink .Name }}
  {{ (.Content | resources.FromString $publishPath).Publish }}
{{ end }}

2) This will publish all page resources with an html extension:

{{ range .Resources.Match "**.html" }}
  {{ $publishPath := urls.JoinPath $.RelPermalink .Name }}
  {{ (.Content | resources.FromString $publishPath).Publish }}
{{ end }}
1 Like

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