Ich hole gerade diesen Thread nach – aber ich denke definitiv, dass die Antwort ja ist
Aufgrund des Erfolgs unserer Enterprise-Community (sowohl bei unseren Benutzern als auch innerhalb unseres Unternehmens) hat sich unser Dokumentationsteam gemeldet und gefragt, ob wir ein Kommentarsystem für die gesamte Dokumentation.sailpoint.com erstellen könnten. Soweit wir sehen können, werden wir fast alles tun können, was wir uns zum Mindestmaß vorgenommen haben:
Kommentare einbetten (Einbettungsfunktion)
Wir möchten auch, dass verschiedene Benutzer als diese posten und verschiedene Tag-Sätze anwenden, basierend auf der Einbettung. Diese Funktion kommt sehr bald:
Von dort aus war alles andere, was das Docs-Team (und mein Team) wollte, innerhalb von Discourse, damit wir diese Erfahrung effektiv von unserem restlichen „Alltags“-Forum-Gebrauch trennen können, während wir den Leuten trotzdem die Möglichkeit geben, zu kommentieren, Benachrichtigungen über Antworten zu erhalten usw.
Möglichkeit festzulegen, welche Benutzer kommentieren dürfen und welche nicht
Kategorie-Moderatoren den zugehörigen Themen zuweisen
Diese Fülle von Kategorien für diese Dokumente von unserer Hauptseite unterdrücken
Kategorie nicht durchsuchbar
Themenkomponente zum Ausblenden aus der Hauptkategorieliste verwendet
Aus dem Digest unterdrückt
Zu den standardmäßig stummgeschalteten Kategorien hinzugefügt
Kommentare nach n Tagen entfernt
Ein paar andere Einstellungen…
Ich würde mir definitiv wünschen, dass viele der hier erwähnten Funktionen umgesetzt werden!
[quote=„Jordan Violet, Beitrag:41, Thema:274455, Benutzername:jordan-violet“]Unser Dokumentationsteam hat sich gemeldet und gefragt, ob wir ein Kommentarsystem für die gesamte Website documentation.sailpoint.com erstellen könnten.
[/quote]
Ist das Ziel, Benutzern zu erlauben, Kommentare auf https://documentation.sailpoint.com/ zu erstellen, oder ist es in Ordnung, die Kommentare nur auf der Dokumentationsseite einzubetten und Benutzer Ihre Discourse-Website besuchen zu lassen, um Artikel zu kommentieren?
Das erstgenannte ist ein Feature, das ich begrüßen und gerne haben würde (lies: bitte baut es, CDCK), aber das letztere erfüllt zumindest unsere Mindestanforderungen.
Ich werde in naher Zukunft tatsächlich eine Idee untersuchen, Discourse unsere Markdown-Dokumentation (nein, nicht in Themen, sondern in traditionellen Markdown-Stil-Dokumenten) bereitstellen zu lassen, in welchem Fall Kommentare und die Anmeldung zum Erstellen dieser allumfassend wären. Aber diese Untersuchung hat noch nicht begonnen.
Mit dem Ansatz, an dem ich jetzt arbeite, wäre es technisch möglich, Discourse-Kommentare direkt auf MkDocs-Seiten zu generieren, aber es würde die Verwendung eines serverseitigen Frameworks (Remix, Rails usw.) zum Ausliefern der MkDocs-Seiten erfordern. Dies würde es ermöglichen, Benutzer auf der Dokumentationsseite zu authentifizieren (mit DiscourseConnect) und auch eine In-Memory-Datenbank für das Caching zuvor zurückgegebener Kommentare zu verwenden.
(Bearbeitung: Nur um klarzustellen, ich spreche davon, Discourse als Identitätsanbieter für die Website zu verwenden, nicht die Website als Identitätsanbieter für Discourse. Letzterer Ansatz funktioniert, ist aber für die meisten Anwendungsfälle zu unflexibel.)
Das wäre jedoch eine große Änderung, die Ihr Team vornehmen müsste.
Ich bin sicher, dass es aus Ihrer Sicht einfacher wäre, wenn dies vollständig innerhalb von Discourse erreicht würde, aber es ist auch möglich, Discourse als Content-Management-System zu verwenden. In diesem Fall würden die Markdown-Dokumentationen als reguläre Discourse-Themen generiert. Discourse-Webhooks würden verwendet, um die Generierung einer Dokumentationsseite auf einer externen Website auszulösen. Dies ist tatsächlich die Grundlage der Discourse-Kommentar-Demo-Site, die ich einrichte.
Da dieses Thema heute verlinkt wurde, dachte ich, ich sollte es mit den Schlussfolgerungen aktualisieren, zu denen ich nach einiger Arbeit an der Idee gekommen bin.
Ich denke immer noch, dass Discourse aus den Gründen, die ich im Eröffnungsposting dargelegt habe, eine gute Kommentarplattform wäre.
Was die Umsetzung betrifft, so denke ich, dass die Arbeit auf der Discourse-Seite erledigt werden muss – idealerweise durch die Verbesserung des Discourse-Kommentar-Embed-Skripts. Dies könnte schrittweise erfolgen.
Es ist technisch möglich, Discourse als Server für eine Kommentarplattform zu nutzen, indem die gesamte Arbeit auf einem Discourse-Client erledigt wird (z. B. das WP Discourse-Plugin), aber aufgrund der Notwendigkeit, den Zustand zwischen Client und Discourse zu verwalten und Ratenbegrenzungsprobleme zu umgehen, wird dies zu einem komplexen Problem. Es ist definitiv komplexer, als ich bereit bin, die Verantwortung für die Wartung zu übernehmen.
Einige Beiträge in diesem Thema deuteten darauf hin, dass die Leute daran interessiert wären, einfach nur Discourse-Kommentare auf einer Blog-Website zu erstellen. Aus meiner Sicht ist das keine gute Lösung, aber sie kann jetzt mit der Discourse-API erreicht werden. Kompliziert wird es, wenn man versucht, ein vollständiges Kommentarsystem zu erstellen, bei dem Benutzer auf einer Website auf ähnliche Weise mit Discourse-Kommentaren interagieren können, wie sie es von Kommentaren auf einer typischen Mainstream-Nachrichtenseite erwarten würden.
Angesichts meiner Erfahrung mit ActivityPub und WP Discourse glaube ich, dass zweiseitiges Kommentieren über eingebettetes Javascript erreichbar ist. Das Einbettungsskript würde Folgendes enthalten:
Nicht authentifizierte „Lese“-Funktion, die ähnlich wie das aktuelle JS-Embed funktioniert (mit einigen Optimierungen).
Ein Remote-Client (d. h. der Browser des Benutzers) registriert einen API-Schlüssel-Client für Benutzer, der spezifisch für die Sitzung des Benutzers ist und relevante Details im lokalen Speicher des Browsers speichert.
Dem Benutzer wird „Zum Kommentieren anmelden“ angezeigt.
Der Benutzer authentifiziert sich (bei Discourse), um einen API-Schlüssel für die Benutzersitzung abzurufen, der im lokalen Speicher des Browsers gespeichert wird.
Jede Aktivität (Kommentar, Like usw.) wird direkt an einen dedizierten Endpunkt mit entsprechenden Schutzmaßnahmen, Handhabung und Aufgabenverwaltung gesendet.
Mit dem richtigen Budget denke ich, dass ich Version 1 produktionsreif machen und in 6-8 Monaten in discourse/discourse integrieren könnte. Nach der ersten Veröffentlichung könnte ich Folgendes tun:
Explizite Unterstützung für Wordpress, Ghost und andere ausgewählte Plattformen hinzufügen.
Versuchen Sie, es auf eine Weise zu implementieren, die für nicht-technische Benutzer sinnvoll ist. Vorhandene Plattformen wie Disqus und Facebook-Kommentare bieten wahrscheinlich gute Beispiele.
Einige weitere Authentifizierungsoptionen:
Die Client-Site wird zu einem DiscourseConnect-Client. Dies ist einfach zu implementieren, erfordert jedoch zusätzlichen serverseitigen Code auf der Client-Site.
Benutzer melden sich direkt über das iFrame bei Discourse an
Meine Zurückhaltung, dies rein clientseitig zu entwickeln, entstand aus der Betrachtung der Probleme, die das System bei jeder Art von Skalierung mit sich bringt. Im Wesentlichen musste ich API-Anfragen in eine Warteschlange stellen und Antworten aus Warteschlangen verarbeiten. Es fühlte sich nicht robust genug an, um beispielsweise 1000 gleichzeitige Benutzer zu bewältigen. Ich hätte ähnliche Bedenken, aber aus anderen Gründen mit dem JavaScript-Embed-Ansatz. Ich vermute, es wäre jedoch viel einfacher zu handhaben, als alles auf dem Client zu synchronisieren.
Ich habe gestern noch einmal eingehender darüber nachgedacht, da das Thema wieder aufkam (deshalb habe ich hier gepostet). Ich denke, eine reine Client-Lösung (d. h. ein JavaScript-Embed) ist die einzige, die hier wirklich Sinn ergibt. Andernfalls sprechen wir im Wesentlichen über eine Reihe plattformspezifischer Implementierungen, jede mit ihren eigenen Problemen.
Sie haben Recht, dass Konkurrenz und Last Probleme sind. Es gibt erhebliche Last- und Konkurrenzprobleme mit ActivityPub, da ein einzelner ActivityPub-Post Sie für viele eingehende und ausgehende Anfragen vom und zum Fediverse öffnen kann. In diesem Zusammenhang ist dies möglicherweise sogar etwas einfacher, da die Remote-Clients kontrolliert werden. Darüber hinaus sind Konkurrenz und Last in diesem Fall wirklich nur auf der Serverseite (d. h. auf der Discourse-Seite) ein Problem, und obwohl es sich um Probleme handelt, denke ich, dass sie durch Hintergrundjobs, Caching und Mutexes lösbar sein sollten. Aber ja, wichtige Probleme, die es zu berücksichtigen gilt.
Ehrlich gesagt, meine größte Sorge hier ist das Timing.
Composer v2 steht kurz vor der Veröffentlichung. Es wäre verrückt, dieses Abenteuer anzugehen und nicht auf unseren neuen Composer zu setzen, aber es gibt einen Berg von Arbeit, den wir im Voraus erledigen müssen, um seine Verwendung in einer schlanken App zu ermöglichen.
Ich denke, das Richtige wäre, diesen Bereich für etwa 2-3 Monate im Auge zu behalten und die Frage dann erneut zu prüfen.
Ich denke, das kann parallel erfolgen. Sie müssen 2 Änderungen am Diskurs vornehmen.
Die Schaltfläche „Antworten“ sollte für nicht registrierte Benutzer sichtbar sein.
Und wenn nicht registrierte Benutzer auf diese Schaltfläche klicken, sollte Folgendes angezeigt werden:
Als Nächstes müssen Sie herausfinden, wie Sie die Kommentarfunktion verwenden. Dies sind wahrscheinlich kleine Codeänderungen und keine große Arbeit.
Ich frage mich, ob es immer noch Interesse gibt, diese Funktion zu entwickeln, jetzt wo Composer v2 verfügbar ist. Ich stimme dafür, dass es immer noch etwas ist, das ich gerne sehen und verwenden würde.
