Depuis la mise à jour d’hier (de mon serveur hébergé sur https://doomemacs.discourse.group), aucun de mes CSS personnalisés n’est appliqué. Les modifications apportées à mon ou mes thèmes ou au CSS des composants n’ont aucun effet (bien que les modifications de leur balise <head> ou d’autres sections HTML fonctionnent parfaitement).
Il y a une balise link suspecte pointant vers une feuille de style vide, dont le hachage change à chaque modification de mon CSS. Il semble que Discourse échoue silencieusement à compiler mes feuilles de style. Aucune mention d’échec n’apparaît dans mes journaux d’erreurs et discourse_theme télécharge mes feuilles de style sans émettre de plainte, mais sans effet.
Un administrateur pourrait-il s’en occuper s’il vous plaît ?
Salut @hlissner, je travaille sur une correction pour cela. Une récente mise à jour du cœur a cassé le composant de thème sur ton instance. Je devrais avoir une correction sous peu.
La correction est désormais intégrée au noyau et votre site est déployé @hlissner. Notez que j’ai désactivé deux composants de thème : celui avec des styles personnalisés (que vous pouvez réactiver) et discourse-theme-category-homepage, qui doit être mis à jour en amont avant de pouvoir être activé. Plus de détails à ce sujet sur Enhanced category-box display component - #7 by pmusaraj
Merci ! Les feuilles de style se chargent maintenant correctement, mais les variables de couleur SCSS ne semblent pas hériter du schéma de couleurs de mon thème. Par exemple, $secondary renvoie sa valeur par défaut, #ffffff, au lieu de #282c34. S’agit-il peut-être d’une autre régression liée à e8b8272 ?
Oui, il s’agit d’une nouvelle régression. La correction est un peu délicate… et pour la grande majorité des variables de couleur, les composants de thème devraient utiliser des propriétés CSS personnalisées. Vous pouvez consulter ce guide Update themes and plugins to support automatic dark mode pour un aperçu et des exemples sur la façon d’ajouter des variations de couleur personnalisées dans un fichier color_definitions.scss spécial de votre composant de thème.
Y a-t-il une meilleure approche ? Je pourrais ajouter des styles directement à chaque thème, mais je prévois d’en avoir beaucoup, et je préférerais gérer certains cas généraux depuis un composant central et global, dans la mesure du possible.
Oui, cela a du sens. Avez-vous essayé d’ajouter ce SCSS ci-dessus dans un nouveau fichier nommé common/color_definitions.scss ? Cela devrait fonctionner simplement en l’ajoutant là. (Il existe également un onglet dans l’interface utilisateur pour cette feuille de style spéciale.)
J’allais justement essayer exactement cela, puis le forum est tombé avec un message « Le logiciel alimentant ce forum de discussion a rencontré un problème inattendu », haha.
Vous pouvez accéder au site via /safe-mode, ce qui désactive les thèmes et les composants, puis vous pourrez voir ce qui s’est passé.
Cependant, il s’agit d’une autre régression : ces erreurs SCSS ne devraient pas faire planter l’ensemble du site. Je vais certainement régler cela dans les prochains jours.
Ça a marché ! Les variables de couleur sont correctement définies dans la portée de color_definitions.scss. Le seul problème est que je ne peux pas y importer d’autres feuilles de style. Par exemple :
Merci pour votre aide ! La PR a été fusionnée, mon instance a été mise à jour, et je peux maintenant importer des feuilles de style dans color_definitions.scss, mais ce problème est réapparu :
Cette fois, cela affecte également les variables dans color_definitions.scss.
Est-il possible de faire ce que vous essayez de faire sans hériter des variables SCSS du thème parent ? C’est un cas d’usage très spécifique et je préférerais ne pas ajouter cette complexité dans le cœur du système.
C’est tout à fait possible, mais peu pratique, car cela nécessiterait des centaines de lignes de code SCSS répétitif par thème (ainsi qu’un système de construction pour partager les variables entre tous), ce qui n’était pas nécessaire il y a une semaine. Cela dit, il serait probablement préférable de le faire de toute façon, pour éviter des problèmes lors de futurs refactorisations du processus de construction de Discourse. Je vais le faire. Merci !
Ce guide est un peu obsolète, c’est vrai, mais ce qui vous pose problème dans votre cas, ce ne sont pas les variables de base, mais plutôt les couleurs SCSS dans un composant qui n’hérite pas de la palette de couleurs du thème. (Néanmoins, je passerai en revue le guide et le mettrai à jour.)
Un peu de contexte : en août/septembre 2020, nous sommes passés à l’utilisation de propriétés CSS personnalisées pour les couleurs. La principale raison de ce changement était de pouvoir prendre en charge le mode sombre automatique de manière légère et rapide. Les thèmes comportent du CSS et du JS, ils ne peuvent donc pas être basculés rapidement, mais grâce aux propriétés CSS personnalisées, les palettes de couleurs peuvent être inversées à la volée, sans recharger la page.
Je vois sur votre site que vous avez 4 thèmes, chacun avec sa propre palette de couleurs, et un composant partagé entre les thèmes pour les styles communs. Vous pourriez obtenir essentiellement la même chose avec un thème principal (qui contiendrait tous les styles partagés) et 4 palettes de couleurs sélectionnables par l’utilisateur. Vous devrez déplacer tous les calculs de couleurs dans le fichier color_definitions.scss du thème principal, mais c’est réalisable. Je vais essayer de trouver un moment pour essayer cela demain.
Ce serait idéal, mais j’ai abouti à la configuration actuelle car plusieurs schémas de couleurs ne fonctionnaient pas pour moi. Certains schémas de couleurs produisent de mauvaises couleurs pour des variables générées automatiquement comme --primary-low. Redéfinir simplement la variable peut fonctionner pour un schéma de couleurs, mais pas pour un autre. Une solution plus générale est possible si nous la redéfinissons en fonction de $primary, ou conditionnellement en fonction de l’ID ou du nom du schéma de couleurs, mais sans cela, plusieurs thèmes sont nécessaires, ce qui me permettrait d’avoir un color_definitions.scss par thème (la duplication que je souhaite éviter). Ou existe-t-il une meilleure option que je n’aurais pas vue ?
