Content adapters vs page bundles for a showcase website

support
1

Between this implementation and page bundles, which is the better one for a similar project to the example site?

(Also took the example site for a spin and it fails to detect data file changes until server restart)

1 Like
2

I just took that example for a spin and it detected my changes. That said, I would say that it’s almost always a better choice to put your data files in assets and load them as shown below. Key benefits are smarter memory management if you’re using that particular data for just that, but it also allows more fine grained partial rebuilds.

As to what’s the better choice, I’m not sure …

{{ $products := resources.Get "products.json" | transform.Unmarshal }}
{{ range $products }}
{{ end }}
1 Like
3

FYI

I’ve updated the referenced example (a) per bep’s comments above, and (b) to address recent deprecations. The example now requires v0.159.0 or later.

git clone --single-branch -b hugo-forum-topic-54852 https://github.com/jmooring/hugo-testing hugo-forum-topic-54852
cd hugo-forum-topic-54852
hugo server
1 Like
4 
ERROR error building site: render: [en v1.0.0 guest] failed to render pages: render of "/categories/windows" failed: "/home/kijana/Code/hugo-forum-topic-54852/layouts/term.html:18:12": execute of template failed: template: term.html:18:12: executing "main" at <.Resize>: error calling Resize: failed to resize image "/home/kijana/Code/hugo-forum-topic-54852/content/products/_content.gotmpl": resize /products/window-frame/01.jpg: invalid JPEG format: short Huffman data
5 
Start building sites … 
hugo v0.159.0-2ed7d193cfdfcf11808fb2a921a9429423b0ebe9+extended linux/amd64 BuildDate=2026-03-23T18:16:59Z VendorInfo=gohugoio


                  │ EN 
──────────────────┼────
 Pages            │  6 
 Paginator pages  │  0 
 Non-page files   │  6 
 Static files     │  1 
 Processed images │  7 
 Aliases          │  0 
 Cleaned          │  0 

Total in 63 ms

Tested on Linux (Ubuntu) and Windows 11.

6

I run Linux Mint. The error keeps popping up.

7

Which version of Hugo are you running, and how did you install it?

8

This https://github.com/gohugoio/hugo/releases/download/v0.159.1/hugo_0.159.1_linux-amd64.deb

sudo dpkg -i hugo_0.159.1_linux-amd64.deb
9

Have you tried recloning the repository?

10

Every time! I delete the folder and run the full commands and the error pops up again and again!

11

OK, I’ve reproduced the problem.

I have to build the site several times in a row (as many as 20 times) to get the error, and I cleared the image cache each time. This intermittent error isn’t anything new… I was able to reproduce with v0.150.0, but didn’t test anything older than that.

This is irritating.

It took me a while, but I finally traced the problem to the content adapter, specifically this bit:

{{ range resources.Match (printf "images/products/%s/*.*" .sku) }}
  {{ $content := dict
    "mediaType" .MediaType.Type
    "value" .Content
  }}
  {{ $resource := dict
    "content" $content
    "path" (printf "%s/%s" $product.name (path.Base .Name))
  }}
  {{ $.AddResource $resource }}
{{ end }}

In this line…

"value" .Content

…the .Content method returns a string. According to the related documentation this should be fine:

content.value The content value as a string or resource.

When content.value is a string, Hugo generates a new resource with a publication path relative to the page. However, if content.value is already a resource, Hugo directly uses its value and publishes it relative to the site root. This latter method is more efficient.

If I pass the Resource object instead of its Content, the problem goes away:

{{ range resources.Match (printf "images/products/%s/*.*" .sku) }}
  {{ $content := dict
    "mediaType" .MediaType.Type
    "value" .
  }}
  {{ $resource := dict
    "content" $content
    "path" (printf "%s/%s" $product.name (path.Base .Name))
  }}
  {{ $.AddResource $resource }}
{{ end }}

I’ve updated the test site accordingly; please try again:

git clone --single-branch -b hugo-forum-topic-54852 https://github.com/jmooring/hugo-testing hugo-forum-topic-54852
cd hugo-forum-topic-54852
hugo server

See:

This has been fixed and will be available in the next release.

2 Likes
12

Thanks for sporting the bug.

Back to OT, I found using the JSON file better coz all details and parameters are defined in one file. It will take a while to update all items, but the best thing is i don’t have to play around with front matter.

13

What are some circumstances that would lead to choosing assets over data folder or vice versa? I use the data folder for some multilingual pages that need such data via shortcodes.

14

bep may have more to add to this, but my take is…

If you have a small amount of data that is accessed by several templates, place the files in the data directory and retrieve the data with the hugo.Data function. This is convenient as the data is globally available without extra setup.

If you have a large amount of data, or a small amount of data accessed from one template, place the files in the assets directory and retrieve the data with resources.Get + transform.Unmarshal. This reduces memory consumption; data in the data directory is loaded into memory at the beginning of each build, while the resources.Get + transform.Unmarshal approach loads the data as needed, and the garbage collector can free memory when the data is no longer needed.

1 Like
15

Based on your description, then I am using the folders correctly. For single use files used by shortcodes, I went with page bundle resources.

16

You might need to update the example to explicitly unmarshall content. I faced a GeoJSON unsupported mime type error with a remote data file Update all transform.Unmarshal examples by jmooring · Pull Request #2444 · gohugoio/hugoDocs · GitHub

17

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.