Es geht also nicht um die Instanzbereitstellung mit DB usw.
Gibt es ein Muster für die Wartung einer Instanz mit einem deklarativen Format? Kategorien, Tags, Richtlinien usw. Ich dachte, es wäre gut, wenn unsere technischen Benutzer Änderungen über PRs anstelle von Themen-Threads und manueller Erfüllung empfehlen könnten, aber ich habe kein Plugin oder ein anderes „as Code“-Tool gefunden, das sich auf die organisatorische Konfiguration von Discourse konzentriert.
Ich denke, die Erwartung ist, dass Websites die vorab festgelegte Kategorie Site feedback dafür verwenden. Ihre Beschreibung lautet: „Diskussion über diese Website, ihre Organisation, wie sie funktioniert und wie wir sie verbessern können.“
Das ist eine interessante Idee. Welchen Vorteil hätte das gegenüber der bloßen Aufforderung an Benutzer, Änderungen in regulären Themen vorzuschlagen? Besteht das Ziel darin, eine Möglichkeit zu haben, die im Laufe der Zeit vorgenommenen Änderungen an der Konfiguration der Website zu verfolgen?
Website-Einstellungen, Kategorien, Tags, Richtlinien usw. können mit der Discourse-API konfiguriert werden. Es wäre möglich, ein Skript zu haben, das die Konfiguration Ihrer Website über die API in einem Git-Repository verwaltet. Das Skript könnte ausgeführt werden, wenn ein PR im Repository akzeptiert wird. Aus meiner Sicht wäre dies jedoch schwieriger, als Änderungen an der Website-Konfiguration manuell über die Benutzeroberfläche vorzunehmen.
10-4 zur Kategorie. Vorerst habe ich ein wenig über ein bestehendes Muster gesammelt. Für mich geht es darum, dieses GitOps-Style-Community-Engagement zu bekommen, also habe ich mich für dieses entschieden, aber ich kann es an das andere weitergeben, wenn es hilft.
Und ja, wir verwenden für viele Dinge ein wenig Konfiguration als Code, sodass Sie die saubere Revisionskontrolle, das deterministische Rollback, die klare Änderungsprüfung usw. erhalten. GUI-basierte Änderungen sind nicht schlecht (und das tun wir heute über Community-Feedback-Schleifen), aber es ist ein manueller Vorgang und der Entscheidungskontext kann im Laufe der Zeit verloren gehen. Und die organisatorischen Konstrukte existieren in der Mitte zwischen der Infrastruktur und dem eigentlichen Dialog, sodass es sich nicht um eine Bereitstellungs- oder Rehydrierungsangelegenheit handelt.
Und ja, PR-basierte Trigger (oder sogar ein Issue) können einen Runbook auslösen, der die vorgeschlagene Änderung ermittelt und den Vorgang durchführt. Die Diff-Analyse und das Linting können schwierig sein, weshalb ich herumgestochert habe, um zu sehen, ob es jemand bereits versucht hatte. Die Anfrage liegt definitiv im Bereich „nice to have“ und wird möglicherweise nur bei einer bestimmten Zielgruppe Anklang finden.
Ich (und ich bin mir ziemlich sicher, dass unsere Programmiersprachen-Community) würde diese Fähigkeit absolut lieben. Insbesondere würde ich gerne Themes, Komponenten und Website-Texte in einem GitHub-Repository verwalten können, wo Leute einfach Pull-Requests einreichen können. Allgemeine Website-Einstellungen wären auch schön, aber es sind diese drei Dinge, die am mühsamsten in einer Weboberfläche zu pflegen sind.
Wenn das heute nicht möglich ist — und ich glaube nicht, dass es das ist, zumindest nicht für eine bezahlte/gehostete Instanz — könnte dies als Funktionsanfrage neu kategorisiert werden?
Unmittelbar nach dem Schreiben dachte ich, ich überprüfe die Benutzeroberfläche. Es scheint, dass dies möglich ist – zumindest um ein Theme aus einem Git-Repository zu erstellen/zu importieren! Wie funktioniert das mit Updates? Kann es neue Commits abrufen? Ich habe Installing a theme from a private Git repository gefunden, aber das bespricht keine Updates.
Ist es möglich, ein bestehendes Theme oder eine Komponente so zu konvertieren, dass sie ein Git-Repository verfolgt?
Sie können ein Theme exportieren, es in ein Repository hochladen und dann installieren.
Alle Remote-Themes haben oben einen Abschnitt, in dem Sie entscheiden können, ob sie automatisch aktualisiert werden sollen, wenn Discourse aktualisiert wird. Darüber hinaus gibt es einen Hintergrundjob, der prüft, ob eine neuere Version verfügbar ist, und Sie können auch manuell nach neuen Updates suchen. Wenn eine neue Version verfügbar ist, bietet die Schaltfläche die Möglichkeit, die Komponente zu aktualisieren.
Diese Informationen finden Sie auch in der Anleitung unter Installing a theme or theme component.
Falls Sie es noch nicht gefunden haben, gibt es auch ein Tutorial zur Theme-Entwicklung.
Das ist großartig, danke @Moin! Das deckt zwei große Quellen für die Anpassung unserer Website ab.
Ich würde Git immer noch sehr gerne zur Verwaltung der Seitentexte verwenden, da viele davon (wie die Richtlinien und FAQs und dergleichen) lang, nicht trivial und für Community-Input und -Überprüfung Open Source sein können.
Die anderen Website-Einstellungen wären nett zu haben, aber definitiv nicht so entscheidend.
Diese basieren normalerweise auf einem Thema in der Mitarbeiterkategorie. Ich denke, Sie können sie in eine andere Kategorie verschieben und den Beitrag zu einer Wiki machen. Dann können Ihre Mitglieder sie bearbeiten.
Sie können auch die Website-Einstellungen FAQ URL, Privacy policy URL und ToS URL verwenden und diese woanders hosten.
Ja, aber die Einstellung FAQ URL hat leider andere Verhaltensweisen, die ihre Verwendung für diesen Zweck sehr selbstzerstörend machen.
Nur um darauf hinzuweisen, dass es klar ist, dass es bereits möglich ist, Inhalte in der Quellcodeverwaltung zu verwalten. Schauen Sie sich dieses Thema an, es wird auf GitHub gepflegt:
ganz unten:
obwohl ich mir nicht sicher bin, ob diese Funktionalität bereits veröffentlicht oder angekündigt wurde (oder ob dies beabsichtigt ist)
Ich habe angefangen, mit einer GitHub-Aktion herumzuspielen, die Updates über die API an den site_texts-Abschnitt des Admin-Panels sendet. Sie ist im Moment ziemlich rudimentär (und schlägt aus irgendeinem Grund bei großen Werten mit einem 422 fehl), aber sie ist vielversprechend.
Braucht definitiv mehr Arbeit.
