We’re an open source software project with a lot of documentation pages. On each of our documentation pages, we decided to replace Disqus for commenting with (embedded) Discourse. After all, we already have a community of users using Discourse – the idea of merging the two places beginners ask questions seemed like a great idea.
However, it seems that whenever someone reloads one of our documentation pages (without actually attempting to comment – they’re just visiting the pages…) a new Discourse topic is created.
This is particularly problematic because when we set up embedding, the problem of new topics being created upon page visits did not present itself. It was only when users organically began visiting individual documentation pages that this flood began, some hours or days later.
This is what our Discourse for our users looks like now; it’s been totally overtaken by embedding. It’s caused an exodus of our users away from our community:
Is there some way to fix this? Ideally, a new topic would only be created after someone clicks the “start discussion” button.
For reference, the community I’m referring to is here:
@codinghorror Is your caution limited to the embedded implementation? I ask because we are just about to go into a testing phase prior to - hopefully - moving to Discourse.
Currently all of our network members are using a listserve - which serves the needs of many in our specialize audience. In any case, mailing list mode is how we will have to start in the new environment. From there, how members decide to use Discourse will be up to them after that. Nevertheless, I can imagine a significant number of users may prefer to stay with an email mode.
Unfortunately, we won’t be able to use Discourse without mailing list mode. We’ve elected to use Discourse as a replacement for a mailing list.
My question though had to do with the behavior of embedded mode. Even if we were not configured to run in mailing list mode, that doesn’t change the fact that embedded mode has this odd behavior of creating thread when people merely visit a page (forget about commenting). Even if we weren’t using mailing list mode, embedded mode has cause a literal deluge of noise/useless posts that people have to sort through.
Also – just a heads up, it seems the title was changed of this thread. The question still stands. Mailing list mode or not – embedded Discourse doesn’t seem like it should be creating new threads each time someone hits a page.
I’ve updated the title of this thread accordingly.
That is how it is designed to work, yes. When the request is made to load the associated WordPress (or whichever software) blog entry, the iframe containing the embedded Discourse topic is loaded. This will create an associated topic if one does not already exist.
I’ve encountered this on my discourse but a while back. My sympathies for what you must be going through!
I’d not take @codinghorror’s warning lightly - discourse is being developed for the future, and the discourse core team see mailing lists as the past. So at best mailing list mode is a compromise and you will always bump up against difficulties if you try to make it the default way people participate in your community. There are alot of topics about this here on meta you may want to read up on.
That said, there is a way to fix this particular issue, which is to set up a specific category for your embedded topics. You can then mute that category by default for all users using the plugin linked below. That way it will not email people for every new topic created by the embed code.
You can then move topics out of this category as people start talking in those topics as you see fit.
@tobiaseigen Thanks for the second warning about mailing list mode. I understand your + @codinghorror’s philosophy on this.
Though I can turn off mailing list mode right now and the issue reported still stands… There’s still a flood of new topics caused when people merely load pages. Have a look at the video I posted above. That’s a lot of noise, no?
The main point here is that embedded mode creates a new topic upon page load – it seems like this shouldn’t be necessary. It seems like it would be more sensible to create a new topic when a user clicks “start discussion,” no?
I don’t have any helpful info, Heather, but I do have some warnings.
We ran into the same issue when I set up our Discourse.
Then I realized that you can’t assign embeds to different categories. So for example, if you use Discourse embeds for comments on your documentation and also on your blog, they’ll both be created in the same category on Discourse.
Finally, I came across another issue: I deleted the slew of blog posts only to find that they could not be re-created because they were still in the database with a deleted status.
This third issue is likely resolveable by manually deleting the posts from the databases (you can’t really delete anything from the GUI), but by this point I had decided that embedding was not workable for our case.
The embed code is a bit of a blunt instrument. Like much with discourse, it works best out of the box for new sites and new content. Existing sites migrating to it need some extra planning and care… sometimes more than you realize because you’re dealing with a bunch of data and not all features are well documented or behave according to your assumptions from other software.
I think your idea is a good one but it does not exist now, and it may be more complex than you realize… and probably not worth the effort. If you wanted to implement this, you’d have to account for the fact that it would create the topic first and then the user would have to leave the site to go to the forum and reply to it, probably having to create an account first. By then the topic will be created the user may abandon the effort and not even do all that, and you then have an orphaned topic with no reply.
Much easier to mute the documentation category for all users, and maybe exclude the category from latest so it doesn’t overwhelm.
I read the feedback topic on your forum which has some good stuff in it.
Could this not be resolved by simply editing the category for comments so it is hidden from the homepage? (I believe it is in Edit Category > Settings)
Sorry, can you explain how changing the behavior of topic creation so it doesn’t flood our community with empty topics is a feature request? You’re arguing that this is behavior is correct and intended?
Hi Heather! I’m just a fellow user trying to help you here. I’ve been through what you’ve been through and recognize it. But what I described above is my understanding of how this feature works… and it’s by design. It’s not broken, preventing normal/typical use of discourse.
Discourse embed is a very simple, hands-off bit of functionality that’s ideal for new sites creating new content. That it can cause pain when added to sites with lots of existing content is obviously not great and I’m sorry you had a bad experience. I guess the howto topic explaining how it works (which I assume you followed) could have been improved with a warning about the risk of flooding the forum and people’s email. Muting the documentation category for your users and hiding documentation topics from your frontpage will be a big help going forward, methinks.
Meanwhile, the feature could be improved to add the functionality you describe which is a good idea! I use the wp_discourse plugin now on a site I actively manage, and I would love to be able to turn on the ability for logged in users to start new topics about content on my site, but not create all of those topics in discourse ahead of time in readiness for someone coming and wanting to reply to one of them.
I’ve been through what you’ve been through and recognize it. But what I described