A partire dall’aggiornamento di ieri (del mio server ospitato su https://doomemacs.discourse.group), nessuno dei miei CSS personalizzati viene applicato. Le modifiche ai miei temi o al CSS dei componenti non hanno alcun effetto (anche se le modifiche al tag <head> o ad altre sezioni HTML funzionano correttamente).
C’è un tag link sospetto che punta a un foglio di stile vuoto, il cui hash cambia ogni volta che modifico il mio CSS. Sembra che Discourse stia fallendo silenziosamente nella compilazione dei miei fogli di stile. Non ci sono menzioni di errori nei miei log e discourse_theme carica i miei fogli di stile senza lamentarsi, ma senza alcun effetto.
Un amministratore potrebbe gentilmente dare un’occhiata?
Ciao @hlissner, sto lavorando a una soluzione per questo: un recente aggiornamento del core ha rotto il componente del tema sulla tua istanza. Dovrei avere una correzione a breve.
La correzione è stata ora unita al core e il tuo sito è stato distribuito, @hlissner. Tieni presente che ho disabilitato due componenti del tema: quello con gli stili personalizzati (che puoi riattivare) e discourse-theme-category-homepage, che deve essere aggiornato a monte prima che tu possa abilitarlo. Maggiori dettagli su questo all’indirizzo Enhanced category-box display component - #7 by pmusaraj
Grazie! I fogli di stile vengono ora caricati correttamente, tuttavia le variabili di colore SCSS non sembrano ereditare lo schema colori del mio tema. Ad esempio, $secondary restituisce il valore predefinito, #ffffff, invece di #282c34. Potrebbe essere un’altra regressione introdotta da e8b8272?
Sì, si tratta di un’altra regressione. La correzione è un po’ complessa… e per la stragrande maggioranza delle variabili di colore, i componenti del tema dovrebbero utilizzare le proprietà CSS personalizzate. Puoi consultare questa guida Update themes and plugins to support automatic dark mode per una panoramica e alcuni esempi su come aggiungere variazioni di colore personalizzate in un file speciale color_definitions.scss nel tuo componente del tema.
Esiste un modo migliore per aggirare questo problema? Potrei aggiungere gli stili direttamente a ogni tema, ma intendo averne molti e preferirei gestire alcuni casi generali da un componente centrale e globale, quando possibile.
Sì, ha senso. Hai provato ad aggiungere quel codice SCSS sopra a un nuovo file in common/color_definitions.scss? Dovrebbe funzionare senza problemi se lo aggiungi lì. (C’è anche una scheda nell’interfaccia per quel foglio di stile speciale.)
Stavo per provare proprio questo, poi Discourse si è spento con un messaggio: ‘Il software che gestisce questo forum ha incontrato un problema inaspettato’, haha.
Funziona! Le variabili di colore sono impostate correttamente nell’ambito di color_definitions.scss. L’unico problema è che non riesco a importare altri fogli di stile da lì. Ad esempio:
Errore di compilazione SCSS: Errore: File da importare non trovato o non leggibile: globals.scss.
sulla riga 129 di color_definitions.scss
>> @import "globals";
Potrei ridisegnare i miei fogli di stile per evitare la dipendenza, quindi non è un grosso problema, ma si potrebbe considerare questo un bug?
Grazie per il tuo aiuto! La PR è stata unita, la mia istanza è stata aggiornata e riesco a importare i fogli di stile in color_definitions.scss, ma questo problema è riemerso:
Questa volta, ciò interessa anche le variabili in color_definitions.scss.
È possibile fare quello che stai cercando di fare senza ereditare le variabili SCSS del tema genitore? È un caso d’uso molto ristretto e preferirei non aggiungere quella complessità nel core.
È certamente possibile, solo scomodo, perché richiederà centinaia di righe di codice SCSS boilerplate per ogni tema (e un sistema di build per condividere le variabili tra tutti) che non erano necessarie una settimana fa. Detto questo, probabilmente è meglio farlo comunque, per evitare problemi con futuri refactoring del processo di build di Discourse. Lo farò. Grazie!
Quella guida è un po’ datata, sì, anche se nel tuo caso il problema non riguarda le variabili principali, ma piuttosto i colori SCSS in un componente che non eredita la palette di colori del tema. (Tuttavia, passerò in rassegna la guida e la aggiornerò.)
Un po’ di contesto: ad agosto/settembre 2020 abbiamo iniziato a utilizzare le proprietà CSS personalizzate per i colori. Il motivo principale di questo cambiamento è stato quello di supportare la modalità scura automatica in modo leggero e veloce. I temi hanno CSS e JS, quindi non possono essere scambiati rapidamente, ma utilizzando le proprietà CSS personalizzate, le palette di colori possono essere invertite al volo, senza ricaricare la pagina.
Vedo nel tuo sito che hai 4 temi con una palette di colori ciascuno e un componente condiviso tra i temi per gli stili comuni. Potresti ottenere essenzialmente la stessa cosa con un unico tema principale (che conterrebbe tutti gli stili condivisi) e 4 palette di colori selezionabili dall’utente. Dovresti spostare tutti i calcoli dei colori nel file color_definitions.scss del tema principale, ma è fattibile; cercherò di trovare un po’ di tempo e ci proverò domani.
Sarebbe l’ideale, ma sono arrivato alla configurazione attuale perché più schemi di colore non funzionavano per me. Alcuni schemi di colore producono colori scadenti per le variabili generate automaticamente come --primary-low. Ridefinire semplicemente la variabile potrebbe funzionare per uno schema di colore, ma non per un altro. Una soluzione più generale è possibile se la ridefiniamo in base a $primary, o condizionalmente in base all’ID/nome dello schema di colore, ma senza di essa sono necessari più temi, così da poter avere un color_definitions.scss per ogni tema (la duplicazione che vorrei evitare). O c’è un’opzione migliore che mi sto perdendo?
