Suppress category from latest topics gone

Hi, it’s not equivalent and we gave a lot of example above.
It’t would be fair to make clear statement that you are not going to revert this options anyway or some sort of it.

I think several maybe tens of admins/community admins are still waiting.


It does apply to anonymous users.

This whole storm is about sites asking for certain levels of fidelity.

They want latest topic list to look “just so” and for end users to have no control over how “just so” they look.

In the case of @Heather_Dudley / @ClawdiaWolf this can be a problem for end users. There was a suppression of all “regional” categories from home page. Cause there were 400 regions and it gets noisy.

But what about a user Sydeny, why is that user not allowed to see topics from Sydney on home page?

To address that we allow sites now to work in a mode where stuff is default muted and mods can opt for “default displayed” categories, this makes it far easier to maintain going forward. When you add a category you don’t need to do anything and users can still follow Sydney if they wish.

I think where this is going to end up is that we will provide plugin hooks for people that want a hard dictation from above about what topics may never ever ever ever be displayed on latest topic lists.


Does that mean that there is no way to fix our foreign language section?

Those categories are currently hidden from the “categories” page, and the foreign language posts are appearing in “latest”, which is just supposed to be English. I’m not sure if people are no longer receiving notifications for the foreign language sections.

Even if I go to the parent Non-English category (seems to not be discoverable by users), only one of the language subcategories (Nederlands) is listed there — the other language categories are gone.

Strangely, if I post in one of the language categories, that post will still appear in /latest, even though the category page itself is gone.

Is there any way left to keep topics off the front page without muting them?

I am still not following here.

Say you default mute “French”

  • “French” topics do not show up on front page for anon and all users

  • “French” people can still unmute this in user prefs and see the category on front page

1 Like

The only problem that I see for the site that I’m looking at now is that there is no way to know that there is a French category to un-mute unless you find it in your preferences, or, perhaps, have a topic (or header link, or similar) that links to the French category.


Sorry, I think I’m a little confused about what the change did. When people went to /categories before, there was a list of foreign language categories. Now those categories are gone and I’m not sure how to get them back in that categories list. Those categories’ posts shouldn’t end up in /latest though, because “latest” is only for English posts.


hmmm … a user pref for

“Hide muted categories from category listings”? default off. Something like that.

Then once you know the ropes you can turn it on.

Does this 100% address the complaints around the new change?


Something appears strange. When I go to the parent category (/c/non-english) with an admin account, I see only the “Nederlands” category (the latest addition to categories). If I go to /categories with an admin account, the Non-English categories aren’t there.

When I log in with a test account (TL0), I can see all 9 Non-English categories on /categories and /c/non-english pages.

My test post in a non-English categories goes to /latest though, which should just be for English.

Edit: both the admin and TL0 user get the topic set to “watching” after making a post. I don’t see “muted” there.

Not following.

Muting categories refers to a default state, any topic in that category can still be tracked and watched by users overriding default state for the category.

No, because muting will still bring specific topics into /latest once a user interacts.

The old approach let site operators throw up partitions where they deemed it necessary. Muting was already there but as the above posts indicate it’s much messier.

Where once there was ‘suppress this category from latest’ there will now be:

  • a category setting for muting
  • a user setting for muting
  • a user setting for visibility

If you’re going to truly replicate the original behavior, we would need an additional setting to stop posts from muted categories creeping back into latest, because as we’ve read some site operators have use cases where it’s advantageous.

A project I’ve been working on will soon go on-hold because of this issue. The client wanted to use Discourse for internal collaboration, with certain categories suppressed as they either contained discussion of as yet unannounced titles, and ‘off-topic’ matters. They liked the behavior that suppress from latest gave them because even if staff participated in topics within those categories, the topic titles wouldn’t be visible on / (which was to be latest) meaning they would have to seek out those categories. For now my suggestion is again that they have a secondary separate instance to achieve the same separation.

Default state for the category refers to the default state for topics originating from a particular category, a state which can be overridden when a user interacts with it. The assumption in all of the above is that this behavior is always desirable, but looking at multipurpose instances that doesn’t appear to be the case.


This is something I have some fundamental disagreement with. If a user is explicitly tracking or watching a topic they are providing very strong signal that they actually care about a topic and want it on latest. If they don’t want it on latest they can always just flick it back to normal no?

Not following this.

All I am proposing here is a user option for:

“I really really never ever care about muted categories and never want to see to them” aka. “I really really hate politics”.


“I usually don’t care about muted categories but I still want to browse them sometimes, so keep them in my drop downs and in category lists”"


Isn’t the simpler and more consistent action to take simply to amend it so we don’t ever start auto tracking topics in muted categories. Seems like a better default to me.


Eventually you end up building the same feature that everyone already used, but end up hiding access to it behind five or six other preferences. The Discourse equivalent of the Konami code, if you will.

If the behavior of those settings are ever reworked we find ourselves back here when posts start appearing where they shouldn’t.

In the end is this actually simpler than locking access to suppress from latest behind a site setting?


I much prefer having “I want to go on a weird and wonderful adventure” kind of things in a plugin.

Fundamentally the user has the right to choose what they see in “latest” and what they do not. Having a setting that allows for weird partitions where the user loses control feels to me like the domain of plugins.

I guess, I am kind of open to making some sort of plugin here that restores the old functionality for the rare sites that feel they really really want this, having his anti-user feature in core makes me uneasy.


That’s a very selective view. If you’re an employer wanting to offer staff a coaborative environment and entertaining the idea of allowing limited “non-work” categories such a feature can be highly desirable.

It has the potential to be anti-user, but there are lots of things which if misconfigured can be destructive to a community.


Hi again,

The thing we (people who still favor the “suppress option”) are trying to outline here is that

"I as a site operator want to control the behavior of posts from specific categories to not appear within /latest"

which I still believe is completely orthogonal to the “muted categories” thing.

I believe that is a viable (DWIM) option with respect to the “muted categories” thing. Nevertheless, it doesn’t solve the “suppress category” requirement for some of us.

That would be awesome. If it isn’t possible at all to keep that feature within Discourse core, putting it into a dedicated plugin would save the world for us.

Is there a chance to work on that / release this in parallel / soon when the removal of the “suppress category” feature will hit more people?

Thanks again for listening and with kind regards,


Isn’t this “by definition” anti user? You are saying “you are all children I can not trust you even with minimal amounts of self control here, if you want to have these kind of discussions head there :arrow_right:

I do not want to let you unmute this category, you can never see this except for in the jail I build you.

I would consider it a compromise.

Employers are under no obligation to create such areas. The obvious benefit is that it aids uptake of new tools, but you don’t want those value-adds to overtake the original purpose.

1 Like

I would say in a work environment this kind of compromise quickly loses teeth with stuff like the sidebar theme which tends to work extraordinarily well in work environments and this is a feature kind of orthogonal to it. When you use sidebar you tend to spend a lot less time in latest anyway.

I am kind of swayed to just provide a plugin here for the old feature.


Again, +1 on that one!

I totally hear you and recognize your perspective here. Using the “muted category” feature will give more freedom to the user as she will be able to self control what she gets within /latest. However, I would like to outline that the “suppress category” feature is not necessarily about censorship at all – at least from our perspective.

Rather, we see and use the “suppress category” feature as moderators in a way to reduce noise coming from categories occasionally or permanently having high traffic in order not to clutter /latest for all users (anonymous and logged in).

Giving another example here, this might come from automated posts to specific categories when using things like GitHub - huw/github-to-discourse: Forwards commit data from a GitHub webhook to a Discourse thread. Posts originating from things like that are not even “real discussions” at all in these specific contexts of using Discourse beyond the original use case as a discussion forum.

If that might hit some rare sites or not is beyond what I might imagine about. So, let’s amend the perspective into something like it might be a crucial feature for some sites running a specific sets of features or requirements.

So, having this functionality available through a plugin in order to satisfy the needs for these kinds of specific sites would probably be totally fine for everyone arguing here to keep that very option.