Allow .Resource.Get etc. to also work with the original path/name

[anakinsleftleg]

Normally, one can use .Resource.Get "images/test.png" to retrieve a page bundle resource. But if one gives the resource a name in the frontmatter like so:

resources:
  - src: images/test.png
    name: header

Then the above function will fail. It will work however if the path is replaced by the name: .Resource.Get "header" but that is neither expected behavior (certainly not documented) nor does it follow from the documentation of Page Resources in the frontmatter where it suggests using .Resources.GetMatch .

This Hugo forum post also describes this and provides a repo to test it.

https://discourse.gohugo.io/t/function-partial-that-loads-image-breaks-when-page-resource-is-given-a-name/39486

https://github.com/anakinsleftleg/hugo_plain/tree/help1/pageresourcemetadata/main

I would expect that the path would ALWAYS work, and the name will only work if defined of course.

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.101.0-466fa43c16709b4483689930a4f9ac8add5c9f66+extended windows/amd64 BuildDate=2022-06-16T07:09:16Z VendorInfo=gohugoio

Does this issue reproduce with the latest release?

Yes

[anakinsleftleg]

The docs here:
https://gohugo.io/content-management/page-resources/#page-resources-metadata

Indicate that the name parameter in the frontmatter page resources is used by .Match and .GetMatch . Which only adds to the confusion on the behavior using .Get

[bep]

I have updated the docs sightly (the .Resources.Get method is a recent addition).

but that is neither expected behavior

It was certainly the prime motivation behind the "rename feature" as it allows having a generic template work without having to rename any images.

We may consider making both work (somehow), but for now I suggest you don't rename your resources. There is a title attribute for the "visual" part.

[heimoshuiyu]

I hope that even after renaming, the .Get method can still be used to retrieve the image using the original path.

The reason is as follows:

I have referenced the image images/demo.webp in a markdown file, and this image has been set as the featuredImage of the article (i.e., renamed images/demo.webp to featuredImage in resources). However, the context .Destination passed into the markup render hook is still images/demo.webp. This prevents me from using the .Page.Resources.Get method to retrieve and process the image.

[jmooring]

It's not terribly pretty, but you can get a renamed page resource within render hook with something like:

{{ $r := or
  (.Page.Resources.Get .Destination)
  (index (where .Page.Resources "Key" "like" (printf "%s$" .Destination )) 0)
}}

{{ with $r }}
  <img src="{{ .RelPermalink }}" width="{{ .Width }}" height="{{ .Height }}" alt="">
{{ end }}

This issue is essentially about using the resource name field in front matter as an alias instead of renaming the resources, or creating a copy of it.

[cmahnke]

I would also like to see this fixed, my use case is that I have images in a format not recognized by Hugo (yet), JXL and generate JPEG derivates which are located in a subdirectory. What I'm doing currently is get the image by name, check the MediaType (which is configured base on extension) and if it's JXL try to load another image from a known location, like $name/full/full/0/default.jpg. This limitation prohibit this.

And actually I can't really understand why this hasn't been implemented in the first place. Maybe it's easier to add a .GetFile method, it won't try do pattern matching or anything else fancy.

[cmahnke]

Working around this by trying to access the required file from the parent isn't working as well:

{{ $relContext := strings.Substr $context (len $entry.Parent.Page.File.Dir) }}
{{ $parentPreviewReference := (path.Join $relContext $previewReference.name $fullResImgSuffix) }}
{{ warnf "--from parent--> %s #%v" $parentPreviewReference ($entry.Parent.Page.Resources.Get $parentPreviewReference )  }}�

Where $context is the path to the Page and $previewReference is a Map from the resource list of the page.

But that this approach isn't working is certainly related to #11439.

[jmooring]

This will be addressed with #11940

[jmooring]

Fixed with #11940.

[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.