By
* Caching common sites matrix setups (e.g. the single site in single site setups).
* Adding a fast path to IntSets.HasAnyVector for the common case of single vector input.
```
AssembleDeepSiteWithManySections/depth=3/sectionsPerLevel=2/pagesPerSection=100-10 31.62m ± 46% 30.68m ± 42% ~ (p=0.310 n=6)
│ master.bench │ perfcommon.bench │
│ B/op │ B/op vs base │
AssembleDeepSiteWithManySections/depth=3/sectionsPerLevel=2/pagesPerSection=100-10 31.98Mi ± 0% 31.24Mi ± 0% -2.30% (p=0.002 n=6)
│ master.bench │ perfcommon.bench │
│ allocs/op │ allocs/op vs base │
AssembleDeepSiteWithManySections/depth=3/sectionsPerLevel=2/pagesPerSection=100-10 460.9k ± 0% 419.9k ± 0% -8.90% (p=0.002 n=6)
````
The slugorcontentbasename permalink token was creating an extra
subdirectory for section pages (_index.md files). This was because
pageToPermalinkContentBaseName did not have the same special handling
for _index.md files as pageToPermalinkFilename.
This commit adds the special handling to return an empty string for
section pages, ensuring backward compatibility with slugorfilename.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixes#14104
* Use helper funcs in hreflect package when possible.
* Use hreflect.ConvertIfPossible to handle conversions when possible.
* Move scratch.go from common/maps to common/hstore to clear cyclic import in the next step.
* Move Indirect to hreflect and reimplementing it and adusting the behavior to preserve struct pointers.
* Adjust evaluateSubElem used by where and others making the struct pointer method case slightly faster.
This cache is used by `resources.GetRemote`.
Default values are:
* respectCacheControlNoStoreInResponse: false
* respectCacheControlNoStoreInRequest: true
This is a slightly breaking change, but the current behaviour is confusing, as:
* Many servers set the `no-store` header without much consideration, see https://developer.chrome.com/docs/web-platform/bfcache-ccns for more context
* We almost always want to cache the `resources.GetRemote` to disk.
Fixes#13990
Allow YYYY-MM-DD-HH-MM-SS prefix when extracting date from file names.
This is in addition to the YYYY-MM-DD prefix that is already supported.
Closes#13830
Add option ``aligny`` to specify the vertical alignment of the text
with respect to the ``y`` offset from the top of the image. Possible
values of ``aligny`` are ``top`` (default), ``center``, and ``bottom``.
The height of the block of text is measured from the top of the first
line to the baseline of the last line.
- ``top``: (Current behaviour) The top of the first line of the block of
text is at an offset of ``y`` from the top of the image.
- ``center``: The vertical center of the block of text is at an offset of
``y`` from the top of the image.
- ``bottom``: The baseline of the last line of the text is at an offset
of ``y`` from the top of the image.
Resolves#13414
````
│ 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 commit also
* Unexport all internal state in TemplateInfo.
* Make the dispatcher keys used for passing context.Context into uint8 from string to save memory allocations.
Co-authored-by: Joe Mooring <joe@mooring.com>
Updates #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
Two issues:
1. Fixe potential edit-loop in server/watch mode (see below)
2. Drain the cache eviction stack before we start calculating the change set. This should allow more fine grained rebuilds for bigger sites and/or in low memory situations.
The fix in 6c68142cc1 wasn't really fixing the complete problem.
In Hugo we have some steps that takes more time than others, one example being CSS building with TailwindCSS.
The symptom here is that sometimes when you:
1. Edit content or templates that does not trigger a CSS rebuild => Snappy rebuild.
2. Edit stylesheet or add a CSS class to template that triggers a CSS rebuild => relatively slow rebuild (expected)
3. Then back to content editing or template edits that should not trigger a CSS rebuild => relatively slow rebuild (not expected)
This commit fixes this by pulling the dynacache GC step up and merge it with the cache buster step.
Fixes#13316
* These response headers will be included in `.Data.Headers` if found.
* The header name matching is case insensitive.
* `Data.Headers` is of type `map[string][]string`
* In most cases there will be only one value per header key, but e.g. `Set-Cookie` commonly has multiple values.
Fixes#12521
* Always include the content hash in the cache key for unprocessed images.
* Always include the image config hash in the cache key.
This is also a major cleanup/simplification of the implementation in this area.
Note that this, unfortunately, forces new hashes/filenames for generated images.
Fixes#13273Fixes#13272
Bjørn Erik Pedersen