Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support creating menu entries with properties within content adapters #13384

Closed
hazel-nut opened this issue Feb 12, 2025 · 1 comment · Fixed by #13392
Closed

Support creating menu entries with properties within content adapters #13384

hazel-nut opened this issue Feb 12, 2025 · 1 comment · Fixed by #13392
Assignees
Labels
Milestone

Comments

@hazel-nut
Copy link

Requesting support to create menu entries with properties using a content adapter, per feedback in my forum post.


In #12507, @jmooring requested support for menu entry creation in content adapters. The resulting implementation in 245928a supports defining flat menu entries:

Front Matter Content Adapter
menus: main {{ .AddPage (dict "menus" "main" [...]) }}
menus: [main, footer] {{ .AddPage (dict "menus" (slice "main" "footer") [...]) }}

However, it's not possible to create menu entries with properties within a content adapter, equivalent to defining the following in front matter:

menus:
  main:
    parent: main-page
    identifier: example-id

I expected that passing a map would work:

{{- $mainMenu := dict 
    "parent" "main-page"
    "identifier" "example-id"
-}}
{{- $menus := dict "main" $mainMenu -}}
{{- .AddPage (dict "menus" $menus [...]) -}}

But it seems menus are defined as an array of strings. Maybe it should be a map, like Params?

Thank you!

@bep
Copy link
Member

bep commented Feb 12, 2025

But it seems menus are defined as an array of strings. Maybe it should be a map, like Params?

To fix this, Menu []string needs to be changed to Menu any; that's what the menu decoder gets from front matter (and then it checks if it's a slice of strings or a map).

@bep bep added this to the v0.144.0 milestone Feb 12, 2025
@bep bep self-assigned this Feb 13, 2025
bep added a commit to bep/hugo that referenced this issue Feb 13, 2025
@bep bep closed this as completed in fd38aee Feb 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants