HUGO

Is it possible to generate list but not single files

Hi,

I would like to generate a list for my archetype “bookmark” (easy to do), but I don’t need single files.
I don’t need to generate one HTML page for every single bookmark, just the list.

Is there any way to do this ?

Thanks

See Build Options available since 0.65.0

Thank you for Build Option documentation.

I checked the documentation : https://gohugo.io/content-management/build-options/#listing-pages-without-publishing-them

I created a content/bookmarks/_index.md file with the content from the documentation:

title: Signets
_build:
  render: true
cascade:
  _build:
    render: false
    list: true

See my content:

$ tree content/bookmarks/
content/bookmarks/
├── 2020
│   └── 03
│       └── 22
│           ├── test.md
│           └── webmention.md
└── _index.md

In the end, it does not work as expected: the individual files are generated:

$ tree public/bookmarks
public/bookmarks
├── 2020                    <- this folder should not exist, right?
│   └── 03
│       └── 22
│           ├── test
│           │   └── index.html
│           └── webmention
│               └── index.html
├── index.html
├── index.xml
└── page
    └── 1
        └── index.html 

(I also lost the {{ .Title }} property in the generated file)

Any idea why this does not work as described in the documentation?

$ hugo version
Hugo Static Site Generator v0.67.0/extended darwin/amd64 BuildDate: unknown

Any idea why this does not work as described in the documentation?

No, it should.

Do you have repo somewhere?

My repo is private for now: I will try to make a minimal repo to share.

(I have to work right now, so I’ll come back later)

Took the liberty of creating a mininal one trying to mimic your usecase: https://github.com/regisphilibert/dir-build-options

You can checkout content/bookmarks and run hugo serve to see everything works out.

Now of course, i’m curious to see your repo to make sure everything checks out.

I made a public clone expurged from most of the content here: https://github.com/jpcaruana/hugo-issue

Can you allow me write access on the repo? I’m @regisphilibert on GitHub.

invite sent :slight_smile:

Just pushed the fix.

Thank you @regis.

I checked the doc, there is no --- in the examples…

Yeah we usually leave the Front Matter delimiter out of the doc as those are “excerpts” from the Front Matter (not the whole enclosed Front Matter) but you have them toml delimiters in your other files (+++) it’s the same thing here but for yaml.

solution: see https://github.com/jpcaruana/hugo-issue/commit/0b113765c3cc5a9fd45b0408cec4bf2c9f15d62e

I forgot in my _index.md to put the example from the documentation in the frontmatter (between a pair of ---)

1 Like

this is a big issue to me: as a newcomer, the doc is not easy to understand, you cannot copy/paste (without understanding what you do, I know) examples from the doc.

When fiddling around, you sometimes forget “oh yeah, this is the frontmatter”, you just think “how do I solve my issue”.

documentation is really very contextual

We cannot give full file examples. We have to minimize with what matters. The page intro for Build Option is:

They are stored in a reserved Front Matter object named _build with the following defaults

Every subsequent examples are therefor written as such: Front Matter. I understand it would help newcomers, but we cannot repeat Front Matter essentials on every feature documentation which deals with Front Matter. Having declared that the context of this feature’s configuration is Front Matter, we have to assume the user understands Front Matter syntax beyond this point or will check the Front Matter documentation.

Yes you are right ; I read too fast and skipped the line you quoted here.

As a personal feedback on this and as a writter of technical documentation myself (this is not a rant in any way), it is enfuriating to see readers skip most part of our prose and go directly to what they “need”… But to me, it is also our job as technical writters (in addition to making code work as expected) to make our documentation as useful as possible for our users and help them have the maximum of information at once.

Here for instance, maybe a different color, or some kind of visual clue, would help to understand “oh yeah, this is some front-matter stuff, this is some template/partial stuff etc”? What do you think?

In the end, I should have read the documentation a little bit slower, there is no excuse for skipping important piece of information.

Thanks again for you help.

As a personal feedback on this and as a writter of technical documentation myself

We’re always in need of technical doc writers. Feel free to look at the Doc repo and create issues or PRs where you see fit.

Thanks again for you help.

You’re very welcome.

1 Like

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