Add sensible fallback for permalink :token when not backed by a file

[jmooring]

WARN 2023/02/17 09:40:41 .File.TranslationBaseName on zero object. Wrap it in if or with: {{ with .File }}{{ .TranslationBaseName }}{{ end }}

This is not a new warning; it exists as far back as v0.55.4, but does not exist in v0.54.0 (I didn't test those in between).

And the warning makes sense. But it took me a couple of minutes to figure out what was causing it.

[permalinks]
tags = "/foo/:filename/"

With this content structure:

content
├── post/
│   └── test.md
└── _index.md

Where content/post/test.md has:

tags = ['tag-a']

This is obviously resolved with:

content/
├── post/
│   └── test.md
├── tags/
│   └── tag-a/
│       └── _index.md   <-- now there's a file
└── _index.md

This was a self-inflicted wound; I'm not even sure what the user was trying to accomplish.

Although the warning message is accurate...

1. The user wasn't able to identify the cause.
2. The resulting URL is http://localhost:1313/foo/ instead of http://localhost:1313/foo/something

I'm not sure if this is just a documentation issue, or if we should substitute the slug when there isn't a backing file (if that's even possible) and throw a more descriptive warning.

MRE

git clone --single-branch -b hugo-github-issue-9448 https://github.com/jmooring/hugo-testing hugo-github-issue-9448
cd hugo-github-issue-9448
hugo server

[bep]

We should try to pick a sensible fallback to the filename in this case, I'm not sure what (I have not looked at the options).

[jmooring]

The ".File.TranslationBaseName on zero object" warning will be seen more frequently as users begin to define permalinks for sections (#10847). I think we need fallbacks for:

:title
:slug
:slugorfilename
:filename

Example config:

[languages.de.permalinks.term]
tags = 'my-tags-de/:slug'

[bep]

@jmooring thanks, I merged that permalink issue knowing that it needed some tweaking/testing. The gist of the above is that we should never see that warning from Hugo code.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.