Es liegt auf der Hand, dass das Thema nun völlig vom Kurs abgekommen ist, wie das immer in Threads passiert, die gegen den Strich gehen. Ich beabsichtige nicht einmal, die Frage der Verwendung einer Theme-Komponente zu diskutieren, danke trotzdem an alle.
Ich stimme zu, dass einige der Beiträge unnötig aggressiv sind.
Ich habe ein TC nur im Zusammenhang mit deinem Vorschlag, einen Button auf der Startseite hinzuzufügen, erwähnt. Das wurde bereits von mehreren Komponenten gezeigt. Wenn es kein Sicherheitsproblem ist, ist ein TC der richtige Weg.
Obwohl ich selbst daran interessiert wäre, welche Probleme du mit Themes und Theme-Komponenten hast. Plugins sind eher für Sicherheit und Dinge gedacht, die nicht innerhalb eines TC erreicht werden können – wie das Ändern von Kernfunktionen. Wenn du dich wohler fühlst, könnten wir das in einem freundlichen PM besprechen.
Ein weiterer Vorteil des TC ist, dass du deinen Code bei Bedarf direkt über die Web-Oberfläche der Seite bearbeiten kannst.
Das Problem, das ich bei der Plugin-Lösung sehe, ist, dass selbst offizielle Plugins, die in den Kern integriert wurden, Git verwenden, um die Plugins und Discourse selbst zu aktualisieren.
Sie können jede beliebige Methode verwenden, um Ihren Quellcode von dem Ort, an dem Sie ihn speichern, in das Verzeichnis discourse/plugins zu kopieren. Wenn Sie git clone nicht mögen, können Sie rsync oder cp -a verwenden. Kopieren Sie Ihr Plugin einfach auf jede beliebige Weise in Ihre VM und fügen Sie einen Befehl hinzu, der es so kopiert, wie es git clone tun würde.
Das ist hier sicher die richtige Antwort. Sie respektiert die ursprünglichen Rahmenbedingungen der Frage. Dieser Thread hat aus der Sicht einer positiven und unterstützenden Community leider nicht wirklich überzeugt.
@Falco@pfaffman Vielen Dank, eure Antworten haben meine Zweifel ausgeräumt.
Ich lasse meine app.yml-Konfiguration hier, falls sie jemandem nützlich ist, der versucht, lokale Plugins in Discourse vom Host-Computer aus zu laden.
## Der Docker-Container ist zustandslos; alle Daten werden in /shared gespeichert
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
- volume:
host: /var/discourse/plugins
guest: /var/plugins
## Plugins kommen hierhin
## siehe https://meta.discourse.org/t/19157 für Details
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- cp -a /var/plugins/. $home/plugins/
In meiner Einrichtung behalte ich alle benutzerdefinierten Plugins in /var/discourse/plugins auf dem Host.
Das eingehängte Verzeichnis wird im Container als /var/plugins verfügbar gemacht, und während des after_code-Hooks kopiert der Befehl:
cp -a /var/plugins/. $home/plugins/
alle eingehängten Plugins in das native Plugins-Verzeichnis von Discourse ($home/plugins, normalerweise /var/www/discourse/plugins).
Dies ermöglicht es, Plugins direkt vom Host aus zu verwalten, ohne git-basierte Plugin-Installationen zu verwenden oder auf Drittanbieter-Hostingdienste angewiesen zu sein.
Super. Freut mich, dass es bei dir funktioniert hat!
Du könntest auch symbolische Links (symlinks) zu den Plugins erstellen, anstatt sie zu kopieren. Und wenn du das tust, können Änderungen an ihnen (zumindest in Fällen, in denen du keine Migrationen oder Kompilierung von Assets benötigst) durch einen Neustart des Containers übernommen werden.