Full path to file should be given in EXIF error message

[snicolai-blog]

$ hugo version
hugo v0.130.0+extended darwin/arm64 BuildDate=2024-07-29T13:51:56Z VendorInfo=brew

I use page objects in my blog, and the new EXIF reader prints error message files relative to the page object. I'd really like it to print them relative to the blog root, so I know which file. For example:

WARN  images: "/fox.jpg": BitsPerSample: expected []interface {}, got uint16:

would be much better as:

WARN  images: "content/posts/part1/part2/fox.jpg": BitsPerSample: expected []interface {}, got uint16:

If it makes sense to strip the content/posts portion off to shorten the error message, that's fine.

[bep]

You are right, but that info isn't easily available where this is printed, which is why I got lazy. The important info for me (to fix this) here is the info to the right.

[nickjj]

It would be great if this could also apply to layout errors that are due to a content file being the culprit.

For example, I got this error recently:

Error: error building site: render: failed to render pages: render of "page" failed: "/app/layouts/blog/single.html:3:21": execute of template failed: template: blog/single.html:3:21: executing "main" at <.Fragments.HeadingsMap>: nil pointer evaluating *tableofcontents.Fragments.HeadingsMap

The problem is I have 500 posts and 300 drafts and there's no indication in the error which page is causing it. There's only a reference to a layout file to a function that is being used by those 800 posts.

Similarly I've gotten errors related to a nil reference from a missing image where the error only mentioned the baseof layout file being the issue but it's really due to a missing image in one of the 800 posts. It would be nice to see which content page that image is being referenced from.

[snicolai-blog]

Another option is to add "while processing <path to page>" to the error message.