When a template calls the .Translations function and a
Hugo environment is using multiple output formats,
a template that calls methods like .Summary and .Len on
each translation will unexpectedly show empty return
values for these methods.
This is because each pageOutput's ContentProvider is
assigned to a page.NopPage in newPageOutput. When
*HugoSites.render assigns pageContentOutputs to
pageOutputs in *pageState.shiftToOutputFormat, it
reuses pageContentOutputs from other pageOutputs,
leaving some pageContentOutputs as NopPages. While this
approach conserves resources, sometimes it means that
a template will unexpectedly call a method on a
pageContentOutput that is actually a NopPage.
In the case of ContentProvider methods called on
translations for alternative output formats, the methods
were called on NopPages.
This change introduces LazyContentProvider, which
performs late initialization when one of its methods is
called. This way, we can reuse content in "normal" cases
but ensure that ContentProvider methods work as expected
when a pageOutput is not assigned a pageContentOutput
during the initial pre-render phase.
Fixes#8919
In page.NewOutputFormat, we take an output.Format f and use it to
create a page.OutputFormat. If the format is canonical, we assign
the final OutputFormat's Rel to "canonical" rather than using
f.Rel. However, this leads to unexpected behavior for custom
output formats, where a user can define a "rel" for a format
via the config file.
For example, the standard for "humans.txt" files requires using
rel="author" in HTML "link" elements. Meanwhile, humans.txt is
usually the only format used for its content. As a result, for
Hugo configurations that define a humans.txt custom output format,
Hugo will render "link" elements to content in this format with
rel="canonical," rather than "author" as required by the standard.
This commit changes page.NewOutputFormat to check whether a given
format is user defined and, if so, skips assigning Rel to
"canonical," even if isCanonical is true.
Fixes#8030
I find that Hugo should contain more links to relevant documentation of features in other tools/documentations. Please let me know if we don't want that and I'll stop. In this specific case I read about `.mailmap` in the Hugo docs and as a developer knew what was meant, but I think less dev-y users might not understand this. Instead of starting to add paragraphs about the format maybe it's ok to link to the features docs? As I said, let me know if that is overkill/bloat. It would make my life easier than seeing a word and googling it :)
(for instance, if we link to git in this case we don't need to add extra-documentation about what the mailmap file should look like and what should be in there)
* Before this commit, when you had static files in the root of /content and no /public folder, that folder would not be created unless the /static syncer had already run.
* So, with a common pattern doing `rm -rf public && hugo` would the fail now and then because /static and /content are processed in parallel (unless you have cleanDestinationDir=true)
* This was even worse before commit 0b918e131fe523188b820d1e3fa0b08251abde69 – a frozen build.
Closes#8166
hugoreleaser