````
│ stash.bench │ perf-v146.bench │
│ sec/op │ sec/op vs base │
LookupPartial-10 248.00n ± 0% 14.75n ± 2% -94.05% (p=0.002 n=6)
│ stash.bench │ perf-v146.bench │
│ B/op │ B/op vs base │
LookupPartial-10 48.00 ± 0% 0.00 ± 0% -100.00% (p=0.002 n=6)
│ stash.bench │ perf-v146.bench │
│ allocs/op │ allocs/op vs base │
LookupPartial-10 3.000 ± 0% 0.000 ± 0% -100.00% (p=0.002 n=6)
```
THe speedup above assumes reuse of the same partials over and over again, which I think is not uncommon.
This commits also adds some more lookup benchmarks. The current output of these on my MacBook looks decent:
```
BenchmarkLookupPagesLayout/Single_root-10 3031562 395.5 ns/op 0 B/op 0 allocs/op
BenchmarkLookupPagesLayout/Single_sub_folder-10 2515915 480.9 ns/op 0 B/op 0 allocs/op
BenchmarkLookupPartial-10 84808112 14.13 ns/op 0 B/op 0 allocs/op
BenchmarkLookupShortcode/toplevelpage-10 8111779 148.2 ns/op 0 B/op 0 allocs/op
BenchmarkLookupShortcode/nestedpage-10 8088183 148.6 ns/op 0 B/op 0 allocs/op
```
Note that in the above the partial lookups are cahced, the others not (they are harder to cache because of the page path).
Closes#13571
This should:
1. Fix some (rare) tiebreaker issues when sorting pages from multiple content adapters.
2. Improve the sorting for pages without a backing file.
* Make it work for all pages, including those created from content adapters and not backed by a file.
* Allow the `slug` to win, so the new tokens are:
`:contentbasename`:
1. ContentBaseName
`:slugorcontentbasename`:
1. Slug
2. ContentBaseName
Note that a page will always have a `ContentBaseName`, so no need to fall back to e.g. the title.
Closes#11722
This is an empty struct for now, but we will most likely expand on that.
```
[contentTypes]
[contentTypes.'text/markdown']
```
The above means that only Markdown will be considered a content type. E.g. HTML will be treated as plain text.
Fixes#12274
This issue fixes two cases where `{{__hugo_ctx` artifacts were left in the rendered output:
1. Inclusion when `.RenderShortcodes` is wrapped in HTML.
2. Inclusion of Markdown file without a trailing newline in some cases.
Closes#12854
Updates #12998
Note that this also adds a new `.ContentWithoutSummary` method, and to do that we had to unify the different summary types:
Both `auto` and `manual` now returns HTML. Before this commit, `auto` would return plain text. This could be considered to be a slightly breaking change, but for the better: Now you can treat the `.Summary` the same without thinking about where it comes from, and if you want plain text, pipe it into `{{ .Summary | plainify }}`.
Fixes#8680Fixes#12761Fixes#12778Fixes#716
This change allows to use permalink tokens in url front matter fields. This should be useful to target more specific pages instead of using a global permalink configuration. It's expected to be used with cascade.
Fixes#9714
This was recently introduced. so no breaking change.
The thing is:
* We do not commonly use the prefix Default* even if it can be overridden in the templates.
* PagerSize makes more sense and is also the term used in the code.
The main use case for this is to resolve links and resources (e.g. images) relative to the included `Page`.
A typical `include` would similar to this:
```handlebars
{{ with site.GetPage (.Get 0) }}
{{ .RenderShortcodes }}
{{ end }}
```
And when used in a Markdown file:
```markdown
{{% include "/posts/p1" %}}
```
Any render hook triggered while rendering `/posts/p1` will get `/posts/p1` when calling `.PageInner`.
Note that
* This is only relevant for shortcodes included with `{{%` that calls `.RenderShortcodes`.
* `.PageInner` is available in all render hooks that, before this commit, received `.Page`.
* `.PageInner` will fall back to the value of `.Page` if not relevant and will always have a value.
Fixes#12356
When creating a link to a file with a `#` in the filename, the link gets
truncated. This happens because the filename is eventaully passed to
`url.Parse` which (correctly!) interprets the `#` as fragment separator.
This commit escapes the `#` in the filename before creating the link.
Fixes#4926Fixes#8232Fixes#12342
Co-authored-by: Joe Mooring <joe.mooring@veriphor.com>
