These were added to the page meta object when we implemented "pages from data", but were not meant to be used in front matter.
That is not supported, so we might as well add validation.
Fixes#12484
New options:
* `FromHeaders`: Server header matching for redirects
* `FromRe`: Regexp with group support, i.e. it replaces $1, $2 in To with the group matches.
Note that if both `From` and `FromRe` is set, both must match.
Also
* Allow redirects to non HTML URLs as long as the Sec-Fetch-Mode is set to navigate on the request.
* Detect and stop redirect loops.
This was all done while testing out InertiaJS with Hugo. So, after this commit, this setup will support the main parts of the protocol that Inertia uses:
```toml
[server]
[[server.headers]]
for = '/**/inertia.json'
[server.headers.values]
Content-Type = 'text/html'
X-Inertia = 'true'
Vary = 'Accept'
[[server.redirects]]
force = true
from = '/**/'
fromRe = "^/(.*)/$"
fromHeaders = { "X-Inertia" = "true" }
status = 301
to = '/$1/inertia.json'
```
Unfortunately, a provider like Netlify does not support redirects matching by request headers. It should be possible with some edge function, but then again, I'm not sure that InertiaJS is a very good fit with the common Hugo use cases.
But this commit should be generally useful.
The failing test case here is
* A custom search output format defined on the home page, marked as `noAlternative` and not `permalinkable`
* In fast render mode, when making a change to a data source for that search output format, the JSON file was not refreshed.
There are variants of the above, but the gist of it is:
* The change set was correctly determined, but since the search JSON file was not in the recently visited browser stack, we skipped rendering it.
Running with `hugo server --disableFastRender` would be a workaround for the above.
This commit fixes this by:
* Adding a check for the HTTP request header `Sec-Fetch-Mode = navigation` to the condition for if we should track server request as a user navigation (and not e.g. a HTTP request for a linked CSS stylesheet).
* Making sure that we compare against the real relative URL for non-permalinkable output formats.
Fixes#13014
Will include zero config values (e.g. "", 0, false) in the output and will be more verbose, but useful if you cant to discover all available config options.
The old setup tried to log >= warning to stderr, the rest to stdout.
However, that logic was flawed, so warnings ended up in stdout, which makes `hugo list all` etc. hard to reason about from scripts.
This commit fixes this by making all logging (info, warn, error) log to stderr and let stdout be reserved for program output.
Fixes#13074
I guess most commonly an issue with TailwindCSS editing in templates:
* Build changes both CSS and index.html => reload OK.
* Build changes both CSS and index.html and some other files => only CSS reloaded.
The above would fix itself with one more edit, but that's annoying.
Build tags setup changed to:
* !nodeploy => withdeploy
* nodeploy => !withdeploy
Also move the deploy feature out into its own release archives.
See #12994 for the primary motivation for this change. But this also greatly reduces the number of dependencies in Hugo when you don't need this feature and cuts the binary size greatly.
Fixes#12994
This seems to be a browser bug (tested in both Chrome and Safari on MacOS), but it seems that doing a `window.location.reload()` (or `window.location.reload(true)`) doesn't refresh the CSS changes, even if HTTP caching is disabled.
This commit works around this by doing additional refreshes of the CSSes.
Closes#12600
- Improve help text
- Add "kind" and "section" to CSV output
- Add a "published" subcommand to list content that is not draft,
expired, or future.
Closes#12520
Do not offer filenames to arguments not taking one, complete arguments
of options taking resource kinds, directory names, --logLevel, release
--step, config and new --format.
As an internal refactoring, use higher level functions to set flag
completions. SetAnnotation works, but is more verbose than
alternatives, and uses bash specific wording.
While at it, move setting completions next to flag definitions
consistently.
Remove superfluous --destination completer setting, which is already
set elsewhere.
Named segments can be defined in `hugo.toml`.
* Eeach segment consists of zero or more `exclude` filters and zero or more `include` filters.
* Eeach filter consists of one or more field Glob matchers.
* Eeach filter in a section (`exclude` or `include`) is ORed together, each matcher in a filter is ANDed together.
The current list of fields that can be filtered are:
* path as defined in https://gohugo.io/methods/page/path/
* kind
* lang
* output (output format, e.g. html).
It is recommended to put coarse grained filters (e.g. for language and output format) in the excludes section, e.g.:
```toml
[segments.segment1]
[[segments.segment1.excludes]]
lang = "n*"
[[segments.segment1.excludes]]
no = "en"
output = "rss"
[[segments.segment1.includes]]
term = "{home,term,taxonomy}"
[[segments.segment1.includes]]
path = "{/docs,/docs/**}"
```
By default, Hugo will render all segments, but you can enable filters by setting the `renderSegments` option or `--renderSegments` flag, e.g:
```
hugo --renderSegments segment1,segment2
```
For segment `segment1` in the configuration above, this will:
* Skip rendering of all languages matching `n*`, e.g. `no`.
* Skip rendering of the output format `rss` for the `en` language.
* It will render all pages of kind `home`, `term` or `taxonomy`
* It will render the `/docs` section and all pages below.
Fixes#10106
