menu: optionally disable index pages for sections

[RoarkGit]

I would like to have the option to disable the index page for a given section, but still have that section appear on the menu.

For example, suppose I have the following layout

.
└── content
    └── posts
    |   ├── _index.md
    |   ├── post-one.md
    |   └── post-two.md
    └── articles
        ├── _index.md
        ├── article-one.md
        └── article-two.md

What I would like is for my navigation menu to still show “Posts” and “Articles,” and expand to show their subpages when clicked. However, I would like for the “Posts” and “Articles” entries in the menu to not redirect anywhere themselves. If I am on /articles/article-one and click on Posts, I would like to remain on /articles/article-one but have the Posts section expanded.

[McShelby]

I've chimed into the discussion in the Hugo discourse forum but I think this is better kept here.

Once I saw your request I started to poke around in the code.

There are a few oddities related to this:

• Would you expect the breadcrumb on post-one to contain posts? In my experiments I am adding a non clickable breadcrumb for it.
• If you have collapsibleMenu=true in your config.toml I would keep the expanding functionality solely to the expander icon. Otherwise it would be suprising for the user that there sometime is page navigation and sometimes not. The text itself would not be clickable.
• If you have collapsibleMenu=false in your config.toml I would always expand that section without a way for the user to close that section. If a user wants expanding behavior he needs to set collapsibleMenu=true - which will change all sections of the menu to be collapsible

While I already have managed the menu creation, generating the breadcrumb and getting prev/next navigation right, is still an open thing. Also children shortcode, RSS, search index and sitemap also need some fixes as there is no URL for such pages.

[RoarkGit]

Would you expect the breadcrumb on post-one to contain posts? In my experiments I am adding a non clickable breadcrumb for it.

I would expect clicking on posts to expand that section to show post-one and post-two in the menu. Clicking on post-one would then redirect to post-one with the URL being /posts/post-one. I think having the breadcrumb for the title is probably still valuable.

If you have collapsibleMenu=true in your config.toml I would keep the expanding functionality solely to the expander icon. Otherwise it would be suprising for the user that there sometime is page navigation and sometimes not. The text itself would not be clickable.

I see what you're saying here. I think I would expect to maybe have it as a global default to never involve page navigation, but if it is per-page configurable then I agree with what you're saying.

If you have collapsibleMenu=false in your config.toml I would always expand that section without a way for the user to close that section. If a user wants expanding behavior he needs to set collapsibleMenu=true - which will change all sections of the menu to be collapsible

I'm not 100% certain I'm following what you're saying here, but yeah I wouldn't expect someone to be able to close a section by clicking on it again. I would expect the only way to close a section would be to open a new section.

[McShelby]

I've pushed the changes and am pretty satisfied with the outcome.

While a next official release will not come this week, feel free to test it directly from this repo.

Feedback welcome!

[RoarkGit]

I took a look and the core functionality is definitely there. Any feedback I have is fairly nitpicky:

• When expanding a section, I would expect the background of the child entries to be --MENU-SECTIONS-ACTIVE-BG-color. I get that the section isn't active, but it seems weird to have an expanded section sometimes have the default background and other times have the active background.
• Having an option to make the full section clickable for expand/collapse instead of just the collapsible menu would be nice (text itself being clickable). I agree that it could be confusing if sometimes it redirects and sometimes it doesn't, but for at least one of my use cases I would want it to never redirect and always expanding the menu instead.

[McShelby]

Any feedback I have is fairly nitpicky

I don't have a problem with this. Actually that's how I am, too ;-)

When expanding a section, I would expect the background of the child entries to be --MENU-SECTIONS-ACTIVE-BG-color. I get that the section isn't active, but it seems weird to have an expanded section sometimes have the default background and other times have the active background.

That behaviour hasn't changed with this patch. --MENU-SECTIONS-ACTIVE-BG-color (and ---MENU-SECTION-ACTIVE-CATEGORY-BG-color) both refer to the currently displayed page and color related areas of the menu accordingly. The expand state of the menu is completly unrelated to this colors.

Having an option to make the full section clickable for expand/collapse instead of just the collapsible menu would be nice (text itself being clickable). I agree that it could be confusing if sometimes it redirects and sometimes it doesn't, but for at least one of my use cases I would want it to never redirect and always expanding the menu instead.

As stated in my previous comment, I find different click behavior for allegedly similar menu entries quite confusing for the user.

[RoarkGit]

Having an option to make the full section clickable for expand/collapse instead of just the collapsible menu would be nice (text itself being clickable). I agree that it could be confusing if sometimes it redirects and sometimes it doesn't, but for at least one of my use cases I would want it to never redirect and always expanding the menu instead.

As stated in my previous comment, I find different click behavior for allegedly similar menu entries quite confusing for the user.

I agree, but making it a global toggle would remove that confusion, for example:

alwaysExpandSection = "true"

Could make it so that section pages always exhibit this behavior and allow for clicking of the text.

[McShelby]

Right now I will keep it that way until further feedback from other users.

The DOM and CSS would need some non trivial update for this to work, which is currently too much effort with not much gain.