@tetra posted a new topic, subject "Login required to see topic info". It read:

   Is there a way to make the topic list visible of a given category, but remove the ability to see the content of the topic without logging in?

@david (David Taylor) replied

    Not with Discourse by itself, but you may be interested in this plugin. Make sure you don't use it for any sensitive information - the topic contents is still visible in search results
    
    Advertise activity in a private category (discourse-category-lockdown) plugin
    
    > This plugin allows you to restrict access to topic pages in a category. Topic titles will still show up in topic lists, search, user activity & digest emails. This is a great way to advertise the activity in a “members-only” category, which may charge for access. It IS NOT designed to keep the contents of the category 100% private - if someone is determined enough they will be able to piece together the content from search results. Each category has a couple of new settings: [57] “Locked do…

Then @tetra said

    Thanks for the link.
    
    May I ask if one is able to “hide” the contents of say… a link, unless a member is logged in?

After which, @david (David Taylor) added

    I haven't used it before, but maybe this plugin could help:
    
    https://meta.discourse.org/t/content-lock-bbcode/48293?u=david_taylor

So @tetra replied

    Thank you. Seems everything is a plugin, odd such things aren't supported on install.
    
    I appreciate you taking the time to help.

After which, @mpalmer (Matt Palmer) added

    tetra:
    
    > odd such things aren't supported on install
    
    That's because it's an extremely niche feature; check how many (or rather, how few) previous topics there are about this feature, and you'll notice that the vast majority of Discourse sites don't need this – so, it doesn't go in core.

To which @pfaffman (Jay Pfaffman) replied

    What is your problem with a plugin for such a feature?

To which @codinghorror (Jeff Atwood) replied

    Oddly enough, this request comes up a fair bit. But I believe it is for ultimately negative reasons — people want to play the peek-a-boo content game, show people topic titles then demand they create an account if they wish to see more.

@Mittineague (Mittineague) replied

    codinghorror:
    
    > this request comes up a fair bit
    
    TBH, I'm surprised that it does. Considering the fact that Google and other search engines are “non-logged in users” I would think that most would not want to trade off losing content visibility in exchange for teasing visitors into registering based solely on what topic titles they can see. If they ever find their way to the forum to begin with.

So @tetra replied

    I never even thought of that. Lol Doesn't really make sense though as you're going to lose a ton of members that way.

@tetra replied

    For me, regardless, I'm going to have a private category. Making it completely invisible to the rest of the community doesn't really make sense to me… No one would even know it exists.

After which, @tetra added

    I don't like messing with things. Even small things. I want to install, and go… default theme, default software, default everything.

Then @mpalmer (Matt Palmer) said

    tetra:
    
    > I want to install, and go… default theme, default software, default everything.
    
    Then you get default behaviour, which is to not bait-and-switch search engine users.

Then @tetra said

    mpalmer:
    
    > Then you get default behaviour, which is to not bait-and-switch search engine users.
    
    You realize just because someone “can” do something with a feature, doesn't necessarily mean they “will” do something with a feature. :S

So @Stephen (Stephen) replied

    tetra:
    
    > You realize just because someone “can” do something with a feature, doesn't necessarily mean they “will” do something with a feature. :S
    
    Yes, and I'm sure you realize that even if you're not interpreting your own intentions that way, the act of showing topic titles without allowing access to posts **is** considered to be bait-and-switch. The expected behavior by users is that **if they can see the topics, they should be able to read them**. Deviating from that user experience is widely accepted to be a dick-move, which is why Discourse doesn't have such functionality baked-in.
    
    The team aren't inflexible, if someone presents a well thought-out case for a feature or change they'll be willing to accept a PR or even build it themselves. The whole point is that nobody has been able to make a case that doesn't fall into the above category.

Then @codinghorror (Jeff Atwood) said

    Can you link to live examples of sites on the web that do what you want? So we can better understand what you are trying to accomplish?

To which @tetra replied

    steve_pd:
    
    > Yes, and I'm sure you realize that even if you're not interpreting your own intentions that way, the act of showing topic titles without allowing access to posts is considered to be bait-and-switch.
    
    … can you please explain how as long as the titles of threads contain the content suggested, it's meeting the criteria of “bait-and-switch”??

@Stephen (Stephen) replied

    tetra:
    
    > … can you please explain how as long as the titles of threads contain the content suggested, it's meeting the criteria of “bait-and-switch”??
    
    steve_pd:
    
    > The expected behavior by users is that if they can see the topics, they should be able to read them.
    
    ^ The above covers it succinctly enough, if users are presented with a resource they should be able to access it. The act of forcing users to register just to be able to read is user-hostile. Many of us will find an alternative site if presented by a login prompt. **Your role when running a community is to give them positive reasons to register, because they want to belong to the community and participate**.

After which, @tetra added

    codinghorror:
    
    > Can you link to live examples of sites on the web that do what you want? So we can better understand what you are trying to accomplish?
    
    I can give an example easily. I was a robertbrown@example.net, they have a section for supporting members. Topic titles are seen, content is not. The idea is that if you want to join in the dialogue on those topics, you have to become a premium member.
    
    image.jpg1267×1030 273 KB
    
    I can't find the logic in having permissions to prevent anyone from even knowing a category exists? Which is how it's currently set up, unless I'm mistaken? (which I could be).

To which @tetra replied

    steve_pd:
    
    > ^ The above covers it succinctly enough, if users are presented with a resource they should be able to access it. The act of forcing users to register just to be able to read is user-hostile. Many of us will find an alternative site if presented by a login prompt. Your role when running a community is to give them positive reasons to register, because they want to belong to the community and participate.
    
    No, it really doesn't… I mean, it's fine if you want to say you don't like the idea, no problem. However, it really doesn't meet the criteria of “bait-and-switch”. No doubt however, someone could use the feature in that manner.
    
    You seem to have a very broad view of what is “user-hostile”. If I want to read someones Facebook page, and the comments on posts, I need to be registered. Is this also user-hostile to you? Personally I see no issue with this.

After which, @Stephen (Stephen) added

    What you just showed us isn't an example of requiring registration to see content, it's content reserved for paying customers, the thread titles serve as an advert for the subscription/payment/whatever is required to become a “supporting member”. That perfectly illustrates our point really, it's not typical behavior in a comunity.
    
    If you're curating specific content for paying customers then take another look at the admin pages, Discourse doesn't offer that functionality out of the box. Patreon integration for example requires a plugin, it's not a part of core. Administering paying user memberships either means adding code, manually promoting users, or integrating SSO and member roles with another third party source.
    
    If you're doing any of the above it's not a huge leap to curate a list of specific paid content behind your paywall.
    
    tetra:
    
    > If I want to read someones Facebook page, and the comments on posts, I need to be registered. Is this also user-hostile to you?
    
    That's a ridiculous straw-man argument. It would be user-hostile to subject them to responses from anonymous users. Facebook allows users to set access control on their content. Search engines won't show private posts, titles to private posts aren't published to entice registration, which is what you've asked for above. If a user wants it to be public then it is, in it's entirety; if it's private then again it is, in it's entirety.

Then @tetra said

    steve_pd:
    
    > That perfectly illustrates our point really, it's not typical behavior in a comunity.
    
    I suppose that depends on the community, or how you view what a “community” is. Regardless, I was asked for an example of what I mean, I gave one. The example was to show a method of displaying thread titles, without content.
    
    steve_pd:
    
    > That's a ridiculous straw-man argument. It would be user-hostile to subject them to responses from anonymous users. Facebook allows users to set access control on their content. Search engines won't show private posts, titles to private posts aren't published to entice registration, which is what you've asked for above. If a user wants it to be public then it is, in it's entirety; if it's private then again it is, in it's entirety.
    
    No, it's not a strawman. :S Just so I understand you, you're making a differentiation between google indexing content to entice registration, vs un-indexed, Is that your main issue? Or am I not following you on this?

So @riking (Kane York) replied

    Enticing registration, versus enticing payment.
    
    The first one is casting a wide net and hurts people coming in from SRPs for dubious benefit (… you get their email address? your “registered users” number goes up?)
    
    The second one has limited scope (people definitely interested in the content) and has concrete benefit for the site (money is exchanged).

To which @tetra replied

    riking:
    
    > Enticing registration, versus enticing payment.
    > 
    > The first one is casting a wide net and hurts people coming in from SRPs for dubious benefit (… you get their email address? your “registered users” number goes up?)
    > 
    > The second one has limited scope (people definitely interested in the content) and has concrete benefit for the site (money is exchanged).
    
    I understand, and my point is… regardless, I like the feature. Just because something can be used for dubious reasons doesn't mean it will. The second one you pointed out is proof of that, and the way Discourse is currently set up will not allow for it to happen.

@Mittineague (Mittineague) replied

    tetra:
    
    > the way Discourse is currently set up will not allow for it to happen.
    
    Actually, the way Discourse is set up makes it possible for plugins to do all sorts of things. If this is something you want I think that's the approach you should look into.

After which, @tetra added

    Mittineague:
    
    > Actually, the way Discourse is set up makes it possible for plugins to do all sorts of things. If this is something you want I think that's the approach you should look into.
    
    Agreed, I'm simply arguing against this logic… all forms of topic visible content is not, is “bait and switch”, that's nonsense.
    
    I have no problems with developers doing whatever they want, and if they don't what to support this by default, no problem. I'll sort myself out.
    
    As a separate question out of curiosity, why is there a “Lounge” area for only trust level 3 set up by default, which no one will ever know about until it magically appears one day? Unless I'm not understanding (which is possible), I'm actually curious as to what that's about.

So @codinghorror (Jeff Atwood) replied

    Well, you know you can advertise the presence of a thing, without showing the thing, yes?

Then @tetra said

    codinghorror:
    
    > Well, you know you can advertise the presence of a thing, without showing the thing, yes? 
    
    So what we're talking about is “degrees” of “advertising”?
    
    Even if we grant that showing topic titles without the content isn't something that is desirable (which I don't), what's the reasoning for not showing the existence of the category at all?

To which @pfaffman (Jay Pfaffman) replied

    codinghorror:
    
    > Can you link to live examples of sites on the web that do what you want? So we can better understand what you are trying to accomplish?
    
    I'm working with several communities that have lots of content that is of interest to only a subset of the community (e.g., mineral rights in a particular state, a society with many geographic and issue sub-groups). They have a need for there to be a bunch of categories that people can know exist, but not have show up in latest. The solution seems to be to use groups to keep them from showing up, but then it's difficult for people to know that the stuff is there, and having to join a group to see it is cumbersome.

@codinghorror (Jeff Atwood) replied

    Why not use tags in that case? I fail to see why the hard walls of security are needed there.

To which @pfaffman (Jay Pfaffman) replied

    I think that the solution to the problem (given that the problem is not getting deluged with topics from categories you'll never care about and not charging for people to see them) is to mute all of the niche categories for new users.
    
    A site and/or category setting for a default watch level for categories could be very useful. For example, you have an Announcements category that you are pretty sure that everyone in your organization should be watching, and you have six regional offices that are of interest only to people in one regional office. Default settings would set new users to watch/mute those categories.

After which, @pfaffman (Jay Pfaffman) added

    tetra:
    
    > I can give an example easily. I was a robertbrown@example.net, they have a section for supporting members. Topic titles are seen, content is not. The idea is that if you want to join in the dialogue on those topics, you have to become a premium member.
    
    Another way to solve this problem is to make those categories read-only for non-supporting members. This solves the problem of people (and search engines) needing to be able to see the stuff. People who see that useful conversation is going on there will want to pay to be able to participate.

Then @tetra said

    You're correct, and I can see that working in some communities. However, I think that it is entirely dependent on the nature of the content. If the content was say, informative in nature… people would obtain the information without ever participating.

So @tetra replied

    Another problem with this feature not existing, is for communities that share sensitive content. I want people to know that we are talking about the content, but not have it be indexed on Google or seen to the general community. This is especially true in the field I currently am in.

@codinghorror (Jeff Atwood) replied

    Simply put up a topic banner announcing the presence of said hidden area. Easy.

To which @tetra replied

    codinghorror:
    
    > Simply put up a topic banner announcing the presence of said hidden area. Easy.
    
    So you actually believe that's easier than throwing out the idea to add more permissions to categories?  
    (a feature that has been fairly common in forum software as I understand it). You're not being very logical here.
    
    You've been given several examples when asked… instead of trying to offer a workaround, just be honest and say… “it's my forum software, and I don't want that feature”, or “you want that feature, go somewhere else”… problem solved.
    
    That would be especially helpful for any future request about this feature since you said:
    
    codinghorror:
    
    > … this request comes up a fair bit.

Then @Mittineague (Mittineague) said

    I think you are missing the point. Discourse is open source. It is entirely possible to write plugins that work with Core code. Plugins are not work-arounds they are work-withs.

Then @eextra (Sylwia) said

    Can I place this banner anywhere it looked like a category on the forum or section?

After which, @tohaitrieu (To Trieu) added

    This plugin is broken and not working for Discourse 2.x.x

Then @bigsmoke (Rowan Rodrik van der Molen) said

    I just wanted to throw in here that I have a use case for this feature that has nothing to do with advertising and monetizing. I'm interested in this feature for a non-commercial forum for people to discuss sensitive psychological issues.

Then @Stephen (Stephen) said

    There are better solutions for sensitive matters including:
    
      * Login-only boards
      * protected categories
      * group private messages

So @codinghorror (Jeff Atwood) replied

    codinghorror:
    
    > I believe it is for ultimately negative reasons — people want to play the peek-a-boo content game, show people topic titles then demand they create an account if they wish to see more.
    
    Still not a fan of this but it comes up a lot … community team is working on a lightweight theme type solution right @tshenry @hawk?

Then @HAWK said

    That is correct. It goes hand in hand with discourse-subscription as an upsell.

@tshenry (Taylor) replied

    Below is a link to the component I was working on. The OP was more geared toward seeing a full topic list without being able to enter any of the topics. This one focuses on exposing the existence of a category without being able to enter it. It should still be useful from an “advertising” perspective and as Hawk mentioned, could pair nicely with a subscription model.
    
    Category Previews theme
    
    > This component will allow you to add “category previews” to your categories page so users are able to see that a category exists without having access to the actual category. The preview looks like a standard category, but can link to a specified page where a user can be educated on how to gain access. I've included a simple example below, but there are many different ways this component can be configured. Please be sure to read all of the information included in the Theme Settings. Theme Cre…

So @MichaelTunnell (Michael Tunnell) replied

    I think the ability to hide content for only logged in users would be useful these days especially if there was a [hide] BBCode. For example, I have an event that I am doing and I'd like to post the link to join the event on my forum, however I do not want to give the awful spammers and trolls access to the event and requiring the basic creating and logging into an account would deter 99% of those trash people.
    
    So if I could have a link to the event join room hidden unless logged in, that would eliminate the vast majority of the garbage potential.
    
    This is similar to MeetUp.com setting it up so that people have to RSVP in order to get the link for a Zoom event to avoid the spammers.

@pfaffman (Jay Pfaffman) replied

    Can't you just put that topic on a login required category?

So @MichaelTunnell (Michael Tunnell) replied

    Not if I want to use the thread to promote the event as well. I would have to manually move it to a locked category when I want to share the link and have a separate thread/page for the promotion of the event. The simpler approach is to just have a section hidden behind a bbcode that way it makes it easy for people to get the information about the event without an additional unnecessary step.

@pfaffman (Jay Pfaffman) replied

    It would be easy enough to have a theme component hide the secret stuff (like the spoiler does), I think, but it would still be in the json load available to the browser. Having a different version of the post for some users and not others seems hard.
    
    If having it hard, but not impossible to see is good enough then I think modifying the spoiler to show only to certain users should be not too hard.

@MichaelTunnell (Michael Tunnell) replied

    pfaffman:
    
    > If having it hard, but not impossible to see is good enough then I think modifying the spoiler to show only to certain users should be not too hard.
    
    I think this would be good enough for most people, including my example. If I had this for an event I did recently it would have been a much nicer experience for me and the participants.
    
    I dont think it necessarily needs to be locked for all because if they are going to go through the trouble of scanning the DOM then I'd like to talk to them to find out why they put in that effort rather than just making an account. lol

@pfaffman (Jay Pfaffman) replied

    MichaelTunnell:
    
    > if they are going to go through the trouble of scanning the DOM then I'd like to talk to them to find out why they put in that effort rather than just making an account.
    
    That's what I thought, but everyone has different definitions of what is “safe enough”, and I usually don't bother to think that any of them is wrong. 
    
    So what you want is a `[hide-for-logged-out-users]` bbtag that just makes whatever is in it hidden from anonymous users? And you'd just include something like “log in to see the link” as part of the topic (it's not the plugin's job to let them know?)
    
    Here's how the the spoiler theme component works. I guess you'd want it to show automatically for logged in users and to not un-blur if they were not logged in. Would that do it? It might be possible to just use the spoiler plugin and add CSS that did that, but I'm not really sure.

@MichaelTunnell (Michael Tunnell) replied

    Yes, logging in would display it and a guest couldnt see it. However, the bbcode for spoiler can be activated by guests, I wouldnt want them to be able to activate at all without being logged in so not unblurring as you said could work.
    
    yea I think having to provide a message myself for how to get the link would be totally fine. bbcode doesnt need to do that.

Then @pfaffman (Jay Pfaffman) said

    That sounds right. Not quite sure offhand just how to do that. If you're interested in paying to get it done, you can contact me privately or ask in #marketplace with a budget (it usually makes more sense to craft a job to match a budget rather than propose some “ideal” solution that took more time merely to research than the entire budget for the project would have paid for).


{'source': 'discourse', 'url': 'https://meta.discourse.org/t/login-required-to-see-topic-info/78512', 'title': 'Login required to see topic info', 'views': 6103, 'has_accepted_answer': False, 'word_count': 3788, 'like_count': 86, 'reply_count': 49, 'participant_count': 14, 'posts': 52, 'tags': '', 'author': '@tetra', 'participants': '@tetra, @david (David Taylor), @mpalmer (Matt Palmer), @pfaffman (Jay Pfaffman), @codinghorror (Jeff Atwood), @Mittineague (Mittineague), @Stephen (Stephen), @riking (Kane York), @eextra (Sylwia), @tohaitrieu (To Trieu), @bigsmoke (Rowan Rodrik van der Molen), @HAWK, @tshenry (Taylor), @MichaelTunnell (Michael Tunnell)', 'image_url': [None], 'created_at': '2018-01-19T23:33:03.589Z', 'last_posted_at': '2021-03-31T20:05:53.469Z'}