.Resources.GetMatch not recognizing jpg as Image kind?

I’m trying to use image processing to ensure a consistent image size in my output. I am getting the following error, which makes it look like I either haven’t set the correct Kind (which I thought was supposed to be magic), or image handling isn’t compiled into my hugo distro:

Rebuild failed:

Failed to render pages: render of "section" failed: "/<path>/layouts/board/board.html:58:42": execute of template failed: template: board/board.html:58:42: executing "board/board.html" at <$headshotR.Fill>: can't evaluate field Fill in type resource.Resource

    {{ range .Pages }}
    {{ $headshotR := .Resources.GetMatch "images/placeholder.jpg" }}
    {{ $headshot := $headshotR.Fill "150x150" }}
    <section class="section container">

Hugo Static Site Generator v0.54.0/extended darwin/amd64 BuildDate: unknown

Git repo: https://github.com/paul-archeryincoloradoorg/archeryincolorado.org

The error comes when you try to resize it, not when loading it. So either the image has some errors (open in a graphics editor, save as jpg sometimes helps) or the line {{ $headshot := $headshotR.Fill "150x150" }} is wrong. Why not use .Resize instead of .Fill? There is no cropping going on and the original is 1:1 in size.

Hi,

Your pages in content/board are not organised as page bundles, so they never have .Resources. This means your $headshotR is nil, giving you that error.

Ok, so the case at hand is silly, but I expect that I won’t always have perfect images, and I don’t want to always manage the images by hand (why else use a template generator for this?).

On the off-chance the image was bad, I ran mogrify -format jpg -quality 85 placeholder.jpg which rewrote the file according to imagemagick, which probably does not emit bad images.

I also used “resize” instead of “fill”, and I still get a similar error:

ERROR 2019/03/19 23:55:26 Failed to render pages: render of "section" failed: "/<path>/layouts/board/board.html:32:30": execute of template failed: template: board/board.html:32:30: executing "board/board.html" at <$headshotR.Resize>: can't evaluate field Resize in type resource.Resource

So, it would appear that there is some kind of issue with .Resources.GetMatch setting the class so that the image methods like .Fill and .Resize are attached to the reference.

I guess my question then is: Did I do something wrong, or is hugo broken?

How is that not a bundle? Isn’t a bundle just a directory under /content that has an index.md or _index.md (depending on if it’s leaf or branch)?

/board/ is a branch bundle: it has _index.md.
/board/loremipsum.md is not: it does not have index.md.

Wow, so because I’m within the range context, .GetMatch will not work? And further, it doesn’t error until I try to do something with the content it couldn’t find?

That’s astonishing. I feel like that ought to be a bug.

Anyway, do you have an idea on how to use the information in the front matter of an article to reference an image file as a resource so that it can be manipulated in a list/section page?

(yes, the current example uses a hardcoded string, but the idea is to use the hardcoded string only when the data are not present in the front matter)

There’s nothing wrong with a nil value in itself. Maybe you are checking for absence of .Resources. It is essentially nil.Fill that doesn’t work, because nil does not have a .Fill method.

Convert your board/loremipsum.md pages into page bundles board/loremipsum/index.md. You need to have the images as page resources to be able to use the image processing methods. You could also put your images in your static folder, and have urls in the front matter, but you won’t be able to use the image processing features on them.

If you want to use your placeholder.jpg as a fallback page resource, you could ‘attach’ it to the board/_index.md bundle. Note that you will need to have it in the same directory as the _index.md (ie /board/placeholder.jpg) as per the docs on page bundles.

{{ $boardpage := .GetPage "/board/_index.md" }}
{{ $placeholder := $boardpage.Resources.GetMatch "placeholder.jpg" }}

Then in your range, (assuming page bundles) check first if there are resources, and use the placeholder if not found.

1 Like

I have restructured the location to try to access as a page resource. My structure is as follows:

board/
   + _index.md
   + placeholder.jpg
   + loremipsum/
   |  - index.md
   + dalorsitamet/
      - index.md

Within the .../layouts/board/board.html template, I have done the following outside the range context:

    <pre>
    {{ . }}
    {{ $boardpage := .GetPage "/board/_index.md" }}
    {{ $boardpage }}
    {{ $placeholderR := .Resources.GetMatch "placeholder.jpg" }}
    {{ $placeholderR }}
    {{/* $placeholder := $placeholderR.Fill "150x150" */}}
    </pre>

The output is:

Page(/board/_index.md)

Page(/board/_index.md)



What I have attempted to do is:

  1. Prove that . is-a page (it seems to be).
  2. Prove that .GetPage "/board/_index.md" is the same as . (it seems to be)
  3. try to load the resource from . or $boardpage
  4. emit something that shows me if I was successful.

If I try to run .Resize or .Fill on the resource, I get the same error as above. It doesn’t matter if I use . or $boardpage as the context.

Is this expected behavior?

With this structure,

content/board/
├── _index.md
├── ....md
└── placeholder.jpg

this in layouts/board/board.html

{{ $boardpage := .GetPage "/board/_index.md" }}
{{ $placeholder := $boardpage.Resources.GetMatch "placeholder.jpg" }}

dot context: {{.}}<br>
$boardpage: {{$boardpage}}<br>
$placeholder: {{ $placeholder }} / {{ .Resources.GetMatch "placeholder.jpg" }}

<hr> 

($placeholder.Fill "150x150").Permalink: <br>
{{ ($placeholder.Fill "150x150").Permalink }}

<hr>

img src = ($placeholder.Fill "150x150").Permalink
<img src="{{ ($placeholder.Fill "150x150").Permalink }}" >

I get this output:

screenshot-placeholder-fill

I’m starting to suspect there’s something more going on here. I’m running the following:

    <pre>
    Dotcontext: {{ . }}
    {{ $boardpage := .GetPage "/board/_index.md" }}
    $boardpage: {{ $boardpage }}
    {{ $placeholderR := $boardpage.Resources.ByType "images" }}
    $placeholderR: {{ $placeholderR }}
    </pre>

and my output is as follows, indicating that hugo did not find anything of type image, even though I have placeholder.jpg in the same directory with _index.md. Note that I’ve also done the above using .Page.Resources.ByType and $boardpage.Resources.ByType with the same results.

    Dotcontext: Page(/board/_index.md)
    
    $boardpage: Page(/board/_index.md)
    
    $placeholderR: []

Directory structure:

❱ ls -la
total 24
drwxr-xr-x  8 myusername  primarygroup   256 Mar 20 14:11 .
drwxr-xr-x  6 myusername  primarygroup   192 Mar 19 23:10 ..
-rw-r--r--  1 myusername  primarygroup   374 Mar 19 23:03 _index.md
drwxr-xr-x  3 myusername  primarygroup    96 Mar 20 14:06 loremipsum
drwxr-xr-x  3 myusername  primarygroup    96 Mar 20 14:06 dalorsetamet
-rw-r--r--@ 1 myusername  primarygroup  4523 Mar 20 14:11 placeholder.jpg

Here’s my hugo install, courtesy of homebrew.

❱ hugo version
Hugo Static Site Generator v0.54.0/extended darwin/amd64 BuildDate: unknown

I recursively cloned your repo, ran it locally, and took a full page screenshot of http://localhost:1313/board/. Just to make sure I’m on the same page, the below is not your expected output?

Yep, that’s my expected output. But it’s not what I’m getting. :frowning:

The difference is in the <pre> block where I’m outputting variables as a debugging mechanism. Where you get the Resource(image: placeholder.jpg) I get nil.

I would run git status and make sure you don’t have any unwanted changes. And you can always do a git reset --hard to get back to last commit

You could also try passing the garbage collection flag on your next run

hugo server --gc
1 Like

I’m 100% sure that it’s not because of unwanted changes. I have only wanted changes in there right now.

Running with the garbage collector flags seemed to solve the problem.

Is the server not totally reliable to rebuild on demand?

What --gc does per the docs

enable to run some cleanup tasks (remove unused cache files) after the build

So perhaps a cache of that image was causing your issue