Comme le montre la figure ci-dessous, les plugins normaux n’ont pas de « css+html » personnalisés, tandis que la plupart des « composants de thème » nécessitent généralement d’ajuster le « css+html », ce qui nous amène à créer un grand nombre de css personnalisés correspondants, ce qui rend difficile notre identification.
2 « J'aime »
En général, nous recommandons d’utiliser GitHub ou un système de contrôle de version similaire, car cela facilite le suivi de votre code au fil du temps.
Nous avions auparavant un bouton CSS/HTML sur tous les thèmes et composants de thème, mais lors de la modification d’un thème distant, les modifications en amont dans le dépôt distant remplaceraient la personnalisation locale, ce qui était une très mauvaise expérience qui effrayait les gens de mettre à jour.
Je suppose qu’une solution possible serait de garder la couche de personnalisation séparée du dépôt distant, mais c’est essentiellement ce que nous recommandons maintenant (utiliser un composant de thème pour la personnalisation locale d’un thème distant), mais peut-être avec quelques étapes en moins.
7 « J'aime »
Une solution, en particulier pour les composants de thème, serait de “fork” les composants de thème et d’apporter vos modifications dans votre propre fork.
1 « J'aime »
Ce que je veux dire, c’est que lorsque nous utilisons les plugins d’autres personnes, dans de nombreux cas, nous, les utilisateurs, avons besoin de CSS personnalisés pour ajuster l’apparence, mais ces plugins n’ont pas l’option de CSS personnalisés, ce qui nous oblige à créer des plugins CSS indépendants pour correspondre aux plugins correspondants, ce qui entraîne une multitude de plugins désordonnés, ce qui est très déroutant.
J’espère donc que l’officiel pourra prendre en charge la personnalisation lors de l’utilisation de plugins sur GitHub, par exemple : joindre automatiquement des options CSS+HTML personnalisables après l’installation du plugin. Si nous ne le configurons pas, alors il n’est pas nécessaire de sauvegarder de données. Si nous le configurons, alors les données sont générées et stockées selon l’“ID du plugin”. Bien sûr, je ne sais pas comment faire spécifiquement.
Regardez la quantité de CSS personnalisés que j’ai et vous comprendrez vraiment à quel point c’est compliqué. Je ne trouve souvent pas mes fichiers CSS personnalisés à cause des mises à jour des plugins GitHub d’autres personnes…
Si vous souhaitez que votre instance Discourse soit débarrassée des composants de thème indépendants responsables de l’ajout de CSS personnalisé pour un plugin particulier, vous pourriez peut-être plutôt créer un seul composant de thème responsable de toutes vos personnalisations uniques que vous souhaitez pour les plugins que vous avez installés.
À l’intérieur de ce composant de thème, vous pouvez ensuite diviser tous vos fichiers en plusieurs fichiers .scss et les importer dans un fichier common.scss principal.
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 « J'aime »
Je sais qu’il existe de nombreuses façons d’implémenter du CSS personnalisé, mais j’ai posté ce sujet pour rendre Discourse plus utile et pour faire des suggestions. Je comprends le résultat de votre réponse. En bref, vous ne vous intéressez pas à rendre Discourse plus concis. Mettez à jour votre réponse et ce sujet pourra être clos.
Ah, vous avez raison, c’est mon erreur, j’avais mal compris. Je voulais principalement faire une suggestion pour vous aider dans votre cas spécifique et souligner la fonctionnalité de division de fichiers .scss que nous avons pour les composants de thème, dont je pensais que vous n’étiez peut-être pas au courant.
Peut-être que ce sujet conviendrait mieux à Feature, et l’équipe produit pourrait alors intervenir et évaluer si c’est un ajout approprié.
2 « J'aime »
Je préférerais une couche de personnalisation dédiée liée au CSS dans les paramètres du composant avec un bouton pour l’activer ou la désactiver. Pour tout ce qui est lié au HTML, il est préférable de forker le composant, car cela n’aurait pas de sens dans une couche séparée, je crois. Ce sera plus facile à gérer pour un utilisateur tout en réduisant le superflu du composant. 
4 « J'aime »
C’est quelque chose dont @david et moi avons discuté récemment.
Je pense que l’idée mérite d’être examinée, mais nous devons réfléchir attentivement aux risques – le système de thèmes est déjà très flexible et il y a déjà de nombreuses façons dont les gens se mettent dans le pétrin, ce qui n’est pas toujours immédiatement apparent.
Avec les thèmes, les composants et les personnalisations manuelles par-dessus un Discourse en évolution, il n’est pas trop difficile de s’exposer à des changements majeurs dans un nœud du graphe de dépendances qu’ils construisent pour eux-mêmes.
Nous allons effectuer des travaux sur les thèmes dans un avenir proche qui mettront notre système de thèmes à l’épreuve de diverses manières, ce qui pourrait nous amener à prioriser certains changements ici, mais ce faisant, nous réfléchirons plus profondément à la manière dont nous permettons des personnalisations plus maintenables. On ne sait pas encore où cela nous mènera, mais cela pourrait éclairer nos opinions sur cette demande.
4 « J'aime »