Age | Commit message (Collapse) | Author |
|
As in: Get the Kubernetes site to build with the new Hugo version.
Updates #10947
|
|
Updates #10947
|
|
Primary motivation is documentation, but it will also hopefully simplify the code.
Also,
* Lower case the default output format names; this is in line with the custom ones (map keys) and how
it's treated all the places. This avoids doing `stringds.EqualFold` everywhere.
Closes #10896
Closes #10620
|
|
Co-authored-by: 641bill <wo23636@126.com>
Fixes #9216
|
|
This is a workaround. We need to improve on this, but not today.
Fixes #10782
|
|
|
|
|
|
Fixes #9897
|
|
Note that we will now fail if `inlineImports` is enabled and we cannot resolve an import.
You can work around this by either:
* Use url imports or imports with media queries.
* Set `skipInlineImportsNotFound=true` in the options
Also get the argument order in the different NewFileError* funcs in line.
Fixes #9895
|
|
* Redo the server error template
* Always add the content file context if relevant
* Remove some now superflous error string matching
* Move the server error template to _server/error.html
* Add file context (with position) to codeblock render blocks
* Improve JS build errors
Fixes #9892
Fixes #9891
Fixes #9893
|
|
* Add file context to minifier errors when publishing
* Misc fixes (see issues)
* Allow custom server error template in layouts/server/error.html
To get to this, this commit also cleans up and simplifies the code surrounding errors and files. This also removes the usage of `github.com/pkg/errors`, mostly because of https://github.com/pkg/errors/issues/223 -- but also because most of this is now built-in to Go.
Fixes #9852
Fixes #9857
Fixes #9863
|
|
|
|
Fixes #2180
|
|
Fixes #9761
|
|
See #9626
|
|
Fixes #9745
|
|
Updates #9687
|
|
The isolated benchmark for the function is obviously much faster:
```bash
name old time/op new time/op delta
GetMethodByName-10 1.21µs ± 7% 0.23µs ± 5% -81.42% (p=0.029 n=4+4)
name old alloc/op new alloc/op delta
GetMethodByName-10 680B ± 0% 0B -100.00% (p=0.029 n=4+4)
name old allocs/op new allocs/op delta
GetMethodByName-10 20.0 ± 0% 0.0 -100.00% (p=0.029 n=4+4)
```
But more pleasing is the overall performance looking at the site benchmarks:
```bash
name old time/op new time/op delta
SiteNew/Regular_Bundle_with_image-10 6.25ms ± 2% 6.10ms ± 2% ~ (p=0.057 n=4+4)
SiteNew/Regular_Bundle_with_JSON_file-10 6.30ms ± 2% 5.66ms ±11% ~ (p=0.057 n=4+4)
SiteNew/Regular_Tags_and_categories-10 22.2ms ± 2% 17.4ms ± 1% -21.88% (p=0.029 n=4+4)
SiteNew/Regular_Canonify_URLs-10 108ms ± 0% 107ms ± 0% -1.20% (p=0.029 n=4+4)
SiteNew/Regular_Deep_content_tree-10 36.1ms ± 1% 33.8ms ± 1% -6.44% (p=0.029 n=4+4)
SiteNew/Regular_TOML_front_matter-10 24.9ms ± 1% 22.6ms ± 1% -9.30% (p=0.029 n=4+4)
SiteNew/Regular_Many_HTML_templates-10 17.9ms ± 1% 16.7ms ± 1% -6.43% (p=0.029 n=4+4)
SiteNew/Regular_Page_collections-10 23.3ms ± 1% 22.0ms ± 0% -5.58% (p=0.029 n=4+4)
SiteNew/Regular_List_terms-10 8.00ms ± 1% 7.63ms ± 0% -4.62% (p=0.029 n=4+4)
name old alloc/op new alloc/op delta
SiteNew/Regular_Bundle_with_image-10 2.10MB ± 0% 2.07MB ± 0% -1.46% (p=0.029 n=4+4)
SiteNew/Regular_Bundle_with_JSON_file-10 1.88MB ± 0% 1.85MB ± 0% -1.76% (p=0.029 n=4+4)
SiteNew/Regular_Tags_and_categories-10 13.5MB ± 0% 11.6MB ± 0% -13.99% (p=0.029 n=4+4)
SiteNew/Regular_Canonify_URLs-10 96.1MB ± 0% 95.8MB ± 0% -0.40% (p=0.029 n=4+4)
SiteNew/Regular_Deep_content_tree-10 28.4MB ± 0% 27.3MB ± 0% -3.83% (p=0.029 n=4+4)
SiteNew/Regular_TOML_front_matter-10 16.9MB ± 0% 15.1MB ± 0% -10.58% (p=0.029 n=4+4)
SiteNew/Regular_Many_HTML_templates-10 8.98MB ± 0% 8.44MB ± 0% -6.04% (p=0.029 n=4+4)
SiteNew/Regular_Page_collections-10 17.1MB ± 0% 16.5MB ± 0% -3.91% (p=0.029 n=4+4)
SiteNew/Regular_List_terms-10 3.92MB ± 0% 3.72MB ± 0% -5.03% (p=0.029 n=4+4)
name old allocs/op new allocs/op delta
SiteNew/Regular_Bundle_with_image-10 25.8k ± 0% 24.9k ± 0% -3.49% (p=0.029 n=4+4)
SiteNew/Regular_Bundle_with_JSON_file-10 25.8k ± 0% 24.9k ± 0% -3.49% (p=0.029 n=4+4)
SiteNew/Regular_Tags_and_categories-10 288k ± 0% 233k ± 0% -18.90% (p=0.029 n=4+4)
SiteNew/Regular_Canonify_URLs-10 375k ± 0% 364k ± 0% -2.80% (p=0.029 n=4+4)
SiteNew/Regular_Deep_content_tree-10 314k ± 0% 283k ± 0% -9.77% (p=0.029 n=4+4)
SiteNew/Regular_TOML_front_matter-10 302k ± 0% 252k ± 0% -16.55% (p=0.029 n=4+4)
SiteNew/Regular_Many_HTML_templates-10 133k ± 0% 117k ± 0% -11.81% (p=0.029 n=4+4)
SiteNew/Regular_Page_collections-10 202k ± 0% 183k ± 0% -9.55% (p=0.029 n=4+4)
SiteNew/Regular_List_terms-10 55.6k ± 0% 49.8k ± 0% -10.40% (p=0.029 n=4+4)
```
Thanks to @quasilyte for the suggestion.
Fixes 9386
|
|
Fixes #9119
|
|
The old implementation had some issues, mostly related to the context (e.g. name, file paths) passed to the template.
This new implementation is using the exact same code path for evaluating the pages as in a regular build.
This also makes it more robust and easier to reason about in a multilingual setup.
Now, if you are explicit about the target path, Hugo will now always pick the correct mount and language:
```bash
hugo new content/en/posts/my-first-post.md
```
Fixes #9032
Fixes #7589
Fixes #9043
Fixes #9046
Fixes #9047
|
|
Test building with `go build -ldflags="-s -w"`
Hugo 0.86.2: 46MB
Before this commit: 77MB
After this commit: 54MB
Fixes #8839
Fixes #8841
|
|
Fixes #8832
|
|
Fixes #8820
|
|
We have been using `go-toml` for language files only. This commit makes it the only TOML library.
It's spec compliant and very fast.
A benchark building a site with 200 pages with TOML front matter:
```bash
name old time/op new time/op delta
SiteNew/Regular_TOML_front_matter-16 48.5ms ± 1% 47.1ms ± 1% -2.85% (p=0.029 n=4+4)
name old alloc/op new alloc/op delta
SiteNew/Regular_TOML_front_matter-16 16.9MB ± 0% 16.7MB ± 0% -1.56% (p=0.029 n=4+4)
name old allocs/op new allocs/op delta
SiteNew/Regular_TOML_front_matter-16 302k ± 0% 296k ± 0% -2.20% (p=0.029 n=4+4)
```
Note that the front matter unmarshaling is only a small part of building a site, so the above is very good.
Fixes #8801
|
|
Fixes #8810
|
|
Fixes #8797
|
|
This commit started out investigating a `concurrent map read write` issue, ending by replacing the map with a struct.
This is easier to reason about, and it's more effective:
```
name old time/op new time/op delta
SiteNew/Regular_Deep_content_tree-16 71.5ms ± 3% 69.4ms ± 5% ~ (p=0.200 n=4+4)
name old alloc/op new alloc/op delta
SiteNew/Regular_Deep_content_tree-16 29.7MB ± 0% 27.9MB ± 0% -5.82% (p=0.029 n=4+4)
name old allocs/op new allocs/op delta
SiteNew/Regular_Deep_content_tree-16 313k ± 0% 303k ± 0% -3.35% (p=0.029 n=4+4)
```
See #8749
|
|
So they can be used from the config package without cyclic troubles.
Updates #8654
|
|
The main motivation behind this is simplicity and correctnes, but the new small config library is also faster:
```
BenchmarkDefaultConfigProvider/Viper-16 252418 4546 ns/op 2720 B/op 30 allocs/op
BenchmarkDefaultConfigProvider/Custom-16 450756 2651 ns/op 1008 B/op 6 allocs/op
```
Fixes #8633
Fixes #8618
Fixes #8630
Updates #8591
Closes #6680
Closes #5192
|
|
Fixes #8613
|
|
Fix this by
1. Making sure that only numerical values are treated as plural counts
2. Making sure that `i18n.pluralFormNotFoundError` is not logged as a warning if `other` resolved.
Note that 2. isn't a new problem, but became visible because of the plural improvements in Hugo `0.83.0`.
Fixes #8492
|
|
This fixes a bug upstream by temporarily using a patched version of go-i18n.
Closes #7838
|
|
The go-i18n library expects plural counts with floats to be represented as strings.
Fixes #8464
|
|
There were some issues introduced with the plural counting when we upgraded from v1 to v2 of go-i18n.
This commit improves that situation given the following rules:
* A single integer argument is used as plural count and passed to the i18n template as a int type with a `.Count` method. The latter is to preserve compability with v1.
* Else the plural count is either fetched from the `Count`/`count` field/method/map or from the value itself.
* Any data type is accepted, if it can be converted to an integer, that value is used.
The above means that you can now do pass a single integer and both of the below will work:
```
{{ . }} minutes to read
{{ .Count }} minutes to read
```
Fixes #8454
Closes #7822
See https://github.com/gohugoio/hugoDocs/issues/1410
|
|
Fixes #8212
|
|
|
|
See https://github.com/mvdan/gofumpt
|
|
This change is mostly motivated to get a more stable CI build (we're building the Hugo site there, with Instagram and Twitter shortcodes sometimes failing).
Fixes #7866
|
|
Fixes #7804
|
|
Closes #7798
|
|
Hugo 0.76.0 updated go-i18n from v1 to v2. This allowed us to set the TOML unmarshaler to use, so we set the one we use in other places in Hugo.
But that does not support dotted bare keys, which caused some breakage in the wild.
This commit fixes that by:
* Using go-toml for language files
* Updating go-toml to the latest version
|
|
Fixes #7787
|
|
Fixes #5242
|
|
Fixes #6550
|
|
Fixes #6993
|
|
This is a big commit, but it deletes lots of code and simplifies a lot.
* Resolving the template funcs at execution time means we don't have to create template clones per site
* Having a custom map resolver means that we can remove the AST lower case transformation for the special lower case Params map
Not only is the above easier to reason about, it's also faster, especially if you have more than one language, as in the benchmark below:
```
name old time/op new time/op delta
SiteNew/Deep_content_tree-16 53.7ms ± 0% 48.1ms ± 2% -10.38% (p=0.029 n=4+4)
name old alloc/op new alloc/op delta
SiteNew/Deep_content_tree-16 41.0MB ± 0% 36.8MB ± 0% -10.26% (p=0.029 n=4+4)
name old allocs/op new allocs/op delta
SiteNew/Deep_content_tree-16 481k ± 0% 410k ± 0% -14.66% (p=0.029 n=4+4)
```
This should be even better if you also have lots of templates.
Closes #6594
|
|
This means that you can now do:
```
{{ range where .Site.Pages "Params.MYPARAM" "foo" }}
```
|
|
|
|
Fixes #6134
|
|
This commit implements Hugo Modules.
This is a broad subject, but some keywords include:
* A new `module` configuration section where you can import almost anything. You can configure both your own file mounts nd the file mounts of the modules you import. This is the new recommended way of configuring what you earlier put in `configDir`, `staticDir` etc. And it also allows you to mount folders in non-Hugo-projects, e.g. the `SCSS` folder in the Bootstrap GitHub project.
* A module consists of a set of mounts to the standard 7 component types in Hugo: `static`, `content`, `layouts`, `data`, `assets`, `i18n`, and `archetypes`. Yes, Theme Components can now include content, which should be very useful, especially in bigger multilingual projects.
* Modules not in your local file cache will be downloaded automatically and even "hot replaced" while the server is running.
* Hugo Modules supports and encourages semver versioned modules, and uses the minimal version selection algorithm to resolve versions.
* A new set of CLI commands are provided to manage all of this: `hugo mod init`, `hugo mod get`, `hugo mod graph`, `hugo mod tidy`, and `hugo mod vendor`.
All of the above is backed by Go Modules.
Fixes #5973
Fixes #5996
Fixes #6010
Fixes #5911
Fixes #5940
Fixes #6074
Fixes #6082
Fixes #6092
|