Cannot get hugo to cast menu maps

I cannot figure where the problem is at this point!


Hugo Static Site Generator v0.76.5-60F0725B openbsd/amd64 BuildDate: 2020-10-14T15:17:56Z

config layout:

|-- config
|   |-- _default
|   |   |-- config.yaml
|   |   |-- languages.yamlx
|   |   |-- menus.yaml
|   |   `-- params.yaml


    - name: "Material"
      url: "/"
      weight: 0
    - name: "Getting started"
      url: "getting-started/"
      weight: 10
    - name: "Adding content"
      url: "adding-content/"
      weight: 20
    - name: "Roadmap"
      url: "roadmap/"
      weight: 30
    - name: "License"
      url: "license/"
      weight: 40

error on serve:

~/SSCMS $ hugo serve -w -b 'site.local:1313' --bind '' 
Start building sites … 
ERROR 2020/10/30 19:43:50 unable to process menus in site config
ERROR 2020/10/30 19:43:50 unable to cast map[string]interface {}{"main":[]interface {}{map[string]interface {}{"name":"Material", "url":"/", "weight":0}, map[string]interface {}{"name":"Getting started", "url":"getting-started/", "weight":10}, map[string]interface {}{"name":"Adding content", "url":"adding-content/", "weight":20}, map[string]interface {}{"name":"Roadmap", "url":"roadmap/", "weight":30}, map[string]interface {}{"name":"License", "url":"license/", "weight":40}}} of type map[string]interface {} to []interface{}
Built in 432 ms
Error: Error building site: logged 2 error(s)

edit: I used a sample config to make sure there isn’t some stray typo.

OK. It seems that I can have a split config.yaml in the root directory but when I move them to a /config/_default/ folder, the server generates the errors listed originally. I’m not sure but it seemed to work at least once in this session of testing. When I put everything in a single config file, the site generates properly and the menus map is accessible without generating errors.

The bug seems to be related to having a split config in /config/_default/.

I’ll repeat this test again tomorrow.

Please share a link to the public repository for your project. See:

Include a link to the source code repository of your project, because we really need the context of seeing your templates and partials to be able to help you. It is trivial to do a quick git clone on your repo, then run hugo server in your project, to help you out. On the other hand, recreating your code from screenshots, or sort of guessing at it, is not.

If you can’t share your repository for whatever reason, consider creating a dummy repo that you can share, which reproduces the problem you’re experiencing.

1 Like

I’ll create a simple project. If the error persists, I’ll upload it.

I set it up on GitHub. As it stands, serving the site generates errors with config separated in different yaml files.

Start building sites … 
ERROR 2020/11/03 14:34:20 unable to process menus in site config
ERROR 2020/11/03 14:34:20 unable to cast map[string]interface {}{"main":[]interface {}{map[string]interface {}{"identifier":"about", "name":"About", "url":"about/"}, map[string]interface {}{"identifier":"posts", "name":"Posts", "url":"posts/"}}} of type map[string]interface {} to []interface{}
Built in 336 ms
Error: Error building site: logged 2 error(s)

this one is new:

Error: site config value "en" for defaultContentLanguage does not match any language definition

These happen on the same yaml configuration available on the GitHub repository. The split toml configuration seems to work fine.

See my initial response, and this working example:

git clone --single-branch -b hugo-forum-topic-29136 hugo-forum-topic-29136
cd hugo-forum-topic-29136
hugo server

When you split a section (e.g., menu) into a separate configuration file, the file itself is the top level configuration object.

For example, config/_default/menus.yaml should look like this:

- name: "Google"
  url: ""
- name: "Yahoo"
  url: ""

Not like this:

  - name: "Google"
    url: ""
  - name: "Yahoo"
    url: ""

then there is a design bug. this is an undocumented exception which doesn’t create useful work. The params file works when you include the parent node params: in yaml and json. The [menu] key declaration also works in toml. Design should be boring and predictable.

This is not an undocumented exception. Hugo behaves consistently across config files. The reason params does not break, is because the params config object itself is a “free” object, ie you can nest anything in there. What happens when you include the params key is that it will look like this:

{{ range $k, $v := site.Params }}
{{ $k }}: {{$v}}<br>
{{ end }}
# params.toml
foo = "bar"


params: map[foo:bar]

foo = "bar"


foo: bar

I have found this to not be the case. menus.toml/yaml/json breaks if you nest under menu. Do you have a repo showing that this setup works?

My test repo:

run with hugo --server --config configdir using the various configdirs included. those with "2" in the dir name have the config options nested and should break.

No, it does not. See:

git clone --single-branch -b hugo-forum-topic-29136-a hugo-forum-topic-29136-a
cd hugo-forum-topic-29136-a
hugo server

Then visit http://localhost:1313/post/test/.

No, it does not. See:

git clone --single-branch -b hugo-forum-topic-29136-b hugo-forum-topic-29136-b
cd hugo-forum-topic-29136-b
hugo server

Then visit http://localhost:1313/post/test/.

No, it does not. See:

git clone --single-branch -b hugo-forum-topic-29136-c hugo-forum-topic-29136-c
cd hugo-forum-topic-29136-c
hugo server

ok. from my previous testing, it seems that I was using the switches --gc and --disableFastRender in lieu of --ignoreCache and every time I changed something in the configuration, as I assumed that was the way to get hugo ignore state from a previous run.

If --ignoreCache actually does what I’m thinking (ignoring past state on new render) then it should be highlighted for new users so they can get predictable results when prodding and poking at hugo. It is hard for a new user to explore hugo and build a coherent mind map when there is a lot of undocumented magic going on. I’m still not sure from the documentation whether this switch actually ignores past state cache.

A minor side note: Am I really the only one that got confused on the split configuration files? I’m assuming that many who encountered this “quirk” either stopped trying or focused on using a single config file because it worked. Most unix config files tend to be interpreted and require all declarations. At the very least this difference should be properly documented.

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