~/SSCMS $ hugo serve -w -b 'site.local:1313' --bind '192.168.1.2'
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/.
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.
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 https://github.com/jmooring/hugo-testing 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:
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
[params]
foo = "bar"
result:
params: map[foo:bar]
#params.toml
foo = "bar"
result:
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?
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.
git clone --single-branch -b hugo-forum-topic-29136-a https://github.com/jmooring/hugo-testing hugo-forum-topic-29136-a
cd hugo-forum-topic-29136-a
hugo server
git clone --single-branch -b hugo-forum-topic-29136-b https://github.com/jmooring/hugo-testing hugo-forum-topic-29136-b
cd hugo-forum-topic-29136-b
hugo server
git clone --single-branch -b hugo-forum-topic-29136-c https://github.com/jmooring/hugo-testing 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.