BookSection: "*" should group by folder about hugo-book HOT 10 CLOSED

I haven't run test, but I think even with thousand of pages in side menu browser should not struggle to render. Regardless of that 1k pages in sidemenu probably will result in bad UX.

I think to add variable like bookMenuHide: true to hide page from side menu even tho it's rendered by hugo 🤔

from hugo-book.

Here we go

# (Optional) Set true to hide page or section from side menu (if BookMenuBundle not set)
bookHidden: true

from hugo-book.

Hi!

I pushed an update, please check if it is what you are looking for.
New logic is:

• If there is "*" all sections rendered first level
• If one specific section is set - then menu rendered starting from first level children

from hugo-book.

Thank Alex, looks great but I am worried about showing all the posts in the menu which ultimately will lead to clutter.
Would it be possible to simply have the Posts folder and have them as a blog in there? with pagination?
Sorry if I am asking something crazy.
thanks

from hugo-book.

I think in your case it's hard to add it in generic way into theme,
I would suggest you to override layouts/partials/docs/inject/menu-after.html and add something like

<ul>
  <li>
    <a href="{{ relref . "/posts" }}">Blog</a>
  </li>
</ul>

This will effectively add Blog link into menu.

from hugo-book.

Nice one! thanks so much Alex... I will give it a spin.

from hugo-book.

Interesting approach with the posts folder. Will jump in on this thread with a couple of related questions if that’s OK:

1. Is this approach possible for docs subfolders too i.e. can we render their single pages as a paginated list too while keeping only subfolders on the menu? (Right now navigating to /docs/ shows an empty page while /docs/subfolder/ throws a 404.)

2. If we have several hundred single pages under about ten or twelve docs subfolders, does it take a toll on page load. (The importance of 1 gets bumped up if there is a hit on page load with the current set-up.)

from hugo-book.

1. I think it will be too much opinionated/hardcoded to have paginated list in /docs but you can control content of /docs with content/docs/_index.md file. You can check that in exampleSite

2. Menu is generated statically and it's a text, so I believe there will no be performance hit, unless we talking about tens of thousands of pages. I would suggest to use bundle menu for such big sites.

from hugo-book.

1. Perhaps you're right. I took a look inside exampleSite and I think I follow. Thanks.

2. I understand you mean that a bundle menu, i.e. the one displayed based on manual curation in menu/index.md, will not take a performance hit despite a few thousand pages. Is that correct? It does make sense since, for the reader, all that’s being done is a bunch of html being rendered on screen.

from hugo-book.

Haha. True. But I've made the menu collapsible so it should help from a design perspective.

I think such a front matter option would a good idea. It's not overbearing and it provides useful added functionality.

from hugo-book.