Wie in der folgenden Abbildung gezeigt, haben normale Plugins kein angepasstes „CSS+HTML“, während die meisten „Theme-Komponenten“ normalerweise „CSS+HTML“ anpassen müssen, was dazu führt, dass wir eine große Anzahl entsprechender benutzerdefinierter CSS erstellen, was uns die Identifizierung erschwert.
2 „Gefällt mir“
Generell empfehlen wir die Verwendung von GitHub oder einem ähnlichen Versionskontrollsystem, da dies die Nachverfolgung Ihres Codes im Laufe der Zeit erleichtert.
Wir hatten früher eine CSS/HTML-Schaltfläche für alle Themes und Theme-Komponenten, aber beim Bearbeiten eines Remote-Themes würden Änderungen im Remote-Repository die lokalen Anpassungen überschreiben, und es war eine sehr schlechte Erfahrung, die die Leute davon abhielt, zu aktualisieren.
Ich vermute, eine mögliche Lösung wäre, die Anpassungsschicht vom Remote-Repository getrennt zu halten, aber das ist im Wesentlichen das, was wir jetzt empfehlen (verwenden Sie eine Theme-Komponente für lokale Anpassungen an einem Remote-Theme), aber vielleicht mit ein paar Schritten weniger.
7 „Gefällt mir“
Eine Lösung, insbesondere für Theme-Komponenten, wäre, die Theme-Komponenten zu forken und Ihre Änderungen in Ihrem eigenen Fork vorzunehmen.
1 „Gefällt mir“
Was ich meine ist, dass wir Benutzer, wenn wir Plugins von anderen Leuten verwenden, oft benutzerdefiniertes CSS benötigen, um das Erscheinungsbild anzupassen. Diese Plugins bieten jedoch keine Option für benutzerdefiniertes CSS, was dazu führt, dass wir unabhängige CSS-Plugins erstellen müssen, um die entsprechenden Plugins anzupassen. Dies führt zu vielen unübersichtlichen Plugins, was sehr verwirrend ist.
Daher hoffe ich, dass die Offiziellen die Unterstützung für Anpassungen bei der Verwendung von Plugins auf GitHub ermöglichen können, zum Beispiel: automatisch anpassbare CSS+HTML-Optionen nach der Installation des Plugins anhängen. Wenn wir nichts einstellen, müssen keine Daten gespeichert werden. Wenn wir es einstellen, werden Daten gemäß der „Plugin-ID“ generiert und gespeichert. Natürlich weiß ich nicht genau, wie es gemacht wird.
Bitte schauen Sie sich die Menge an benutzerdefiniertem CSS an, die ich habe, und Sie werden wirklich verstehen, wie kompliziert das ist. Ich kann meine benutzerdefinierten CSS-Dateien aufgrund von Updates fremder GitHub-Plugins oft nicht finden…
Wenn Sie möchten, dass Ihre Discourse-Instanz frei von unabhängigen Theme-Komponenten ist, die für das Hinzufügen von benutzerdefiniertem CSS für ein bestimmtes Plugin verantwortlich sind, könnten Sie stattdessen eine einzige Theme-Komponente erstellen, die für alle Ihre einzigartigen Anpassungen verantwortlich ist, die Sie für die installierten Plugins wünschen.
Innerhalb dieser Theme-Komponente können Sie dann alle Ihre Dateien in mehrere .scss-Dateien aufteilen und sie in einer Hauptdatei common.scss importieren.
my-theme-component/
├── about.json
├── common/
│ ├── common.scss
│ └── head_tag.html
├── scss/
│ ├── announcement-bar.scss
│ ├── banner-featured-links.scss
│ ├── category-banners.scss
│ ├── disco-toc.scss
│ ├── topic-list-excerpts.scss
│ ├── topic-list-thumbnails.scss
│ └── disco-toc.scss
└── settings.yml
3 „Gefällt mir“
Ich weiß, dass es viele Möglichkeiten gibt, benutzerdefiniertes CSS zu implementieren, aber ich habe dieses Thema gepostet, um Discourse nützlicher zu machen und Vorschläge zu machen. Ich verstehe das Ergebnis Ihrer Antwort. Kurz gesagt, Sie sind nicht daran interessiert, Discourse prägnanter zu gestalten. Aktualisieren Sie Ihre Antwort und dieses Thema kann geschlossen werden.
Ah, Sie haben Recht, mein Fehler, ich habe das missverstanden. Ich wollte hauptsächlich einen Vorschlag machen, um Ihnen in Ihrem speziellen Fall zu helfen, und die .scss-Datei-Aufteilungsfunktion hervorheben, die wir für Theme-Komponenten haben und von der ich dachte, dass Sie sie vielleicht nicht kennen.\n\nVielleicht ist dieses Thema besser für Feature geeignet und dann kann das Produktteam sich einklinken und beurteilen, ob es eine geeignete Ergänzung ist.
2 „Gefällt mir“
Ich würde eine dedizierte CSS-bezogene Anpassungsschicht in den Komponenteneinstellungen mit einer Schaltfläche zum Aktivieren oder Deaktivieren bevorzugen. Für alles, was mit HTML zu tun hat, ist es am besten, die Komponente zu forken, da dies meiner Meinung nach in einer separaten Schicht keinen Sinn ergeben würde. Es wäre für einen Benutzer einfacher zu verwalten und würde unnötige Komponentenerweiterungen reduzieren. 
4 „Gefällt mir“
Das ist etwas, das @david und ich kürzlich besprochen haben.
Ich denke, die Idee ist es wert, in Betracht gezogen zu werden, aber wir müssen die Risiken sorgfältig abwägen – das Themensystem ist bereits ziemlich flexibel und es gibt bereits viele Möglichkeiten, wie Leute sich in Schwierigkeiten bringen, was nicht immer sofort ersichtlich ist.
Mit Themes, Komponenten und manuellen Anpassungen zusätzlich zu einem sich ändernden Discourse ist es nicht allzu schwer, sich Breaking Changes in irgendeinem Knoten des selbst erstellten Abhängigkeitsgraphen auszusetzen.
Wir werden in naher Zukunft einige Theme-Arbeiten durchführen, die unser Themensystem auf verschiedene Weise auf die Probe stellen werden. Dies könnte dazu führen, dass wir einige Änderungen hier priorisieren. Dabei werden wir uns eingehender damit beschäftigen, wie wir wartbarere Anpassungen ermöglichen können. Es ist noch nicht klar, wohin uns das führen wird, aber es könnte unsere Meinung zu dieser Anfrage beeinflussen.
4 „Gefällt mir“