Von einer Wordpress + Discourse Struktur zu einer reinen Discourse Seite wechseln?

Allgemein
1
Hallo!

Bevor Sie weiterlesen, können Sie sich Moved from PluXml and phpBB to Wordpress and Discourse, my all-new experience 🎉 ansehen, aber das ist nicht zwingend erforderlich, ich werde eine Zusammenfassung geben.

Was wir gerade haben.

WP ist über WP Discourse mit Discourse verbunden. WP ist auch der DiscourseConnect-Client, und die WP-Nachrichten werden automatisch in einer dedizierten Kategorie nach Discourse veröffentlicht. Das ist alles, was das Plugin für uns tut.

  • Die WP-Website konzentriert sich hauptsächlich auf Nachrichten und statische Informationsseiten.

  • Das Discourse-Forum ist… Ein Forum. Wo sich die Community trifft, spricht und manchmal Dinge organisiert.

Die Frage

Ich habe mich gefragt: „Was ist wirklich der Zweck der Website? Der Mehrwert ist gering, und viele Funktionen der Website könnten in Discourse umgesetzt werden. Warum also zwei Plattformen bemühen?“

Beachten Sie, dass ich erst am Anfang meines Denkprozesses stehe. Aber ich fange an zu denken, dass es in unserem Fall eine gute Idee sein könnte, WordPress loszuwerden.

Was sind also die Vorteile der Website? Sie hat ein klares, nachrichtenorientiertes Layout. Sie hat kleine Funktionen, die nett erscheinen, aber vielleicht nutzlos sind. Der Facebook-iframe der Sportföderation. Ein Magazin-Button. Die jüngste Aktivität des Forums. Der Veranstaltungskalender (eine benutzerdefinierte Lösung). Und viele statische Informationsseiten über Einrad-Sachen.

Was davon kann nicht in Discourse gemacht werden? So ziemlich nichts.

Die Hauptsorge wäre, wie die Nachrichten auf unserem Forum sichtbarer gemacht werden können. Es gibt nicht jede Woche neue Informationen, aber sie sind wichtig in der französischen Einrad-Community und sollten sichtbar sein.

Ich habe dies mit zwei beteiligten Personen in diesem Forum/dieser Website besprochen. Sie denken, dass die Abschaffung von WP eine gute Idee sein könnte, wenn wir nichts Wichtiges verlieren, was uns die Website gibt.

Die technischen Dinge.

  • Der benutzerdefinierte Discourse-Header wĂĽrde bleiben, wie er ist.

  • Die Nachrichten könnten News Plugin đź“° verwenden. Nicht als Hauptseite, da der Inhalt des Forums erst nach dem Klicken auf eine „Forum“-Schaltfläche (wie Elektronauts) verfĂĽgbar wäre und wir auch die Online-Community-Aktivität hervorheben möchten. Ich habe das News-Plugin jedoch noch nicht ausprobiert.

  • Wir möchten jedoch einige Nachrichten auf der Homepage des Forums haben. Ich erinnere mich, ein Plugin oder eine Theme-Komponente gesehen zu haben, die einige Beiträge in einem Banner ĂĽber den Themen angezeigt hat, aber ich kann mich irren. Gibt es dafĂĽr eine bestehende Lösung? Die beste Nutzung fĂĽr uns wäre meiner Meinung nach, etwas wie die 3 letzten Nachrichten mit einem Thumbnail und einem Auszug oben auf der Homepage, unter dem Header, zu haben, und wir könnten dieses Banner umschalten, damit es uns nicht stört, wenn wir diese Themen bereits gelesen haben.

  • Die statischen Seiten der Website könnten entweder Themen oder veröffentlichte Seiten sein.

  • Das Wiki könnte die Wiki-Funktion von Discourse nutzen.

  • Wir brauchen keinen Newsletter (der Digest von Discourse wĂĽrde dies ersetzen), und mein Co-Admin sieht keinen wirklichen Sinn in der eingebetteten Facebook-Post-Stream der Sportföderation sowie einigen anderen Dingen.

  • Wir haben eine Veranstaltungskategorie (benutzerdefinierte Lösung), die heutzutage etwas leer ist, aber ihre NĂĽtzlichkeit hat, und wir möchten die Art von Veranstaltungskategorie mit spezifischen Funktionen beibehalten.

Ich habe in der Vergangenheit mehrere Event-/Kalender-Plugins gesehen und ausprobiert:

Einige waren etwas umständlich zu verstehen oder zu konfigurieren, und meine Bedürfnisse waren etwas anders, als ich sie ausprobiert habe, daher sollte ich es noch einmal versuchen.

Vor- und Nachteile der ausschlieĂźlichen Beibehaltung von Discourse

Vorteile

  • Keine weiteren potenziellen Probleme mit WP, seinen vielen Erweiterungen/Themes/benutzerdefiniertem ungeschicktem Code [1] und der WP/Discourse-Kompatibilität beim Veröffentlichen von Beiträgen.
  • Nur eine Plattform, die berĂĽcksichtigt und auf die man sich konzentrieren muss
  • Alle Daten werden in einer einzigen Datenbank organisiert, was die Dinge einfacher macht, wenn wir eines Tages alles umziehen mĂĽssen (selbst Discourse ist nicht ewig… Oder doch? :face_savoring_food:)

Nachteile

  • Etwas Arbeit, um einige Dinge von WP nach Discourse zu „verschieben“
  • Notwendigkeit, geeignete Lösungen fĂĽr einige Funktionen zu finden
  • Notwendigkeit, 301-Weiterleitungen einzurichten

Ihre Meinung, Gedanken, Ratschläge

Ich denke, ich habe gut erklärt, was ich anstrebe. Ich würde mich freuen, Vorschläge, Ratschläge usw. zu diesem möglichen Übergang von WP+D zu D zu hören.

  1. Sie wollen es nicht ansehen; versuchen Sie nicht einmal, darüber nachzudenken, ich schäme mich schon ↩︎

6 „Gefällt mir“
2

Das würde wahrscheinlich davon abhängen, wie viel Traffic jede Website generiert und wie hoch Ihr Budget ist.

Discourse kann absolut all das oben Genannte leisten, aber wenn Sie eine Menge Inhalte fĂĽr anonyme Benutzer auf der WordPress-Website bereitstellen, sind Ihre Kosten pro Seitenaufruf deutlich niedriger.

Ein richtig konfigurierter $5-VPS kann Millionen von schreibgeschützten Seitenaufrufen mühelos bedienen, hier glänzt WordPress. Der gleiche Traffic würde erheblich mehr Ressourcen benötigen, wenn er über Discourse bereitgestellt würde. WordPress ist immer noch ein unglaublich effektives Werkzeug, wenn Ihnen so etwas wichtig ist. Richtig konfiguriert ist es auch ziemlich gut darin, die Inhalte, die Sie für Suchmaschinen bereitstellen, zu kuratieren.

Ich habe einen Kunden, der derzeit etwa 100 US-Dollar pro Monat für die beiden an DO zahlt. Als wir untersuchten, ob wir die Dinge komplett auf Discourse umstellen sollten, wären die laufenden Kosten um eine Größenordnung höher gewesen, man kann sicher sagen, dass diese Arbeit nicht zustande kam.

3 „Gefällt mir“
3

Große Bedenken. Ich hätte Informationen dazu erwähnen sollen.

Dies ist eine sehr Nischen-Website. Der Traffic ist von Natur aus gering. Sie kostet nichts an Bandbreite, Speicherplatz oder Ă„hnlichem. Beide Websites laufen reibungslos auf meinem VPS neben anderen Web-Sachen und ich mache das alles als Freiwilligenarbeit. :slight_smile:

Der SEO-Aspekt wäre interessant zu studieren. Daran habe ich nicht gedacht. :thinking:

2 „Gefällt mir“
4

verwendet derzeit ein Strapi Headless CMS-Backend + Next.js-Frontend, gehostet auf Vercel.

Es hat auch ein Discourse-Forum angehängt:
https://forum.monerochan.news/
Ich ĂĽberlege auch, das Strapi-Backend komplett aufzugeben und nur Discourse als Headless CMS zu verwenden.

Dieses Problem könnte also gelöst werden, indem die “Landing Page” / die meistbesuchten Seiten auf etwas wie Vercel Headless gehostet werden.
Selbst in seiner jetzigen Form könnte Discourse fast als Headless CMS funktionieren: Wir können einfach .json an die Topic-URL anhängen und die Markdown / Rohdaten des Beitrags erhalten.

Das einzige Problem wären dauerhafte Links, kuratierte Topic-Listen und ein Veröffentlichungs- + Berechtigungssystem für Autoren und Redakteure. Ein Teil davon könnte mit Gruppen und Kategorien erledigt werden, aber es wäre schön, wenn es nur eine Artikel- / Vorschauartikel-Kategorie gäbe.

Vielleicht sollten wir dafĂĽr ein Plugin bauen :thinking:

@Canapin danke fĂĽr das Thema! Tolle LektĂĽre :grinning: :+1:

4 „Gefällt mir“
5

Das setzt voraus, dass nur die Titelseite statische Inhalte liefert. In meinem obigen Beispiel hat die Website über 10.000 Beiträge und Seiten.

1 „Gefällt mir“
6 
export const getStaticProps: GetStaticProps = async ({params}) => {
  // Run API calls in parallel
  const id = params?.id

  if (!id) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
        // statusCode: 301
      },
    }
  }
  const qs = require('qs');
  const query = qs.stringify({
    populate: '*',
  }, {
    encodeValuesOnly: true, // prettify URL
  });
  const article = await fetchAPI("/api/articles/" + params.id + "?" + query)
  if (!article.data) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
        // statusCode: 301
      },
    }
  }

  return {
    props: { article },
    revalidate: 1,
  }
}

Ich verwende diesen Code im Next.js-Frontend, um die Artikel abzurufen. So wird der Artikel fĂĽr 1 Sekunde zwischengespeichert und dann neu validiert. Die Discourse-Instanz wĂĽrde also nur eine Anfrage pro Sekunde erhalten, wenn wir diese Methode verwenden.

Es ist vorstellbar, dies nicht nur fĂĽr eine spezielle Kategorie zu tun, die von einer speziellen Gruppe von Autoren und Redakteuren verwaltet wird.
Es könnte für alle Inhalte erfolgen. Das Strapi-Backend von monerochan.news stellt auch Markdown bereit (genau wie Discourse). Wir könnten also denselben Code verwenden, um die Post-Daten abzurufen (hängen Sie einfach .json an die normale Topic-URL an) und anzuzeigen.
Offensichtlich würden die interaktiven Funktionen von Discourse in diesem Fall fehlen. Aber wir könnten einfach einen Button dort platzieren, der zum Beispiel sagt: kommentieren! und dies wird zur Discourse-Seite weiterleiten. Next.js-Seiten laden auch super schnell und sind SEO-freundlich.

Ich denke also, es gibt zwei Situationen: 1. Eine Nachrichtenseite mit einer speziellen Kategorie, die von Autoren und Redakteuren kuratiert wird. 2. Ein normales Discourse-Forum mit benutzergenerierten Inhalten.
Es könnte auch eine Mischung aus beiden Fällen geben.

In beiden Fällen könnte der Aufbau eines Headless-Frontends viele Vorteile haben.

1 „Gefällt mir“
7

Wenn Sie Probleme bei der Durchführung eines der oben genannten Punkte mit dem News Plugin, dem Landing Pages Plugin oder dem Events Plugin haben, können Sie mir dies jederzeit mitteilen. Ich helfe Ihnen gerne weiter.

Bezüglich des Events Plugins sollten Sie sich melden, da wir derzeit nach weiteren Anwendungsfällen für unsere bald erscheinende Version 2 suchen. Füllen Sie diesen Assistenten aus:

2 „Gefällt mir“
8

Das ist eine interessante Idee, wenn ich sie richtig verstehe. Im Grunde würdest du dein Forum so belassen, wie es ist, und zusätzlich eine selbstgemachte Website haben, deren Inhalt über die API von Discourse aus den Daten des Forums stammt. Stimmt das?

@Stephen, WordPress hat in der Tat berechtigte Punkte.

WP lädt sehr schnell, besonders wenn man ein Caching-System verwendet, während Discourse die gesamte Anwendung laden muss, was immer eine Weile dauert, wenn man es öffnet.

Meine Seite https://monocycle.info lädt schnell und die Navigation von Seite zu Seite ist fast augenblicklich.

Die Idee, WordPress zu entfernen, hat mehrere Gründe, die ich aufgelistet habe, aber ich habe vergessen hinzuzufügen, dass ich das Forum sichtbarer und offensichtlicher machen möchte. Ich möchte, dass die Leute sehen, dass es eine aktive Community gibt, sobald sie auf der Website landen.

Die Registrierung und das Posten auf Discourse sind sowohl auf dem Desktop als auch auf dem Mobilgerät eine angenehme und problemlose Erfahrung.

Ich könnte WP nur für die Homepage (oder nicht viel mehr) behalten und die meisten Inhalte in die Themen/veröffentlichten Seiten von Discourse verschieben.

Schön! Ich muss mir dein Plugin noch einmal genauer ansehen, bevor ich deinen Assistenten ausfülle, damit ich genau weiß, welche Funktionen es bietet und wie es insgesamt funktioniert. :+1:

1 „Gefällt mir“
9

Was ist mit der Einbringung von mehr Community-Inhalten auf die WordPress-Seite? Erhöhen Sie die Sichtbarkeit auf diese Weise.

10

Haben Sie eine konkretere Idee? Wenn wir auf der Homepage landen, gibt es einen Link „Diskussionen“ und eine Liste der zuletzt erstellten Themen.

image
image1173Ă—1128 379 KB

11

Ja! Das ist genau das, was ich meine! Es muss auch nicht viel auf der Discourse-Seite getan werden! Wenn du .json an jeden Link eines Themas anhängst, hast du bereits die API!
Schau dir zum Beispiel dieses Thema an, ĂĽber das wir gerade sprechen:
https://meta.discourse.org/t/go-from-a-wordpress-discourse-structure-to-a-discourse-site-only/247273/8.json?include_raw=true

Beachte das .json und include_raw=true am Ende. So kannst du sogar den Markdown des Beitrags zusätzlich zum “gekochten” HTML erhalten.

Strapi verwendet ebenfalls einen Markdown-Editor, sodass ich buchstäblich denselben Code wie zuvor verwenden kann.

Screenshot 2022-12-12 at 13-05-29 https __meta.discourse.org
Screenshot 2022-12-12 at 13-05-29 https __meta.discourse.org1315Ă—933 138 KB

2 „Gefällt mir“
12

Das hat mich buchstäblich auf meinem Stuhl aufspringen lassen. Soweit ich das durch die Verwendung von: .json und include_raw=true mit einer Art Automatisierung (n8n) verstanden habe, könnten wir theoretisch alle Discourse-Inhalte in Hugo umleiten, indem wir die Meta-Tags und das Markdown direkt in ein Git-Repository pushen??

1 „Gefällt mir“