This is a fantastic feature! I look forward to making good use of it.
Would it be possible to not automatically create a topic until a user chooses to comment on the article? I want to prevent having a ton of topics with no replies (i.e. which were created automatically by visitors who only read articles and not commented on them). I’m specifically thinking of a site with a large number of articles; only a few of them will actually have comments.
What would be the most reasonable way to achieve that? Any thoughts?
No this is not possible. Discourse doesn’t support commenting on things that don’t exist yet, so the topic needs to be in place when they navigate over to post.
I understand. But when exactly is the topic created? When (a) the blog post is loaded, or (b) when the user clicks on the link to write a comment? What I want to prevent is a ton of topics being created as users read blog posts (and not comment). That’s because all these topics would end up being empty topics with no posts. For a site with millions of articles, that would swamp the forums.
The blog post is created the first time Discourse successfully crawls it. This usually happens shortly after the first request for the IFRAME that shows the comments. So if people are viewing your blog entries, you will be getting topics generated.
That is exactly what I thought, and what I think might not be the desired behaviour for many sites, specially large-scale ones. And that is precisely because of the number of empty topics that would be created as people are simply reading articles. For a site like the one I manage, this would mean millions of empty topics being generated as soon as the integration is in place (as we have millions of articles).
That would be far from ideal.
Would it be possible to only create the topic when someone publishes a comment?
Or, at least when someone clicks on “Write a comment”, or something along these lines…
No, it is a huge change architecture wise. On Discourse you need to post replies on topics. There is no concept of “replying to a topic that doesn’t exist yet.”
Yeah, I wouldn’t suggest changing such a fundamental part of the underlying architecture. But I reckon we could change the way we automatically create those topics as triggered by the JavaScript embed code. Instead of creating a topic once the iframe is loaded, couldn’t we make the link “Write a comment” point to a script that will then create the topic and then display the post editor?
That would be a huge improvement to the terrible scenario I described above.
There are issues with this approach too. The first is that the topics to embed are crawled as a background job. You wouldn’t want it to happen on click as it involves perhaps multiple HTTP requests back to the source it’s embedding to get the right content.
We could I suppose show a huge spinner that says “please wait before replying” the first time someone clicks it, but that would be tricky to build and I’m not sure it would be a great experience for the user. Also, people could still create empty topics by clicking that link and never making a post.
I’m confident that even that would be better than swamping the forum with two million new topics.
Couldn’t we have an API call of some sort for whatever is needed to create the topic? I’d love to have Discourse call a data feed, perhaps passing the blog post URL as an argument and receiving a title as the bare minimum (in JSON). This could work beautifully and allow some amazing integrations with existing content management systems.
Also — actually, if the bare minimum is the topic title, couldn’t we include that in the list of variables inside DiscourseEmbed = {}? That makes a lot more sense to me than making one (or more) HTTP request(s) for more data.
For example:
DiscourseEmbed = { discourseUrl: 'http://discourse.example.com/',
discourseEmbedUrl: 'http://example.com/blog/entry-123.html',
discourseEmbedTitle: 'Title of the topic to be created' };
No, that would be very insecure. You can’t trust what the client passes to you to create topics. It’s important that the Discourse instance makes a GET request to a server you have whitelisted as embeddable.
I appreciate the enthusiasm but you’ll have to trust me when I say this is not easy to do.
Thank you for the suggestion, but that of course wouldn’t allow users to start a discussion on an old article, which is also not the desired behaviour.
There seems to be conflicting goals here
I don’t want topics that don’t have any replies
I want users to be able to reply to topics that don’t have any replies
I can think of two possible approaches
Compromise - determine an arbitrary cut-off point for “old” so it won’t swamp the forum with topics yet will allow members to post replies on the topics that are there
Have all topics - but - set them as Closed so they will “fall away” off of lists, requiring members to “Reply as linked topic” to start a discussion.
I see your predicament. But instead of the potentially messy solutions discussed so far, what if the topics are indeed created normally, but until they have a reply, they are unlisted, i.e. not visible in the forum stream and only accessible via a direct link. Would that be an acceptable compromise?
In other words, the basic spec request becomes something like this:
Option to set topics generated for embedded comments as unlisted by default.
Special flag that can be put on selected unlisted topics (in this case automatically) to make them unlisted if they receive a reply.
Thanks for approaching this, @erlend_sh. Out of all the options discussed thus far, I reckon this might be the best one. It is still inefficient given that a lot of topics will be created but never used —how much do we know about the impact of millions of topics in the performance of a Discourse instance?—, but insofar as user experience is concerned, I guess your approach prevents the swamping we were talking about.
I don’t want to swamp the forums with millions of “empty” topics, compromising UX;
I want users to be able to comment on all articles, regardless of when they were posted.
The fact that we need a topic object to exist before a post object can be created is a construct within the system. I’m not challenging the architecture, just the flow / user experience. We might want to start with some text (e.g. the user’s comment), then create the topic object and then create the post object.
Do you actually have millions of blog posts that would be created as topics? Because that would definitely create a lot of data and performance would be a concern. However, if you are just creating thousands, the performance impact is negligable to create them invisibly. I think @erlend_sh’s idea is a good one!