Benutzerdefiniertes CSS wird nicht auf mein Discourse angewendet

Unterstützung
1

Seit dem gestrigen Update (auf meinem gehosteten Server unter https://doomemacs.discourse.group) wird mein benutzerdefiniertes CSS nicht mehr angewendet. Änderungen an meinen Themes oder an den CSS-Dateien der Komponenten haben keine Wirkung (wobei Änderungen am <head> oder anderen HTML-Bereichen einwandfrei funktionieren).

Es gibt einen verdächtigen link-Tag, der auf ein leeres Stylesheet verweist, dessen Hash sich jedes Mal ändert, wenn ich mein CSS anpasse. Es scheint, als würde Discourse beim Kompilieren meiner Stylesheets stillschweigend fehlschlagen. In meinen Fehlerprotokollen gibt es keine Hinweise auf Fehler, und discourse_theme lädt meine Stylesheets ohne Beanstandung hoch, aber ohne Wirkung.

Könnte sich bitte ein Admin des Problems annehmen?

3 „Gefällt mir“
2

~~Ich bin mir nicht sicher, aber ich glaube, du stößt auf diese Änderung: https://meta.discourse.org/t/restrict-editing-of-remote-themes/170051~~
Sieht so aus, als wäre das falsch :smiley:

2 „Gefällt mir“
4

Hallo @hlissner, ich arbeite an einer Lösung dafür. Ein kürzlich durchgeführtes Upgrade des Kerns hat die Theme-Komponente auf deiner Instanz beschädigt. Ich sollte bald eine Lösung haben.

4 „Gefällt mir“
5

Die Korrektur wurde nun in den Kern übernommen und deine Seite ist bereitgestellt, @hlissner. Beachte bitte, dass ich zwei Theme-Komponenten deaktiviert habe: die mit benutzerdefinierten Stilen (die du wieder aktivieren kannst) und discourse-theme-category-homepage, die zuerst upstream aktualisiert werden muss, bevor du sie aktivieren kannst. Weitere Details dazu findest du unter Enhanced category-box display component - #7 by pmusaraj

5 „Gefällt mir“
6

Vielen Dank! Die Stylesheets werden nun korrekt geladen, jedoch scheinen die SCSS-Farbvariablen nicht das Farbschema meines Themes zu erben. Beispielsweise liefert $secondary den Standardwert #ffffff anstelle von #282c34. Handelt es sich hierbei womöglich um eine weitere Regression durch e8b8272?

2 „Gefällt mir“
7

Ja, es handelt sich um eine weitere Regression. Die Lösung ist etwas knifflig… und für die allermeisten Farbvariablen sollten Theme-Komponenten benutzerdefinierte CSS-Eigenschaften verwenden. In diesem Leitfaden Update themes and plugins to support automatic dark mode findest du einen Überblick und einige Beispiele, wie du benutzerdefinierte Farbvariationen in einer speziellen Datei color_definitions.scss in deiner Theme-Komponente hinzufügen kannst.

Lass mich wissen, wie es läuft!

2 „Gefällt mir“
8

Das habe ich soweit möglich getan, aber ohne Zugriff auf diese Variablen kann ich Farben nicht basierend auf meinem aktiven Schema anpassen. Z. B.:

$primary-low: dark-light-choose(darken($secondary, 12%), lighten($secondary, 10%));

:root {
    --primary-low: #{$primary-low};
}

Gibt es einen besseren Weg, das zu lösen? Ich könnte Stile direkt für jedes Theme hinzufügen, aber ich plane, viele davon zu haben, und würde es vorziehen, allgemeine Fälle so weit wie möglich von einer zentralen, globalen Komponente aus zu verwalten.

2 „Gefällt mir“
9

Ja, das ergibt Sinn. Hast du versucht, dieses SCSS oben in eine neue Datei unter common/color_definitions.scss zu fügen? Es sollte einfach funktionieren, wenn du es dort hinzufügst. (Es gibt auch einen Reiter in der Benutzeroberfläche für diese spezielle Stylesheet-Datei.)

2 „Gefällt mir“
10

Ich wollte genau das gerade ausprobieren, dann ist Discourse mit der Meldung ‚Die Software, die dieses Diskussionsforum betreibt, ist auf ein unerwartetes Problem gestoßen‘ ausgefallen, haha.

1 „Gefällt mir“
11

Sie können die Seite über /safe-mode aufrufen, was Themes und Komponenten deaktiviert, sodass Sie sehen können, was passiert ist.

Dies ist jedoch eine weitere Regression. Diese SCSS-Fehler sollten die gesamte Seite nicht zum Absturz bringen. Ich werde das in den nächsten Tagen definitiv beheben.

4 „Gefällt mir“
12

Das hat funktioniert! Die Farbvariablen sind im Gültigkeitsbereich von color_definitions.scss korrekt gesetzt. Das einzige Problem ist, dass ich keine anderen Stylesheets daraus importieren kann. Zum Beispiel:

// scss/globals.scss
$foo: "#000000";

// color_definitions.scss
@import "globals";
:root { --foo: #{$foo}; }

Dies führt in den Discourse-Protokollen zu folgendem Fehler:

SCSS-Kompilierungsfehler: Fehler: Datei zum Import nicht gefunden oder nicht lesbar: globals.scss.
        in Zeile 129 von color_definitions.scss
>> @import "globals";

Ich kann meine Stylesheets zwar so umgestalten, dass die Abhängigkeit entfällt, was also kein großes Problem ist, aber könnte dies als Fehler betrachtet werden?

2 „Gefällt mir“
13

Ja, ich habe einen PR erstellt, um das Importproblem zu beheben. Er sollte bis morgen gemerged werden.

https://github.com/discourse/discourse/pull/11963

3 „Gefällt mir“
14

Vielen Dank für deine Hilfe! Der PR wurde gemerged, meine Instanz wurde aktualisiert, und ich kann Stylesheets in color_definitions.scss importieren, aber dieses Problem ist wieder aufgetaucht:

Dieses Mal betrifft dies auch Variablen in color_definitions.scss.

1 „Gefällt mir“
15

Ist es möglich, das zu erreichen, was du vorhast, ohne die SCSS-Variablen des Eltern-Themes zu erben? Das ist ein sehr spezieller Anwendungsfall, und ich würde diese Komplexität lieber nicht in den Kern aufnehmen.

1 „Gefällt mir“
16

Es ist definitiv möglich, nur unpraktisch, da es pro Theme hunderte Zeilen an Boilerplate-SCSS erfordert (und ein Build-System, um Variablen über alle Themes hinweg zu teilen), die vor einer Woche noch nicht nötig waren. Dennoch wäre es wahrscheinlich am besten, dies ohnehin zu tun, um Probleme bei zukünftigen Refaktorierungen des Discourse-Build-Prozesses zu vermeiden. Ich werde das übernehmen. Danke!

1 „Gefällt mir“
17

Vielleicht sollte dieser Leitfaden überarbeitet oder entfernt werden, wenn er nicht mehr unterstützt wird.

2 „Gefällt mir“
18

Dieser Leitfaden ist tatsächlich etwas veraltet, ja. Allerdings liegt das Problem in deinem Fall nicht bei Kernvariablen, sondern bei SCSS-Farben in einer Komponente, die das Farbschema des Themas nicht erbt. (Dennoch werde ich den Leitfaden durchgehen und aktualisieren.)

Ein wenig Kontext: Im August/September 2020 sind wir dazu übergegangen, für Farben benutzerdefinierte CSS-Eigenschaften zu verwenden. Der Hauptgrund für diese Änderung war, dass wir automatischen Dark Mode auf eine leichte und schnelle Weise unterstützen konnten. Themen verfügen über CSS und JS, sodass sie nicht schnell umgeschaltet werden können. Durch die Verwendung benutzerdefinierter CSS-Eigenschaften können Farbschemata jedoch ohne Seitenneuladung im Handumdrehen umgeschaltet werden.

Ich sehe auf deiner Seite, dass du vier Themes mit jeweils einem Farbschema hast sowie eine Komponente, die über alle Themes hinweg für die gemeinsamen Stile verwendet wird. Du könntest im Wesentlichen dasselbe mit einem Hauptthema (das alle gemeinsamen Stile enthält) und vier vom Benutzer auswählbaren Farbschemata erreichen. Du müsstest alle Farbberechnungen in der Datei color_definitions.scss des Hauptthemas verschieben, aber das ist machbar. Ich werde versuchen, morgen etwas Zeit zu finden und das auszuprobieren.

19

Das wäre ideal, aber ich bin zu dem aktuellen Setup gekommen, weil mehrere Farbschemata für mich nicht funktionieren. Einige Farbschemata erzeugen schlechte Farben für automatisch generierte Variablen wie --primary-low. Das einfache Neudefinieren der Variable mag für ein Farbschema funktionieren, aber nicht für ein anderes. Eine allgemeinere Lösung ist möglich, wenn wir sie basierend auf $primary neu definieren oder bedingt basierend auf der ID/dem Namen des Farbschemas, aber ohne beides ist eine Mehrfachthemen-Struktur notwendig, damit ich eine pro-Thema-color_definitions.scss haben kann (die Duplizierung, die ich vermeiden möchte). Oder gibt es eine bessere Option, die ich übersehe?

20

Dieses Thema wurde automatisch nach 27 Tagen geschlossen. Neue Antworten sind nicht mehr möglich.