Derzeit werden die Kommentare von Discourse und WordPress synchronisiert. Es wäre großartig, eine bidirektionale Synchronisierung zwischen den Hauptinhalten zu haben, damit die Discourse-Community die Inhalte von der Discourse-Instanz aus bearbeiten (modifizieren und erheblich anreichern) kann. So könnte die Community an der Verbesserung der WP-Seite teilnehmen (wofür die Community konzipiert ist – an der Erstellung und Verbesserung von Inhalten mitzuwirken) und nicht nur Vollzeitredakteure. Die Artikel wären besser und die Informationen genauer und aktueller, ohne zusätzliches Personal einzubeziehen. Dazu muss eine dritte Einstellung eingegeben werden: Synchronisierung von Themen zwischen Instanzen.
2 „Gefällt mir“
Hallo Volanar,
Wenn Ihre Discourse-Site Ihre WordPress-Site widerspiegeln soll, benötigen Sie dann unbedingt beides?
Die Formulierung ihrer Anfrage lässt mich ihren Ablauf wie folgt sehen:
flowchart
WP <-- Post
Discourse <-- Post
Community --> Discourse
Editors --> WP
Nun, aber was ist der Vorteil von zwei Bearbeitungsschnittstellen für denselben Inhalt?
Während WordPress Markdown verarbeiten kann und dies auch tut, ist es nicht der Standard für die meisten Websites, und es sei denn, das Verhalten hat sich geändert, wird Markdown beim Speichern des Beitrags in HTML umgewandelt. Jede spezifische CSS-Formatierung geht ebenfalls verloren. Das Ergebnis ist, dass gut aussehende WordPress-Beiträge bei der Anzeige auf einer Discourse-Website einige ihrer visuellen Details verlieren.
Wenn Discourse den Inhalt eines WordPress-Beitrags überschreiben darf, würde dies viele der Präsentationsfunktionen von WordPress einschränken. Es gibt auch das Problem der Versionierung und gleichzeitiger Änderungen – vermutlich gewinnt der letzte Schreiber?
Wenn Sie möchten, dass Redakteure und Community-Mitglieder die Qualität derselben Inhalte beitragen, warum bearbeiten Sie sie nicht am selben Ort?
1 „Gefällt mir“
Da die Kontrolle darüber, wer was sieht und wer was nicht tun kann, in Discourse viel besser gesteuert werden kann, aber auf der WordPress-Seite auch andere Veröffentlichungen möglich sind.
Das könnte ein Grund sein. Ich beziehe keine Stellung dazu, ob das gut, schlecht oder neutral ist.
(Zumindest für mich) klingt es so, als ob sie nicht alle aus ihrer Community zur WP-Instanz hinzufügen wollen:
Obwohl Sie einen Punkt haben, ist die Bearbeitung auf der einen oder anderen Seite wahrscheinlich besser, als auf beiden Seiten zu bearbeiten.
Hallo @volanar, ich sehe, was du erreichen möchtest.
Dies wird in absehbarer Zeit kein Teil des WP Discourse Plugins sein, teilweise weil sich dieses Plugin auf die Synchronisierung von Wordpress-Kommentaren und nicht von Wordpress-Beiträgen konzentriert, und teilweise, weil die bidirektionale Gestaltung des WP Discourse Plugins Herausforderungen birgt, die im Rahmen dieses Plugins und seiner Funktionsweise mit Discourse schwer zu lösen sind. @Stephen hat einige dieser Herausforderungen erwähnt. Es gibt noch weitere.
Das gesagt, ist es potenziell möglich, dass du dein Ziel durch die Verwendung des Wordpress ActivityPub Plugins und des Discourse ActivityPub Plugins erreichen kannst, die kombiniert, theoretisch, das tun könnten, was du möchtest, d.h. bidirektionale Synchronisierung von Inhalten (Wordpress-Beiträge und Discourse-Beiträge).
Dabei gibt es zwei große Vorbehalte. Die bidirektionalen Funktionen des Discourse ActivityPub Plugins sind noch nicht in den Hauptzweig des Plugins integriert (der PR wird derzeit überprüft), und ich habe dieses Plugin noch nie mit dem Wordpress ActivityPub Plugin getestet. Aber was du vorschlägst, ist potenziell durch die Kombination der beiden möglich.
Tatsächlich ist das von dir beschriebene Szenario das, wofür das ActivityPub-Protokoll entwickelt wurde. Warum ist es in diesem Kontext eher möglich als im WP Discourse Kontext? Es gibt viele Gründe, auf die ich hier nicht eingehen werde, aber es genügt zu sagen, dass, wenn das dein Ziel ist, dies der Weg ist, den du in Betracht ziehen solltest.
Da WordPress WPML unterstützt und die Inhalte in mehrere Sprachen übersetzt werden. WPML eignet sich gut zur Verfolgung von geänderten Inhalten. Als Nächstes veröffentlicht WP Inhalte im Blog und in der mobilen App. Das heißt, WP kann als Headless CMS verwendet werden.
Das Hauptthema wird in WP erstellt, aber die Community kann Korrekturen und Ergänzungen zu den Inhalten vornehmen. Dies sind technische Informationen und die Schönheit des Inhalts ist nicht wichtig, daher können Sie das Markdown-Plugin in WP standardmäßig für ein einzelnes Inhaltsformat installieren. Idealerweise ist es besser, Ghost, Strapi, Squidex oder eine andere Plattform zu verwenden, aber das kostet Geld und ist nicht für jeden geeignet. Die Lösung sollte für alle universell sein.
Ich habe eine gute Option gefunden. Am Ende des Themas wird ein Link zur Bearbeitung auf der Frontend-Seite unter WP angegeben. Auf diese Weise können Benutzer die Inhalte selbst bearbeiten, und der Moderator kann Änderungen annehmen oder ablehnen.
1 „Gefällt mir“