There is no way to choose specifically which comments are shown when embedding. However there is a site setting embed post limit which limits how many will be attached to any given post. The default is 100.
Client-side caching in browser isn’t more edficient than server-side caching. For instance, when cache is used server-side, you deliver the HTML generated immediately. If caching client-side in browser, you’ll have tonread the cache and update your HTML, so it may not look instant to the user.
We got several Caching-Layers(Varnish, a self-written REDIS-Caching-Plugin for Wordpress and more) in this project. I think it’s not ontopic to explain the whole setup here.
The point is, that in some setup, it can make a real caching-advantage, if the cached data is not altered after every new comment. And that’s what i want to accomplish amongst others.
I had a look into the discourse-code at the weekend and tend to write my own implementation of what i need in the next weeks.
I just want to cache the HTML of a Page independent from the Comments, so i dont have to invalidate Cache-Objects in Varnish for every new comment incoming.
I’m confused, sorry. When you embed Discourse comments via JS, your comments are generated client-side, AFTER the page is loaded into the user’s browser. So you’re free to cache whatever HTML your page is: it will include the JS-comments embed code, but not the comments themselves.
I haven’t learned much about the native Discourse comments embedding via JS, but that’s how js-embedding works. Unless I misunderstood your goals.
native discourcse-js-embed-solution: lacks a possibility to control what posts are displayed in situations where hundreds of posts are posted in a thread. you can control the number of posts, but nothing like "display only the most-liked-posts, if there are more then 30 posts in the thread. But it is client-side in the way i need it - right!
wp-discourcse-plugin: The Discourse-Plugin for Wordpress implements the Discourcse-Posts as Comments in the Wordpress-Comment-Database. The Comments are implemented (as HTML) into the corresponding HTML-Document and are not integrated Client-Side.
Yes, thanks. So what you’re saying is that you’d like to have some caching of the comments HTML server-side in the Discourse’s WordPress plugin, so that the whole page HTML does not need to re-render with every load?
Remonter un sujet très ancien. Devrais-je en créer un nouveau ?
Je ne sais pas comment les choses se passaient en 2016, mais Google indexe désormais les commentaires intégrés de Discourse. Vous pouvez le confirmer en recherchant une partie du contenu des commentaires de https://blog.discourse.org/. Notez que Meta n’a pas activé le paramètre embed set canonical url, vous pourriez donc obtenir des résultats dupliqués lors de la recherche de commentaires de blog, ou vous devrez peut-être cliquer sur le lien « Afficher les résultats supplémentaires » sur Google pour que les commentaires de blog soient renvoyés au lieu que seul le message Meta soit renvoyé.
Ma préoccupation à ce sujet est largement liée au SEO. Des commentaires non pertinents ou négatifs peuvent nuire au SEO. Des commentaires pertinents qui ajoutent un contexte supplémentaire à un article de blog peuvent aider le SEO : Google On The SEO Value Of User Comments On Websites.
Le plugin WP Discourse gère cela en ayant une option « Afficher uniquement les J’aime des modérateurs » pour contrôler les commentaires qui sont affichés. L’ajout d’une fonctionnalité similaire aux commentaires intégrés serait simple, mais serait-il préférable d’avoir une case à cocher explicite montrée au personnel pour déterminer si les commentaires sont affichés ou non sur un article de blog ?
Cela me semble être un sujet différent. Le vôtre concerne l’optimisation du référencement. Celui-ci concerne simplement le contrôle de ce qui est affiché.
Je ne fais qu’énoncer une autre raison d’implémenter la fonctionnalité demandée dans le message initial. Je ne suis pas particulièrement intéressé par le SEO, mais dans ce cas, cela semble simple.
Ma vraie question était à quoi devrait ressembler l’interface utilisateur de la fonctionnalité. Le plugin WordPress repose sur un modérateur ayant aimé un message : discourse/lib/filter_best_posts.rb at main · discourse/discourse · GitHub. Il serait facile d’ajouter cette fonctionnalité aux commentaires intégrés, mais cela ne semble pas être la meilleure façon de contrôler les commentaires affichés.
Je ne suis pas sûr de l’intérêt qu’il y a à promouvoir l’utilisation de Discourse comme système de commentaires pour les sites Web. Peut-être que cela mérite un sujet distinct.