It has been reported that recent Hugo versions broke user's configuration of Headroom JS via the `header.on_scroll` option.
With this PR, Headroom JS configuration is working again.
Fixes#2935
Shortcodes in the new block system do not get access to the correct .Page variable (see #2918 ). The problem is the use of markdownify function to parse $block.content.text, since it actually is an alias to site.Home.RenderString since v 0.93.0 (see gohugoio/hugo#9959 (comment)).
This causes the shortcodes to always get the Homepage as .Page variable. The fix is to substitute markdownify with $page.RenderString, which gives the correct context.
Fixes#2918
Both site header and footer now use dynamic block system.
E.g. for custom header at `layouts/partials/components/headers/simple.html:
```
---
header:
navbar:
block: simple
---
```
Also, Params.footer.widget changed to Params.footer.block
Hooks replaced custom_js.html and custom_head.html
However, custom_js/custom_head remain supported for legacy purposes.
Despite commit acd74954b5 mentioning that the custom.html is still supported for now, I don't think it's being picked up at the moment. This PR resolves this issue.
- rename widgets/ folder to blocks/
- rename Blank block to Markdown
- rename Pages block to Collection
- replace Featured block with Collection block, filtered with `featured_only: true`
- standardise block variables to .wcPage and .wcBlock
- check requested block exists before loading
- refactor block parser to parse_block.html
E.g. a custom view (views/custom.html) can be wrapped with:
views/custom-start.html
views/custom-end.html
This allows for custom grid-based views (cards, etc.)
Adding `site.GetPage /privacy.md` to reflect the absolute path to `privacy.md`, as per the Hugo documentation for GetPage.
This should force Hugo to only link to a `/privacy.md` page at the root of the site and prevent Hugo searching for unrelated pages with `privacy` in the name (as it currently does, if for example you also have a /tags/privacy/ page).
Note that currently there's a Hugo bug where Hugo does not respect absolute paths in `site.GetPage`. Hence, Hugo can still return other unrelated pages (for example any other pages that have `privacy....` in the filename) until this bug is fixed: https://github.com/gohugoio/hugo/issues/10243
