Data files in the page bundle

The concept of the global data folder does not work well with the page bundle concept. There should be a way to have data folders specific to page bundles that can override the global data variables just like assets already do.

I would love to put a yaml file in the page bundle and access it in the page. Is there a way to already do this per page?

That way we could carve out things like the sidebar into a separate files without resorting to cramming it in the front matter. Headless pages with special names can be used as an alternative but they bring their own burden with them being parallel to the page rather than components.

I have a nagging feeling that I forgot to document this (did I, @regis ?) … But you can do:

{{ $data := .Resources.Get "mydata.yaml" | transform.Unmarshal }} 

I did not find this in the documentation. That looks really powerful.

Update. Ahh I see

It is just in function docs. Not in the other places like the data documentation.

1 Like

On vacation hence the slow response but we did not document the many possibilities opened by the transform methods no.

I had a need to use a data file in a page bundle and found this page. However, when I attempted to use the above as an example, I got:
execute of template failed: template: index.html:40:25: executing “main” at <.Resources.Get>: can’t evaluate field Get in type resource.Resources

For anyone else who stumbles across this:

Per the Page Resources docs, it looks like .Resources.Get should actually be .Resources.GetMatch

Note that if you are doing this within a Custom Shortcode instead of within a standard Template, then you need .Page.Resources.GetMatch, or .Parent.Page.Resources.GetMatch if this is a nested Shortcode, since Shortcodes have their own context and use .Page to get to the page’s context.

If you search for .Resources.Get, you will find resources.Get in the Hugo Pipes docs. This is a separate and unrelated feature for accessing files in the global /assets/ directory.

For reference: I have opened hugoDocs PR 1548 to attempt to clarify this in the docs.

Yea, it’s on my TODO list (or: we have a GitHub issue) about getting this into a common interface which would make sure that all methods were available in both scenarios.