(nicht empfohlen) Discourse-Templates aus einem Theme oder Plugin überschreiben

Idealerweise solltest du beim Anpassen von Discourse über Themes/Plugins CSS, die JavaScript-Plugin-API oder Plugin-Outlets verwenden. Wenn keines dieser Verfahren für deinen Anwendungsfall funktioniert, kannst du gerne einen PR an den Discourse-Core öffnen oder hier auf Meta ein #dev-Thema starten. Wir freuen uns immer darauf, über die Hinzufügung neuer Outlets/APIs zu diskutieren, um die Anpassung zu erleichtern.

Wenn du alle anderen Möglichkeiten ausgeschöpft hast, musst du möglicherweise auf Template-Overrides zurückgreifen. Mit dieser Technik kannst du das gesamte Template jeder Ember-Komponente oder Route aus deinem Theme/Plugin überschreiben.

:rotating_light: Dies ist keine empfohlene Methode zur Anpassung von Discourse. Alltägliche Änderungen im Discourse-Core werden früher oder später mit deinem Template-Override in Konflikt geraten und können potenziell zu katastrophalen Fehlern bei der Darstellung des Forens führen.

Wenn du dich für diesen Ansatz entscheidest, stelle sicher, dass du ausreichende automatisierte Tests und QA-Prozesse hast, um Regressionen zu erkennen. Wenn du ein Theme/Plugin mit Template-Overrides verteilst, stelle bitte sicher, dass die Foren-Admins sich der Stabilitätsrisiken bewusst sind, die dein Theme/Plugin mit sich bringt.

:rotating_light: :rotating_light: :rotating_light: Update Oktober 2023: Für neue Funktionen setzt Discourse zunehmend auf Komponenten, die im .gjs-Dateiformat von Ember erstellt werden. Die Templates für diese Komponenten sind inline definiert und können nicht von Themes/Plugins überschrieben werden.

Künftig sollten alle Template-Anpassungen über Plugin-Outlets erfolgen.

Ich verstehe, dass dies in naher Zukunft nicht mehr funktionieren wird, zeig mir trotzdem die Doku

Überschreiben von Komponententemplates

Um ein Ember-Komponententemplate zu überschreiben (d. h. alles unter components/* im Discourse-Core), solltest du in deinem Theme/Plugin eine .hbs-Datei mit demselben Namen erstellen. Zum Beispiel: Um das Template für die badge-button-Komponente im Discourse-Core zu überschreiben, würdest du eine Template-Datei an diesem Ort in deinem Theme/Plugin erstellen:

:art: {theme}/javascripts/discourse/templates/components/badge-button.hbs

:electric_plug: {plugin}/assets/javascripts/discourse/templates/components/badge-button.hbs

Der Override muss immer im /templates-Verzeichnis verschachtelt sein, selbst wenn die Core-Komponente ein „colocated“ (beigefügtes) Template hat.

Überschreiben von Routen-Templates

Das Überschreiben von Routen-Templates (d. h. alle Nicht-Komponenten-Templates unter templates/*) funktioniert auf die gleiche Weise wie bei Komponenten. Erstelle ein Template mit demselben Namen in deinem Theme/Plugin. Zum Beispiel: Um discovery.hbs im Core zu überschreiben, würdest du eine Datei wie folgt erstellen:

:art: {theme}/javascripts/discourse/templates/discovery.hbs

:electric_plug: {plugin}/assets/javascripts/discourse/templates/discovery.hbs

Interaktion zwischen mehreren Themes/Plugins

Wenn mehrere installierte Themes/Plugins dasselbe Template überschreiben, ist der „Sieger“ derjenige mit der niedrigsten Nummerierung in dieser Liste:

  1. Theme-Overrides (das Theme mit der höchsten „id“ gewinnt)
  2. Plugin-Overrides (der alphabetisch letzte Plugin-Name gewinnt)
  3. Core

Diese Priorisierung bedeutet auch, dass du Plugin-Templates aus Themes heraus überschreiben kannst. Technisch kannst du auch Theme-Templates aus anderen Themes und Plugin-Templates aus anderen Plugins überschreiben, aber das Verhalten kann überraschend sein, aufgrund der Abhängigkeit vom Plugin-Namen und der Theme-ID.

Wie funktioniert das?

Discourse stellt Templates zusammen und priorisiert sie in der DiscourseTemplateMap-Klasse. Für colocated Komponententemplates werden diese Informationen während der App-Initialisierung verwendet, um die Core-Template-Assoziationen zu ersetzen. Für alle anderen Templates wird die Map von dem Resolver zur Laufzeit verwendet, um das richtige Template abzurufen.


Dieses Dokument ist versioniert - schlage Änderungen auf GitHub vor.

17 „Gefällt mir“

Und was ist mit mobilen Vorlagen? Wie ist die Verzeichnisstruktur, um Vorlagen aus dem Kern neu zu schreiben?

Es sollte genau gleich funktionieren – Sie passen den Namen der Kernvorlage an. Wenn sie also /mobile enthält, fügen Sie dies in Ihre Überschreibung ein.

Ich versuche, die mobile login.hbs-Vorlage neu zu schreiben, und es funktioniert nicht Imgur: The magic of the Internet, liege ich mit dem Pfad richtig?

Der vollständige Pfad ist in Ihrem Screenshot, soweit ich sehen kann, nicht sichtbar. Bitte fügen Sie ihn hier als Text ein.

themeroot/javascripts/mobile/modal/login.hbs

Sie haben discourse/templates in Ihrem Pfad vergessen

In Ihrem Fall wäre das also {theme}/javascripts/discourse/templates/mobile/modal/login.hbs

2 „Gefällt mir“

Ist das immer noch der Fall?

Ich bin etwas traurig, dass die Möglichkeit, viel Code zu überschreiben, entfernt wird.

Es ist sinnvoll, das maßgeschneiderte Widget-System bis zu einem gewissen Grad zu ersetzen, aber das gab uns die Möglichkeit, auf mehreren Ebenen in bestehenden Code einzugreifen, wodurch das Risiko von Breaking Changes erheblich reduziert wurde, da wir uns auf kleine Blöcke auf clevere Weise konzentrieren konnten, die es uns ermöglichten:

  • Funktionen hinzuzufügen
  • nichts anderes zu stören.

Ich musste zum Beispiel gerade ZWEI wesentliche Funktionen aus Discourse Journal entfernen, die auf feingranularen Überschreibungen von Widgets basierten, da die einzige Möglichkeit, sie in Glimmer neu zu erstellen, über ein Paar Template-Überschreibungen erfolgte (einschließlich des Versuchs, eine .gjs-Datei zu ändern), was anscheinend nicht mehr unterstützt wird.

Selbst wenn dies unterstützt würde, müssten wir größere Codeabschnitte überschreiben als im Widget-Framework, mit einem damit verbundenen erhöhten Risiko, dass Kernänderungen mit den Überschreibungen in Konflikt geraten.

Das ist nicht gut für die Erweiterbarkeit der Plattform.

Kann man etwas dagegen tun?

7 „Gefällt mir“

Ja, ich verstehe dich – es gab einige nette Dinge an den erweiterbaren Widget-APIs.

Aber die Kehrseite ist, dass es für uns unglaublich schwierig war, IRGENDWELCHE der Widget-basierten Benutzeroberflächen im Kern zu ändern, da wir keine Ahnung hatten, welche zufälligen Methoden/Dekorationen Leute möglicherweise einführen. Deshalb schienen Widget-Anpassungen relativ stabil zu sein – wir hatten zu viel Angst, die Kernimplementierungen anzufassen.

Unsere Lösung dafür für die Zukunft sind Wrapper Plugin Outlets. Diese ermöglichen es Themes und Plugins, optional sehr kleine Vorlagenteile mit ihrer eigenen Implementierung zu überschreiben.

Sehen Sie zum Beispiel, wie Chat bedingt das Home-Logo überschreibt mit einer benutzerdefinierten Komponente. Das funktioniert für das bestehende Widget-basierte Header und den neuen Glimmer-basierten Header (bald verfügbar! :tm:).

Wir sind generell bereit, PRs zu akzeptieren, um neue Wrapper-Outlets an verschiedenen Stellen hinzuzufügen. Wenn Sie sich bei einem bestimmten Anwendungsfall unsicher sind, können Sie gerne ein #dev-Thema mit Details eröffnen!

10 „Gefällt mir“

OK, das klingt nach einem gangbaren Weg, danke.

Ich muss die Auswirkungen davon verdauen und meine Strategie entsprechend anpassen.

Ich schätze die Antwort!

6 „Gefällt mir“