Misc fixes and improvements

[bep]

This is 4 separate and (mostly) related commits. See the commit messages for details.

The one thing that may need some explaining is the addition of kind, path and lang as front matter keys, and the consolidation of the page configuration into this struct:

type Dates struct {
	Date        time.Time
	Lastmod     time.Time
	PublishDate time.Time
	ExpiryDate  time.Time
}

// PageConfig configures a Page, typically from front matter.
// Note that all the top level fields are reserved Hugo keywords.
// Any custom configuration needs to be set in the Params map.
type PageConfig struct {
	Dates                   // Dates holds the fource core dates for this page.
	Title          string   // The title of the page.
	LinkTitle      string   // The link title of the page.
	Type           string   // The content type of the page.
	Layout         string   // The layout to use for to render this page.
	Markup         string   // The markup used in the content file.
	Weight         int      // The weight of the page, used in sorting if set to a non-zero value.
	Kind           string   // The kind of page, e.g. "page", "section", "home" etc. This is usually derived from the content path.
	Path           string   // The canonical path to the page, e.g. /sect/mypage. Note: Leading slash, no trailing slash, no extensions or language identifiers.
	Lang           string   // The language code for this page. This is usually derived from the module mount or filename.
	Slug           string   // The slug for this page.
	Description    string   // The description for this page.
	Summary        string   // The summary for this page.
	Draft          bool     // Whether or not the content is a draft.
	Headless       bool     // Whether or not the page should be rendered.
	IsCJKLanguage  bool     // Whether or not the content is in a CJK language.
	TranslationKey string   // The translation key for this page.
	Keywords       []string // The keywords for this page.
	Aliases        []string // The aliases for this page.
	Outputs        []string // The output formats to render this page in. If not set, the site's configured output formats for this page kind will be used.

	// These build options are set in the front matter,
	// but not passed on to .Params.
	Resources []map[string]any
	Cascade   map[page.PageMatcher]maps.Params // Only relevant for branch nodes.
	Sitemap   config.SitemapConfig
	Build     BuildConfig

	// User defined params.
	Params maps.Params
}

I think the above should be complete. Note that

1. Use cases for kind, path and lang in front matter may be rare, but this is mostly a preparation for other data formats.
2. None of these can currently be set in cascade.
3. I have renamed the _build to build (but both will work).

[jmooring]

None of these can currently be set in cascade.

To clarify, "these" refers to kind, path, and lang. For example, type and layout may be set in cascade.

[jmooring]

For the release notes...

Anyone who has been ignoring the ".Path when the page is backed by a file is deprecated" warning for the past two years (since v0.92.0) may encounter what they consider to be a breaking change.

v0.122.0: .Page.Path →posts/post-1.md
v0.123.0: .Page.Path →/posts/post-1

The value returned by .Page.File.Path (which the warning message recommends) remains the same (e.g., posts/post-1.md).

[jmooring]

type Dates struct {
	Date        time.Time
	Lastmod     time.Time
	PublishDate time.Time
	ExpiryDate  time.Time
}

I was expecting that I'd be able to do {{ .Dates.Lastmod }}. Is that incorrect?

can’t evaluate field Dates in type page.Page

[bep]

To clarify, "these" refers to kind, path, and lang. For example, type and layout may be set in cascade.

Yes, I was a little quick: This refers to kind, path, and lang only (the new values).

[jmooring]

This is a bit contrived, but...

content/
└── posts/
    └── post-1/
        ├── index.md
        ├── my image.jpg
        └── my-image.jpg

The table below shows the value returned by .RelPermalink.

	.Resources.Get "my-image"	.Resources.Get "my image"
v0.122.0	/posts/post-1/my-image.jpg	/posts/post-1/my%20image.jpg
this PR	/posts/post-1/my-image.jpg	indeterminate

By indeterminate I mean: sometimes it finds the resource, and sometimes it does not (i.e., .Resources.Get returns nil).

FYI, there are a couple of open issues related to case-sensitivity when matching resource filenames:

• Upper case letters in path causing match to fail #7686
• resources.Match is always returning lower case paths #10112

[bep]

This is a bit contrived, but...

I'm pretty sure that case is documented somewhere in my issues, but given this bundle:

mybundle/index.md
mybundle/Foo Bar.txt

The new canonical content paths for the two resources above is:

/mybundle
/mybundle/foo-bar.txt

WIth that, this list:

mybundle/index.md
mybundle/index.html
mybundle/Foo Bar.txt
mybundle/foo bar.txt
mybundle/foo-bar.txt

Will still only produce 1 bundle with 1 resource. We have some deduplication and ordering of content files, but for the resources, when you have duplicates, which one you end up with is undefined.

[jmooring]

but for the resources, when you have duplicates, which one you end up with is undefined.

We detect page collisions (--printPathWarnings). Is there any way to detect resource collisions and warn or error, preferably without having to use a CLI flag?

What was bothersome was the inconsistent behavior from one build to the next; sometimes it finds a resource, sometimes it does not.

[bep]

Is there any way to detect resource collisions and warn or error, preferably without having to use a CLI flag?

Maybe, but it's not in scope for this PR.

What was bothersome was the inconsistent behavior from one build to the next; sometimes it finds a resource, sometimes it does not.

I have never seen this issue in the wild. This very minor path normalisation is done with good intent: We already merge content from many files sources with different languages etc. Imagine when we add content from JSON, WordPress, SQL, whatnot. We need less ambiguity/complexity to prepare for ... more complexity.

[jmooring]

I've tested what I can think of. My only remaining question is...

I was expecting that I'd be able to do {{ .Dates.Lastmod }}. Is that incorrect?

[bep]

I was expecting that I'd be able to do {{ .Dates.Lastmod }}. Is that incorrect?

That is incorrect. The PageConfig struct is internal and not accessible directly in the templates.