Removing Uncategorized and migrating to a standard category

[lindsey (Lindsey Fogle)]

The Uncategorized category was intended to serve as a home for topics that don’t fit the community’s category structure or haven’t been categorized yet, but the special nature of Uncategorized created bugs and inconsistencies.

That’s why we’re removing it and migrating everyone who was using it to a standard category that will provide all the same benefits, but without these issues.

What’s changed

When the Remove and replace Uncategorized category upcoming change is enabled, the special Uncategorized category becomes a standard category. If this category was set as the default composer category (meaning it is the default category when someone opens the composer), the standard category will set as the default. All topics in the Uncategorized category will remain in the standard category.

All in all, this should be a seamless and invisible change to your staff and community members.

For communities using tags only (no categories): If your site was relying on Uncategorized as a way to avoid requiring category selection, you’ll want to install the discourse-tags-only-component theme component to hide the category selector in the composer.

You’ll also need to set default composer category to your single default category, and remove Categories from your top_menu. Categories remain accessible in /admin and while creating chat channels.

Turning on Remove and replace Uncategorized category in your community

To turn this on early, head to the Upcoming changes page in your admin area (/admin/config/upcoming-changes) and find the Remove and replace Uncategorized category item. Update the Enabled for… field to opt your site in:

Note: This upcoming change will only be visible to sites that currently have allow uncategorized topics enabled.

[steffahn (Frank Steffahn)]

I just saw that this change is already at the stage of “will become permanent soon. You will no longer be able to opt-out.”

Unfortunately, I can’t entirely confirm that this change is a

@lindsey

seamless and invisible change to your staff and community members

… as far as can tell, this e.g. changes that uncategorized posts now bear an “Uncategorized” badge. (Also “Uncategorized” used to have some special casing in the topic creation UI, that differs from just having a pre-selected entry in the dropdown.)

I could find this comment from a year ago

@sam

My recommendation here is

1. Delete both settings and delete the hidden setting uncategorized_category_id
2. Have a concept of default category (which we already do) - we already have default_composer_category
3. 'uncategorized` then is no longer a special concept, less stuff to reason about.
4. Have a theme component for people that must have a “category without a badge”

which mentions a theme component, and I agree a theme component would be a great solution to reduce the amount of change this introduces to the UI for users of a forum.

I couldn’t find any existing work regarding such a theme component though. Am I overlooking something? (I suppose I could try to roll my own^[1], but I would doubt that I’m the only person^[2] who would prefer/choose to just keep uncategorized topics work more like they used to, at least on the front-end/client side of things.)

---

1. and also learn how to actually do that ↩︎

2. for context, I come from users.rust-lang.org & internals.rust-lang.org, which I help administer ↩︎

[gormus (Osman Görmüş)]

The Uncategorized category was the one I always filtered out in my queries as we never enabled it since day 1, so I welcome its removal, thanks @lindsey

However, I had a rather unexpected experience today.

TL;DR; The Uncategorized category was enabled for everyone, and there were already two topics created in it.

Let me take a step back for a larger picture. Before the latest release deployed on our production last night,

• the allow_uncategorized_topics setting was set to false,
• the Uncategorized category was never used and empty; practically invisible to all users.
• the Remove and replace uncategorized upcoming change was enabled for Everyone

Just because the category was never used, and empty; I expected it would be removed completely.

It might be just me misreading the feature description, but I still was surprised to see it became a public category.

I think it would helped better if there was a clearer wording, and explanation of what to expect in various configurations.

For the record, I moved the topics to another category, and changed its security settings to make it admin only. So it is not an issue at the moment.
Once I have the time, I’ll review, and eventually delete the category completely.

[lindsey (Lindsey Fogle)]

Thanks @gormus for reaching out — we’re looking into this and will share an update here soon!

[zogstrip]

@gormus

Just because the category was never used, and empty; I expected it would be removed completely.

that’s kinda tricky because there are some many “cases” where people have repurposed the “uncategorized” to something else and we don’t want to delete stuff in an irrecoverable way.

DEV: Reset category settings that point at missing categories (#44385)

will fix it, and only delete if that “category” has never been touched.

[satonotdead]

@zogstrip

will fix it, and only delete if that “category” has never been touched.

I really appreciate this effort on this kind of approaches. Praise to the team