Do you think is possible to add the opportunity to reply comments directly on the page using api’s?
I need to trash my comment system and I don’t want Disqus 
4 Likes
That’s not planned at the moment, as stated many times in this topic.
I know that the team has not planned this feature, but I want to know I using the api is possible to post from another page… I want to create an ember editor component on the post page.
Yes! You can use the API to do anything!
However, it isn´t dead easy. You can’t expose API in the JS world, so you´ll need some backend service do to the middle work between your page with comments and discourse.
1 Like
This is going to be extra challenging because the embedded code doesn’t use Ember 
It’s designed to be super fast and lightweight because it’s embedded in other people’s sites, so it’s just vanilla HTML/CSS and a small amount of Javascript.
I know, I just want to create an external editor not related to the embed code. Just a simple editor to add a reply…
2 Likes
I’m also looking to do the same. Which API resources are available for this?
There are unfortunately no API hooks for this, since it uses a different non-Javascript code path that’s never been extended before. I would gladly accept a PR that adds some though, if you can figure out what you need to have added.
1 Like
With the api you can create a new reply, so my idea is to create an editor on the post page to add a new reply to the related forum discussion. This is not related to the discourse embed js, I will keep my editor totally separated: is just an editor that on submit create a reply using the api.
I think it’s not difficult, but I will lose a lot of Discourse features like to opportunity to like post.
Hi,
do you have some plan on adding a posting interface in the embedded JS? The process to go to the forum is really timely and having the ability to directly comment in the iframe would be great (with the SSO, the user would have a smoothless experience)
Thanks a lot
Thanks for the reply 
@codinghorror adding comments on our site pages would actually add topics and activity for our community. Basically, the site pages are jumping off points that would drive conversation.
We have tried plugging in comment systems, but they pale in comparison to what Discourse can provide. We see the comment pages as just an extension to current conversations in the community and as an on boarding path for new members.
We love Discourse and it has 90% of what we need to keep all the site ‘conversations’ happening in one system, which is huge for us.
I tried the way comments work on your blog. The the approach of flipping someone into a Discourse topics page is a bit of a shock, but we’re trying that for a start.
The thing is that the mental model for comments is pretty strongly ‘in place’ on the page where you see the comment. So, that’s where our need for this really lies. And, again really as a place to onboard people to the community.
1 Like
I guess I haven’t had enough coffee yet, but going to the site you linked to I did not find an example of comments (unless that is what reviews are) and did not find a way to experience the “flipping into a Discourse topics page” you described. What am I missing?
1 Like
Sorry, I was just giving an example of where we’d put the ‘comments’. We have a whole discussion board that’s run by Discourse and are trying to stay away from having a comment solution that’s separate.
So, the book list page mentioned above would become a ‘topic’ in Discourse and we’ll put the comments under that.
You can see the current comments approach on codinghorror’s blog. Password Rules Are Bullshit
There’s a link after the post that says “continue discussion”. That’s where you’ll be dropped into a Discourse topic for the blog post.
1 Like
I’ve started to research Discourse as a general solution and started with embed capabilities. To be frank the whole situation seems to be a bit of a mess.
This thread has many requests based on what makes sense for users, and many replies of implausibility based on limitations of the architecture. This doesn’t sound good – the latter should be informed by the former, especially for what appear to be common or not an edge case scenarios.
Would it be possible to only create the topic when someone publishes a comment?
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.”
How could this require a huge change to a well designed architecture? Of course, no design can do everything well nor should it try. However embedding scenarios have existed longer than Discourse has. Even if embedding was not an original goal I’m not sure why the door wouldn’t be left open. Sometimes things change.
Can’t we use an API to help the situation?
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…
you’ll have to trust me when I say this is not easy to do.
Are you sure the API would have to be very insecure? You’re the expert on your code, but I don’t see a problem in principle here. I guess a big difference would be if you’re talking about existing code limitations vs. what best practices would be in general.
[people wanting to get rid of the “Continue Discussion” limitation]
No, we won’t be doing that – the goal is to drive people to the community site, not be a comment engine for a random webpage.
You know what, I would post that at the top of this thread in a large font because it’s a strategic bet you’re making that everyone should be able to get on board with or not right up font.
I don’t mean to sound disagreeable in this thread and I usually find it quite pleasant to talk with other developers. I must admit feeling a little defensive after reading a few different threads where Robin said something to the effect of “well if you don’t like it maybe you’d be better off with another product”.
Is that technically a true statement? Sure. Does it sound good? I think often it gives the wrong impression. I mean the content adds no value right? If a feature is not going to be implemented, I’d suggest it’s good enough just to say something like “sorry, that’s not on our roadmap at the moment but we appreciate the feedback.”.
3 Likes
Apparently you haven’t met me. There is nothing I love more than slamming the door closed on directions we don’t want to go in. Then nailing them shut and painting over them.
Building a great product is about saying yes to a few things and no to everything else. If you don’t understand that, with respect, show me what you have built.
7 Likes
I’m just going by what I’ve read in this thread, where it seems that multiple times responses talked about something being really hard for technical reasons relating to how Discourse works. Since some of these requests seem like a good thing, I’m inferring the limiting factor is tech, rather than simply deciding priorities and optimal workflow.
If I didn’t infer that correctly that’s fantastic, I would be glad to learn that’s not the case.
Regarding your blog post, I don’t see how I have disagreed with anything there. In fact I explicitly said no one should try do to everything well or be expected to do so. Shouldn’t it be possible to agree with the philosophy, but disagree with the things that a product has chosen to say yes to?
Regarding my resume, I’m not sure how that changes whether my suggestions are valid. If you’re asking if I can empathize with what it takes to create complex software that is good enough for people to like and/or pay money for, then yes I have done that as a startup and at other companies. I know it’s not easy like climbing Everest wearing shorts is not easy. I do empathize.
I also know it requires constructive criticism, which was my intention believe it or not. To be constructive I think requires going beyond complaining, to try and suggest things that (I believe anyway) may help improve a product or company. I will try to be more clear and concise on these suggestions:
-
I believe embedding should be one of the few Yes items, and receive your best shot at a great UX that is competitive with Disqus. I think you could actually provide a superior experience by leveraging what’s been accomplished with the Discourse foundation.
-
The first item would require it to be compatible with your direction, strategy, business model. If it’s not that’s fine, but with hundreds of posts discussing embedding, I would suggest it makes sense to clarify that it’s considered more of a minor capability, rather than a core scenario at this point. If you’ve already done this my apologies, but googling did not tell me that.
-
To an outsider, limitations around how and when topics can be named, and how APIs cannot be called securely, don’t make sense. I don’t doubt there are real and challenging problems, but I would find it normal for people to question that if it were the only info provided.
-
I would suggest changing how you tell people “no”, such that it doesn’t involve suggesting they go find another product. If you did a survey asking people which way left them feeling more positive about Discourse, I think my example would win handily.
Am I right in my suggestions? Who knows, I’m some guy on the Internet who doesn’t create community software for a living. But for me personally, I would want to hear feedback like this. Once in a while a post might influence me, most probably not, some may just plant a seed of thought for the future.
5 Likes
On page commenting is a radically different product, and not at all comparable to the community we’re trying to build. There is plenty of existing discussion on this if you wish to read through it.
1 Like
I don’t because I don’t see Disqus as competing with Discourse.
Discourse is clearly focused on one community at a time. Disqus is clearly focussed on comments for published documents such as blogs in more than one community. The idea of community is compromised in ways that the Discourse team will never allow.
You are right that there is clearly an opportunity to leverage Discourse - and thanks for expressing yourself so clearly and politely. And it would be easy to take that path But the opportunity cost is way too high when core Discourse has so much more yet to be realised on the road map.
2 Likes