Add headless page bundles

[bep]

We have a fairly solid page bundle story now, with metadata support and powerful glob matching. There are probably some improvements to be had here as well (linking resources outside of the bundle, metadata outside of front matter), but that will have to wait.

There are, however, popping up questions about "how to reuse images?" and similar, and people are creating more or less elegant hacks. We have similar requests for reuse of content files (many obvious use cases here, see #3612).

We should give people a good solution for this sooner rather than later. This is a low hanging fruit: Big win for little effort.

I suggest that we establish support for headless bundles for the index bundle type.

So:

headless = true

In front matter means that

• It will have no Permalink and no rendered HTML in /public
• It will not be part of .Site.RegularPages etc.

But you can get it by:

• .Site.GetPage ...

Thoughts?

[RealOrangeOne]

As a quick and somewhat dirty fix, this makes sense. However long term i'm not sure it's ideal, or especially useful. Assuming in the longer-term that the Resource stuff is available to static files under static/, then this becomes fairly useless.

On the other hand, if this is maintained after that implementation, it's possible it becomes a killer feature for someone in a situation I've not considered.

Assuming it's not too much work, and doesn't end up breaking flow in weird ways in other places, I'd say go for it!

[bep]

Assuming in the longer-term that the Resource stuff is available to static files under static/,

That will not happen. Static is static, i.e. plain copy.

This is not meant as "quick or dirty". You really need no explain a little what you mean by that?

[budparr]

Only .Site.GetPage, which would mean to me I could not loop through a section of content while having that section headless (my original request). Is that right?

[RealOrangeOne]

That will not happen. Static is static, i.e. plain copy.

Damn, i'm clearly seeing things!

I had assumed this was a quick fix, however if Resource isnt coming to static/ (which now I think about the design philosophy of Hugo, makes sense), this feels really nice! eg. adding a section simply called images, and storing all resources in there to be shared around pages feels really nice, and matches the directory structure of most sites anyway (having resources like images under a separate path)

[bep]

Only .Site.GetPage, which would mean to me I could not loop through a section of content while having that section headles

I'm talking headless bundles (i.e. the index.md), so there isn't a section to loop. So it is not a replica of your issue, but should solve the use case: Reusable content pages.

Imagine this in the home page template:

{{ $headless := .Site.GetPage "page" "someh-headless-page" }}
{{ $reusablePages := $headless.Resources.Match "sidebar-content*" }} 
{{ range $reusablePages }}
{{ .Title }}
{{ end }}

@RealOrangeOne Hugo is good at transforming content to websites. Content lives in /content (and to some extent in /data and /i18n), but not in /static. We could certainly add static assets helpers (fingerprinting, SASS, image compression, HTML minification -- but we should get some plugin support first), but it doesn't fit into the "content data model" in my head. The way we're doing it now with bundles means we have pretty good control of "what's changed" etc. and can improve on the partial rebuild area (with some significant effort).

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.