Question about a widgets organisation an html generation

support
1

Solution :partying_face:

Thanks to jmooring for the solution.
I would also have liked to know if my design choice was correct, but you can’t have everything :laughing:

You need to use build options and cascade to apply globally.

The result in my case :

[[cascade]]
  [cascade.build]
    list = 'never'
    render = 'never'
    publishResources = false
  [cascade.target]
    path = '{**/_widgets,**/_widgets/**}'

The solved issue

helloooo every one,
Firstly, thanks for hugo, and to the community :stuck_out_tongue:

I have a question about folder organization and stuff like “widgets” in Hugo.
In my template, I want to use multiple “pages” inside home page.

I wanted to use the assets folder, but since I’m trying to use MD files with front matter, that didn’t seem to work. So I created a content/_widgets/ folder, but, unsurprisingly, this produce unwanted HTML page in the public folder and in the site map.

I load the widgets I want via the front matter of the page in question, for example with the Home page

+++
widgets = [“le_cabinet”]

[params stuf ...]
+++

# blablabla Mr.Freeman...

+++
etiquette = "/ LE CABINET /"
titre_decoration = "blabla headcrab"
+++

## TAKE THIS HEADCRAB

the template loads it like this

{{ range $_, $widget := .Page.Params.widgets }}
  {{ partial (printf "widgets/%s.html" $widget) $ }}
{{ end }}

{{ $widgetPage := .Site.GetPage "/_widgets/le_cabinet" }}

{{ with $widgetPage }}
<section class="widget full-width le-cabinet">
    <div class="container">
        {{ with .Params.etiquette }}
        <h2 class="widget__label">{{ . }}</h2>
        {{ end }}


        <div class="widget__members">
            {{ $keys := slice }}
            {{ range $key, $value := $.Site.Data.equipe }}
            {{ $keys = $keys | append $key }}
            {{ end }}
            {{ range shuffle $keys }}
            {{ with index $.Site.Data.equipe . }}
            <div class="widget__member">
                <div class="widget__member__pic">
                    <img src="{{ .photo.chemin }}" alt="photo de {{ .nom }}">
                </div>

                <div class="widget__member__info">
                    <h3 class="widget__member__name">{{ .nom }}</h3>
                    <p class="widget__member__role">{{ .role }}</p>
                </div>

                <div class="widget__member__bio">
                    {{ .description | markdownify }}
                </div>
            </div>
            {{ end }}
            {{ end }}
        </div>

        <div class="widget__content">
            {{ .Content }}
        </div>
    </div>
</section>
{{ else }}
{{ errorf "Impossible de charger le widget" }}
{{ end }}

hugo v0.152.2+extended+withdeploy linux/amd64 BuildDate=unknown
GOOS=“linux”
GOARCH=“amd64”
GOVERSION=“go1.25.3 X:nodwarf5”
[github.com/sass/libsass=“3.6.6”](http://github.com/sass/libsass=“3.6.6”)
[github.com/webmproject/libwebp=“v1.3.2”](http://github.com/webmproject/libwebp=“v1.3.2”)
[github.com/sass/dart-sass/protocol=“3.2.0”](http://github.com/sass/dart-sass/protocol=“3.2.0”)
[github.com/sass/dart-sass/compiler=“”](http://github.com/sass/dart-sass/compiler=“”)

http://github.com/sass/dart-sass/implementation=%E2%80%9C%E2%80%9D

Sorry, we were unable to generate a preview for this web page, because the web server returned an error code of 404. Instead of a preview, only a link will appear in your post. cry

Why do I want to do this? Because otherwise, I end up with an _index.md file for the home page where the MD content is very small and there is a HUGE front matter containing variables with Markdown. My colleagues aren’t necessarily developers, so a little front matter is fine, Markdown is fine, but otherwise they panic.

Any advice ? Thanks :slight_smile:

2

I’ve read this a few times. What’s your question?

3

Is this approach correct? And if so, how can I avoid having them appear as pages in the public output?

If it weren’t the home page, I would have used Leaf Bundles.

4

See https://gohugo.io/content-management/build-options/.

5

Yes, I know about build.publishResources, but that requires adding this variable to each widget and adding a “do not touch” comment. Isn’t there a more comprehensive approach?

I would also like to know if this is the best approach for this type of operation.

Thanks anyway :slight_smile:

6

You can cascade the values down from the site config.

7

hummmm with a cascade target. Ok. Thanks.

8

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