In a top category page, show only its own topics below subcategories

So, in our community people have been refused to understand and get used to the way categories work in Discourse. They get confused again and again. Nobody can understand the following Discourse’s concept:

  • A top category can have topics
  • A subcategory can have topics
  • A top category can mix its own topics with topics of its subcategories and show in a single list

I don’t know why, but people just don’t understand it. They are used to a structure book alike:

  • Category can have sub-categories
  • Categories can have topics

I was thinking about a way to improve user experience for our use-case.

Thing 1. On a top category page, show two things only:

  1. The list of subcategories
  2. Topics found in the main category only; show it under the list of subcategories

Thing 2. Hide 2 items in the subcategories dropdown list:

So that only subcategories are shown, no “all subcategories” nor “none of subcategories” items.

Is it possible to configure Discourse as outlined above?

We really struggle to structure our categories well: we don’t want to create a lot of subcategories as I’ve read a lot here on Meta that it’s not recommended and will eventually fail. Yet we still need some subcategories, and we fail teaching our users how it works as it is now.


I think you should do away with categories and use tags only in that case. Look up the gethopscotch forums to see a site like that.

I should have been more clear about categories.
Our community members really like categories and need them.
They just don’t accept the concept of mixing topics from top categories and their subcategories.

The problem would be solved partially if there was a setting not to show topics from its subcategories on a category page. So that only subcategories are shown and then the list of the top-category’s topics, but not its subcategories.

Would it be difficult to implement such a setting? Basically just one more setting/filter to the topics selection query.


This is a problem for our users also. It makes top level categories unusable for users who still want to read by category*. In real terms it means we might need to add an extra level of subcategory, to allow users to filter by that specific category. Having the option of hiding subcategory topics from the parent category view would fix this.

We migrated from phpbb, and have more than 10 years worth of categorised posts, so it’s not so easy to drop the hierarchical information schema.

  • most of them, apparently.

So this is the proposal?


From what I remember, the original idea was this:

It is still an issue though. People do not understand that topics can be posted in a top category as well as in a subcategory. For many people it is confusing.

I would try any solution available (except using tags only), but I got no ideas on what I can do with using the mans available currently in Discourse.

What we need is:

  1. Make it clear that a category and subcategory both CAN hold a topic.
  2. Make it clear that when viewing a category, you will also see all topics from subcategories (alternatively, configure it so that no topics from subcategories are shown when viewing categories).
  3. Make it distinguishable and more intuitive about “all subscategories” and “no subcategories” in dropdown list. It is a confusing concept and difficult to translate in a way that would make sense and be treated intuitively.

In our community, this issue is still open and has not been addressed successfully.

Having the option to hide subcategory posts would be helpful for us also. We have a main category for Feature Requests and subcategories of Accepted, Scheduled and Not Planned. Hiding the subcategory posts would allow our customers to better see which requests have no status and use the Voting Plugin (love it!) to vote on them.

Just my two cents!


Bumping this @codinghorror

Any thoughts about this feature?


Another vote for this feature:

In our setup, subcategories are expected to be very noisy because they are nurtured by embedded posts from different sources. We scan the subcategories and promote the best topics to the parent category. Ideally, users visiting the category would only see the promoted posts. With the Latest setting they would see everything, which defeats the point. We are using Top for now, as a way to at least have the most popular posts on top.


We’d like to see this as well.


Can’t you go into Edit :arrow_right: Security :arrow_right: Edit Permissions and set the top categories to all be read-only to non-staff users?


Any update on this? I’d like to set it as the default for my community.


My community is also in favor of this feature, as we migrated from Simple Machines Forums.


Should this be moved to the feature section?

1 Like

And if you do it with CSS?

For example, for a category:


.collection-header .category-filter {display: none;}
.category-dev {
.category-dev-translations, .category-dev-sso {display: none;}

That’s a solid workaround for the time being. Thanks!

Only downside is the number of topics displayed will be less than usual if there are hidden posts, but that’s negligible in my case.

Ideally there would be a “suppress topics from parent category” setting for each category that is a subcategory.


Shameless bump but this would be great for us, too.


We sometimes have different settings for subcategories (some with voting, some with an event). When they are mixed up and shown in the parent category, it creates some weird UX patterns with certain actions/information on certain topics, and certain not.

Having such an option (to show topics only from current category) looks like it might help in both visual and interaction noise :slight_smile:


Yup. Our community definitely needs this, too. Just a tiny checkbox in the settings would do!
@sam @codinghorror any reason why you might delay this?

1 Like

We currently have this which works.

The feature request here is for:

Default List Filter:

[all topics] (default) 
[no sub categories]

Something like that.

Seems reasonable to me, sort of doable in a theme component but it is somewhat tricky cause you need to muck with ember routing and get a double request which is not ideal.

@codinghorror should I slot this? Has popped up often enough.