Enabling category previews for restricted paid access categories

One thing I find repeatedly missing and very cumbersome to work around on Discourse are category previews. Working with clients on Discourse themes, they often have restricted categories (either for signed in users only, or for paying members), but they still want to publicly show all the areas they offer to attract more signups. An example I’ve been given several times is circle’s interface. All the spaces are visible, but if a user doesn’t have access they will see a banner note with a call-to-action for gaining access:

I know there’s a Category Previews component on meta, but it doesn’t allow this usage flow. You could only add a manual replacement of the category link on the category list. But users without access still won’t be able to follow the regular category link. And the category link will not show in other places.

I’d love to see an integrated option to allow previews of restricted categories. So if checked, the category link would show up as other category links. When followed, only the category header and the “About the …category” topic are visible.


@nolo are these the same / related? :thinking:


Yes, it’s similar requests. But I didn’t find a solution in these topics. In my experience this usage is becoming common, but the solutions offered by manual workarounds or the plugin require a lot of set-up and maintenance, either by a theme author and/or by community managers. They also easily lead to errors when the site structure is changed.


Can you make the parent category readable by everyone and not writable, and then only make the subcategories readable/writable to those granted access?

That way you could have an “about this category” topic and a banner at the parent level, and then all the restricted content can be unlocked when someone gains access to the subcategories. That requires some extra categorization, but may have fewer downsides of some other approaches…

Another workaround of course, but we don’t currently have any category preview work scheduled.


Just wondering if by Visible did you want users to be able to view the categories? But not post/reply?

Or just a Category List with the description?

1 Like

Yes, I’ve tried this approach, but think it’s generally not intuitive for users that actually have access to understand that they only can post in the sub-categories. This gets complicated by the fact that the “New Topic”-button will not show when entering the umbrella category. So this needs an additional workaround in the design.

Thanks for the heads up! Well, I just wanted to share this feedback, because I think there’s three basic category modes: Public, Restricted and Secret. Other platforms make it very simple to choose one of those modes. Here’s the setting on circle:

Screenshot from 2022-01-18 19-53-44

On Discourse we have Public and Secret. And the Private/Restricted mode defaults to what @Heliosurge mentioned: View the category topics, but no post/reply. But that setup is a rather rare requirement, as it is typically already covered by not being logged in to a site.

I think the more common default for Private/Restricted would be just the category page with a lock and a description.


If your looking for Category to be open but no post reply.

Goto Category Settings

| Group | Permissions |
| Everyone | See |
| GroupName | See/Create/Reply |

There is another page where if they try to post/reply a string can pop up saying ie request Access

1 Like

I’m pretty sure they want the option to only allow people to see the title of the category but not the topics and their posts within the category. I’m pretty sure what you suggested will allow people to see category name, topics, and posts but I could be wrong.


Yes, just as on the first screenshot shared above. I think this is a common scenario when the intention is to monetize certain areas of the forum: Clients typically don’t want these areas to be a secret, but show users what the forum would offer when they choose to pay.

As mentioned before, to me the other option (see all topics, but can’t reply or create new ones) is typically covered already by the distinction between anonymous visitor and logged in member. It’s rather rare that this experience should be repeated for logged-in users.

That’s the whole point of this feature topic: I think the one option is more common, but difficult to implement in Discourse. While the other is less requested, but is currently the default behavior with Discourse.


This isn’t a common use case in our experience. The more common use case is for the whole forum to be paid access.

1 Like

Yes, I’d love this feature as well for the reasons you mention, to advertise to users that it exists and there is a way, whether thru application or invite or even paying, to access it. I can see many uses for it as I consider having a tiered community for both a podcast and also an online martial arts training.

That being said, I still see the value in hiding the category names as well, but would love the three options you suggested.

1 Like

That can be accomplished by this plugin Advertise activity in a private category (discourse-category-lockdown)

1 Like

I believe I found a workaround that lets me realize the desired user experience without messing with Discourse’s security architecture.

This example is not about paid-restrictions but with a similar goal. We have restricted categories for working groups on this forum. We’d still want to promote their existence and attract interest in joining them. So I’d like these categories be visible for every forum user as on this mockup:

Now to show the categories, no matter if a user actually has access or not, I added the restricted ones plus I added public “shadow” categories to each of them. Here’s my admin view of all categories for Community Builders and Translators:

Now a user without special access just sees the public boxes and can visit the categories and find respective information about the groups:

Once a user has actual access to a restricted category, I hide the public one with CSS. Let’s say a user joined Translators. They will have this view:

I use a component to address user groups with CSS: https://github.com/discourse/discourse-groups-css-classes-in-body/

Then the declaration is rather straightforward:

body.group-translators {
    .select-kit-row[data-name="Join Translators"] {
        display: none !important;

Well, it’s still some effort… but I like the user experience. And it adds the advantage that users that don’t have access to the group as such can still engage with group leads on the public categories – without adding noise to the actual group discussions.