Vor einiger Zeit gab es eine Diskussion darüber, ob man in einem Theme oder einem Plugin entwickeln sollte. Der Rails-Teil von https://www.pfaffmanager.com/ wird langsam ziemlich stabil, und ich möchte die Entwicklung des Rails-Teils in eine Theme-Komponente verschieben. Das funktioniert ziemlich gut, und Änderungen an Templates und Initializern in der Theme-Komponente überschreiben das Plugin wie erwartet. Aber, Änderungen an javascripts/discourse/components/server-item.js.es6 im Theme überschreiben nicht dieselben Dateien im Plugin.
Ich könnte den Ember-Teil des Plugins ganz entfernen und ihn nur im Theme belassen, aber das würde wahrscheinlich einen Tag dauern, um all diese Teile zu verschieben, zu testen und auf den Server zu laden. Übersehe ich vielleicht etwas Einfaches? Sollte ich es einfach hinnehmen und die Teile, die ich in der Theme-Komponente haben möchte, komplett aus dem Plugin entfernen? Sollte ich alles im Plugin belassen?
Das gleiche Codefragment sowohl in der Theme-Komponente als auch im Plugin zu haben, erscheint mir etwas seltsam – meiner Meinung nach wäre es besser, sich zwischen Theme-Komponente/Plugin zu entscheiden und dann voll darauf zu setzen. Das Überschreiben ganzer Dateien ist nichts, was wir selbst tun, und wir empfehlen es auch nicht. Um das Kern-/Plugin-Verhalten zu überschreiben, sollte Ihre Theme-Komponente Methoden wie api.modifyClass verwenden.
Ich vermute, dass die Ursache hier darin liegt, dass Plugin-ES6-Module anders als Kern-/Theme-Module mit einem Präfix versehen werden. Wenn ich dies auf Ihrer Website ausführe, sehe ich, dass die Module mit plugin als Präfix versehen sind. Ich vermute, wenn wir die Theme-Komponente aktivieren würden, würden wir einen weiteren Eintrag sehen, aber mit einem anderen Präfix.
Ich stimme im Allgemeinen zu, es gibt jedoch einige Ausnahmefälle:
Wenn das Volumen der Änderungen an JavaScript die Änderungen am Backend bei weitem übersteigt, in welchem Fall Theme-Komponenten eine großartige Möglichkeit sind, Code SCHNELL bereitzustellen und bereitzustellen.
Wenn die meiste Funktionalität in der Basis-Theme-Komponente geliefert werden kann, aber das Hinzufügen eines ergänzenden Plugins zusätzliche Funktionen hinzufügen kann, die allein mit JavaScript nicht möglich sind. Ich setze diese Technik in Topic List Previews ein, wo die Komponente 90 % dessen leistet, wozu das Add-on fähig ist, aber wenn Sie auch das Plugin hinzufügen, erhalten Sie einige zusätzliche coole Dinge.
Dennoch ist die Verpackung von allem in einem Plugin sinnvoll, da es weniger Verwirrung bei der Konfiguration und Installation gibt und alles immer auf dem neuesten Stand gehalten wird.
Aber selbst in Ihrem Plugin+Theme-Szenario würde ich den Ember-Code nicht sowohl im Plugin als auch im Theme duplizieren. Daher müsste ich zumindest die meisten Vorlagen, Initialisierer und Komponenten aus dem Plugin herausreißen und sie nur in der Theme-Komponente belassen.
Da ich der Einzige sein werde, der über die Konfiguration verwirrt ist, ist das keine große Sache. Ich mag die Idee, neue Frontend-Sachen auf der Live-Website testen zu können, indem ich auf die Beta-Version des Themes umsteige.
Ich weiß es zu schätzen, dass Sie mir dabei helfen.
Das andere Problem, das ich sehe, sind QUnit-Tests. (Ich werde so tun, als könnte ich welche hinzufügen, was ein ganz anderes Problem ist; ich glaube, mein Problem ist, dass ich nicht weiß, wie ich die Tests mit Daten für die anzuzeigenden Elemente versehen kann…). Ich denke, wenn ich QUnit-Tests in meinem Plugin habe, werden diese ausgeführt, wenn ich zu GitHub pushe (weil ich ziemlich sicher bin, dass ich meine fehlerhaften Tests fehlschlagen gesehen habe).
Kann ich eine Theme-Komponente bekommen, die dasselbe tut?
Technisch sollte es möglich sein, aber ich glaube nicht, dass wir bereits fertige GitHub Actions Workflows für Themes haben. Das Theme-Testing wird derzeit etwas überarbeitet (für die Ember-CLI-Umstellung), aber danach können wir vielleicht einige Theme-Testing-Workflow-Vorlagen zu GitHub - discourse/.github hinzufügen.
Szenario: Ich möchte eine Vorlage überschreiben, die in einem Plugin bereitgestellt wird. Aber ich möchte sie auf eine codegesteuerte Weise überschreiben.
Also habe ich versucht, die neue Vorlage in einer Theme-Komponente zu versenden. Dieselbe Datei existiert in einem Plugin (ist aber anders).
Dies scheint auf meiner Dev-Cloud-Installation zu funktionieren, aber nicht auf einer Standard-Produktionsinstallation.
Ist es also fair zu sagen, dass man nicht vorhersagen kann, ob dies mit Vorlagen erfolgreich sein wird oder nicht? D.h. die Asset-Pipeline ist so beschaffen, dass man nicht vorhersagen kann, welche „Vorlage“ bestehen bleibt, da es keine vordefinierte oder vorhersagbare Rangfolge gibt?
Ich habe mit einer seltsamen Annahme gearbeitet, dass es eine Hierarchie gab, so etwas wie:
Kern
Plugin
Theme-Komponente
Lokale Website-Änderungen
Und wenn man eine „Datei“ mit demselben Pfad und Namen in einer späteren Ebene dieser Hierarchie ablegte, würde sie jede „vorherige“ Definition überschreiben.
Aber meine Annahme ist wahrscheinlich nicht sicher?
Ist die einzige „paketierte“ Lösung (lokale Website-Änderungen ausgeschlossen) daher, das Plugin zu forken und die Änderungen direkt darin vorzunehmen?
Das wäre in gewisser Weise schade, da es den Wartungsaufwand für Anpassungen erhöhen würde, da Sie Änderungen regelmäßig mit dem Haupt-Plugin-Repository zusammenführen müssten …
Der beste Weg wäre, das bestehende Plugin zu aktualisieren und ihm einen Plugin-Outlet und/oder eine Anpassungs-API zu geben, die die Theme-Komponente verwenden kann.
Mein Kommentar oben bezog sich speziell auf das Überschreiben ganzer JS-Dateien (d. h. ES6-Module). Das ist nicht möglich. Die Asset-Pipeline versieht Plugin/Theme-Module automatisch mit dem Namen/der ID des Plugins/Themes, sodass ein Konflikt mit dem Kern nicht möglich ist.
Für Vorlagen wissen wir, dass Leute (einschließlich uns, in einigen Situationen) sie überschreiben, daher werden wir dieses System wahrscheinlich weiterhin funktionsfähig halten. Aber bitte denken Sie daran, dass es ein Hack ist. Wenn die ursprüngliche Komponente/der ursprüngliche Controller sein Verhalten ändert, wird Ihre überschriebene Vorlage wahrscheinlich dazu führen, dass die Website abstürzt.
Im Allgemeinen denke ich, dass die von Ihnen erwähnte Hierarchie (Kern, Plugin, Theme) richtig sein sollte – wenn Sie also etwas anderes sehen, teilen Sie bitte die Details der Dateipfade im Plugin und Theme mit.
Danke für die Bestätigung. Mein Problem war eigentlich nicht damit zusammenhängend und die Klärung hat mir geholfen, an der richtigen Stelle zu suchen!
