[Discussion] Apps - the best approach to commenting systems

[ErisDS]

One of the most popular modifications people make to their Ghost blog, is to add comments. This is a relatively straightforward amend to make to a theme at present, but when Apps become available we expect it to become a matter of a few clicks.

Here is a list of some of the commenting systems that can be integrated with Ghost at present (if you know of others please leave a comment and I will add it to the list):

• Disqus
• LiveFyre
• Moot
• Facebook
• Google+ Comments
• Annote
• NodeBB
• Isso
• Intense Debate
• Juvia

These solutions all have slightly different approaches to how they can be integrated, but it almost always requires embedding some extra code into the blog page. Therefore we need to make sure there is a simple way to integrate between the app and any theme. That is, there needs to be an easy way for themes to support the addition of comments with minimal impact or effort on everyone's part.

At present we have {{ghost_foot}} which enables us to embed code in every page. This will likely be augmented by code injection #1993, however this isn't a suitable solution for comments for two related reasons: firstly, because most comment systems require the code to be injected at the point where the comments should appear, and secondly because comments are usually only wanted on blog posts, i.e. only in post.hbs not anywhere else.

Therefore, I propose a new helper:

{{comments}}

This can be placed by theme developers wherever comments should appear, and can be leveraged by comment app authors to output their code via an api method something like:

var code = '<script....</script>';
this.ghost.registerComments(code);

The upside to this suggestion is that {{comments}} can be added to themes long before it does anything. In fact, we can get theme developers to do something like this for added flexibility:

{{#if comments}}
  {{comments}}
{{else}}
... current comment solution goes here...
{{/if}}

The downside to this is that it requires theme authors (or users) to do some work in order to get comments working. Not all themes are kept up to date. So it's worth considering whether we can add a fall back for where comments get inserted if {{comments}} doesn't exist.

This begs a second question about how to tell if a theme supports certain features... can we detect them? Or should we get theme authors to declare their feature support in package.json somewhere? This is probably a different discussion though.

Another downside to this helper is that it is very, very specific. This is good in some regards, comments are a very common piece of functionality so it's probably not a superfluous helper... but comment systems have one other common feature that isn't supported by this helper, which is displaying a comment count. So do we also add {{comment_count}}? Or do we get comment apps to implement that helper if they support it? Adding 2 helpers seems a lot, but getting individual apps to implement a helper means they probably won't do it consistently.

So, I'm throwing this open to discussion. Is there a better way?

[javorszky]

The apps can implement this as an interface (hah!), and then depending which service they're using, they can either set the {{comment_count}} to false, or if the number is available, the number.

{{comments}} helper can totally be used, and :+1: for that. On the other hand, users will need to be super extra careful about using apps that are safe, because essentially we'll need to run unescaped javascript on the page, which the app attached to the helper. So while I may be a good citizen when it comes to coding, Mr Malware Guy might add some... extra things there that shouldn't necessarily be there.

[javorszky]

Theme support isn't unheard of, so it could totally live in the package.json file. The problem is when a theme lies about it, although at that moment I assume it's not our problem.

Feature detection could be done by using regex and scanning all the theme files. It might be slow however, but on first run a generated file for the theme can be created to avoid further scans.

For a fallback option I would still use the ghost_foot approach.

Back to the helper for a bit. Depending on the service used, embedding comments multiple times on the same page could break them. Is it up to the app developer (?) or theme developer (?) to make sure this doesn't happen? Would Ghost know if a comment has been already embedded, and just blocks subsequent embeds depending on service used?

[ErisDS]

Theme support isn't unheard of, so it could totally live in the package.json file. The problem is when a theme lies about it, although at that moment I assume it's not our problem.

Exactly - not sure if it's even a worthwhile approach given the potential for false positives and negatives.

Feature detection could be done by using regex and scanning all the theme files. It might be slow however, but on first run a generated file for the theme can be created to avoid further scans.

I'm not sure if it's worth the overhead, but it might be? It would be nice to be able to warn users of problems with the theme they have added: this theme doesn't use the asset helper, this theme doesn't support comments etc. However, this might become an unmanageable list of things.

For a fallback option I would still use the ghost_foot approach.

I was thinking about detecting the post class output by {{post_class}} and inserting after that?

Back to the helper for a bit. Depending on the service used, embedding comments multiple times on the same page could break them. Is it up to the app developer (?) or theme developer (?) to make sure this doesn't happen? Would Ghost know if a comment has been already embedded, and just blocks subsequent embeds depending on service used?

There are two problems I foresee here - the first being having multiple {{omments}} blocks, and the second being having multiple apps activated which use the registerComments function. The first is pretty easy to resolve with a flag to only allow the comments helper to output once, and to log a warning on subsequent occasions. The second would require warnings to the user that they have 2 active comments apps I think?

[b992]

Not completely new, it's an annotation styled addition to the LiveFyre system:

http://blog.livefyre.com/say-hello-to-sidenotes/

[halfdan]

@b992 That is not what this issue is about - it’s about how to best integrate commenting systems with Apps. How they appear in Ghost is a different discussion.

[mikerudolph]

The first is pretty easy to resolve with a flag to only allow the comments helper to output once, and to log a warning on subsequent occasions.

:+1:

The second would require warnings to the user that they have 2 active comments apps I think?

This probably fits into a bigger discussion, but it would be ideal to have some form of a conflict resolution system not just for comments but other functionality as well advising a user when something like this happens.

[segmentationfaulter]

I have not tested it, but the developer says it is built for inline comments in ghost http://ouija.io/

[HLFH]

@segmentationfaulter Ouija and GoInstant have been discontinued since August 2014. It's now released as open source. We need to solve these issues to get it working on Ghost: https://github.com/ouija-io/ouija/issues/74 and https://github.com/ouija-io/ouija/issues/76

[P3lUZa]

Add Isso and Juvia!!!!

[ErisDS]

Temporarily closing all of the app specific issues (tagged with later). Will review & reopen those that are still relevant when we kick off that project, which should be shortly after Zelda lands.

[23W]

@ErisDS Is it realized in the version 0.11 LTS or will be in the version 1.0 ?