Nest subcategories under their parent categories in the sidebar

Subcategories should be nested in the sidebar.

Things like this example will not work unless subcategories are nested:

The resulting display would be:

In the screenshot below, documentation is the parent category, while admins, faq, moderators, sso, sysadmin are subcategories.


One detail we need to figure out here is what we do in the event that someone adds the subcategory and not the parent category… should the parent category always be included for context?


It is more or less must, if sub-categories can have duplicated names.

I’m not a dev, but I’m doing a lot UX/UI-related gigs so I would say that using same name is really bad policy anyway. So one solution would be forcing even real names be unique (and after that out there is tons of broken forums…)

But could you guys give free hand to name categories by admin way that is not related to tech of forum? It is just another visibile name for users — so then one could use something like category:sub-category.

Forcing the parent category name into the subcategory name will have a lot of redundant stuff, like:

–Ford Driving
–Ford Purchasing
–GM Driving
–GM Purchasing


I just went through and renamed all of our sub-categories with a category prefix but I also agree that nesting would a good option. Because we have different security levels on each top category, we went with the same name but I can also see the advantage of having prefixes.

It would also be nice if the categories could be toggled open and close - with over 200 categories, it is a long list.


Our intial thinking is that we may start with some simple improvements here:

  1. Always order categories by parent category, then subcategory
  2. Show the half-and-half badge style for subcategories (so there’s some visual hint of its parent)

It doesn’t solve the whole problem, but the workarounds of either: 1) having users add the parent category themselves or 2) updating category names to distinguish are both available.

We’ll keep an eye on this though and consider what other changes may be warranted.

How many of these categories do you expect a given user will add to their sidebar?


I take this as a general question :wink:

None. They are already following only those categories that are interesting and they want notifications equally from all of those.

3 posts were split to a new topic: Option to show only unread categories and tags in sidebar

Toggling subcategories in the sidebar is essential. We have nine categories and 19 subcategories already and I haven’t finished sorting. I expect to add 25 more subcategories. I would like them all to be available in the sidebar. Our corpus has been building since 1969 so our forum serves as a reference library as much as it does a symposium. For us, categories are both finding aids and conversation filters.

For that same reason, tags need to be alphabetic and scroll-able in the sidebar. We have 1400 tags and that will double by the time I am done sorting. Without a scroll window it will be impossible to present tags in a useful manner. In fact, a scroll window with a query box on top would be ideal.

It’s probably a separate discussion but putting tags in switchable pop-down windows under topic titles in list view would also be very helpful. Our topics have an average of 18 tags each. Our longest topic has 98 tags. When I present them all they obfuscate the topic titles. I mention it here because implementing a generic toggled scrollbox class could serve multiple useful purposes.

It would also be nice if the categories could be toggled open and close


Why? It would be really horrible to use, because that list will be a mile long. Well, if majority of your users have 24” screen or bigger and you don’t mind smaller screens and mobiles and your users don’t know how to use category page then maybe.

And we are back to the main issue: an user must have the choice what to see and what not. It is not admin’s job to decide.

Because it would make for easy navigation. It would be much cleaner than double width category/list view which is the only current option and which takes up way more screen than a single list with a sidebar if real estate is the issue.


Assuming you are referring to tags, a mile long alpha-numerically ordered list scrolling within a window controlled by a search box above it and a mouse wheel would be pretty convenient, way better than any other tag presentation. That includes the massive list view of the tags page which is absolutely not a convenient navigational aid because it requires whiplash paging back and forth from tag page to topic and for which the only tool is the back button on the browser.

that list will be a mile long.

So two points here.

First, Discourse is built from the bottom up for the future which means it is intended for everybody having generous, high resolution screens. It is nearly a moot point anyway, I just shopped for a new monitor for my daughter last week and found zero available at less than 24-inches.

As for mobile I can only say that navigation designed for those classes of interface is in every way different than for a desktop or laptop. Sidebars are not an appropriate tool.

if majority of your users have 24” screen or bigger and you don’t mind smaller screens and mobiles


The future, that is even normal monday already, is totally opposite. It is builded on mobiles. Sorry, but big screens are yesterday’s news.

Did you know that in Europe mobiles are more common than laptops? But we don’t have landlines or cheques anymore either (except UK/Ireland, but they are lagging behind something like 50 years :wink: )

It sounds as though your use case is more suited to discourse-docs than the sidebar.

You can see an example of the view and filtering it provides here Docs - Discourse Meta

Yeah, didn’t see that coming at all. I do think the slidebar version of the sidebar is well suited to those pesky mobile devices.

So maybe you know, is this the mobile app that comes with the lucky forums at Digital Ocean?

Stephen, thanks for this suggestion. I installed it and am playing with it. It might work for a large set of articles that we have not added yet. What I need for those is the ability to comment in order to draw the reader into discussions. I have been thinking of integrating Ghost with Discourse for the purpose.

I do still think the sidebar will be ideal for desktop/laptop navigation if it comes with a toggling scrollbox for tags, and with toggling categories.

1 Like

This part was delivered in PR

FEATURE: double color for subcategories prefix by lis2 · Pull Request #18525 · discourse/discourse · GitHub


The color badge is very helpful for distinguishing parent-subcategory relationships. Sorting and possibly indenting should solidify the visual identification of subcategories. Here’s what I mean:

documentation is the parent category to admins and sysadmin. In the current setup, they are sorted by alpha and the only indication of a relationship is the half-badge color. Obviously, this is not ideal.

When sorted, we get a sense of order and relationship, but still it’s only a color badge distinction.

A better way would be to give the subcategory a subtle indent which is universally understood as an indication of a category-subcategory relationship. The mockup above shows what that might look like when the subcategory is indented by a half- or full-width of the badge.


Thanks for taking the time to mock up these ideas!

There’s another scenario to think about: when users have all the above categories in their sidebar that you’ve illustrated but not the #documentation parent category. How would you imagine handling that scenario?

1 Like

I suppose it would depend on the site’s structure. In my OP where I used Ford and GM as an example of a structured community, not including a parent category could make the sidebar hard to read—which is which?

In this case, the parent category should be shown:

  • Driving
  • Driving

In cases where each subcategory can stand on its own, the parent may not be necessary.

For categories with subcategories, my community treats the parent as a placeholder that has no topics. Instead the topics are all in subcategories. We do have other standalone categories.

So, ideally an admin would be able to choose whether the parent category is listed in the sidebar.

:white_check_mark: Display hierarchy in sidebar


The order of subcategories in the sidebar now sort first by their parent per this PR by @tgxworld:


Did anyone figure out a solution for nested subcategories? Still browsing around and couldn’t find any theme components that work.