Conforme mostrado na figura abaixo, os plugins normais não possuem “css+html” personalizados, enquanto a maioria dos “componentes de tema” geralmente precisa ajustar “css+html”, o que nos leva a criar um grande número de css personalizados correspondentes, dificultando nossa identificação.
2 curtidas
Geralmente recomendamos o uso do GitHub ou de um sistema de controle de versão semelhante, pois isso facilita o acompanhamento do seu código ao longo do tempo.
Anteriormente, tínhamos um botão CSS/HTML em todos os temas e componentes de tema, mas ao editar um tema remoto, as alterações upstream no repositório remoto substituiriam a personalização local, e era uma experiência muito ruim que fazia as pessoas terem medo de atualizar.
Acho que uma solução possível seria manter a camada de personalização separada do repositório remoto, mas é essencialmente o que recomendamos agora (use um componente de tema para personalização local em um tema remoto), mas talvez com algumas etapas a menos.
7 curtidas
Uma solução, especialmente para componentes de tema, seria fazer um fork dos componentes de tema e fazer suas alterações em seu próprio fork.
1 curtida
O que quero dizer é que, quando usamos plug-ins de outras pessoas, em muitos casos, nós, usuários, precisamos de algum CSS personalizado para ajustar a aparência, mas esses plug-ins não têm a opção de CSS personalizado, o que nos leva a ter que criar plug-ins CSS independentes para corresponder aos plug-ins correspondentes, o que leva a muitos plug-ins confusos, o que é muito confuso.
Portanto, espero que o oficial possa oferecer suporte à personalização ao usar plug-ins no github, por exemplo: anexar automaticamente opções de CSS+HTML personalizáveis após a instalação do plug-in. Se não definirmos, não há necessidade de salvar nenhum dado. Se definirmos, os dados são gerados e armazenados de acordo com o "ID do plug-in". Claro, não sei como fazer isso especificamente.
Por favor, olhe a quantidade de CSS personalizado que tenho e você realmente entenderá o quão complicado isso é. Frequentemente não consigo encontrar meus arquivos CSS personalizados por causa das atualizações de plug-ins de outras pessoas no GitHub…
Se você quiser que sua instância do Discourse fique livre de componentes de tema independentes que são responsáveis por adicionar CSS personalizado para um plugin específico, você pode, em vez disso, criar um único componente de tema que seja responsável por todas as suas personalizações exclusivas que você deseja para os plugins que instalou.
Dentro desse componente de tema, você pode dividir todos os seus arquivos em múltiplos arquivos .scss e importá-los em um common.scss principal.
meu-componente-de-tema/
├── 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 curtidas
Sei que existem muitas maneiras de implementar CSS personalizado, mas postei este tópico para tornar o Discourse mais útil e dar sugestões. Entendo o resultado da sua resposta. Em resumo, você não está interessado em tornar o Discourse mais conciso. Atualize sua resposta e este tópico poderá ser fechado.
Ah, você tem razão, meu erro, eu entendi mal. Eu queria principalmente apontar uma sugestão para ajudar no seu caso específico e destacar o recurso de divisão de arquivos .scss que temos para componentes de tema, que pensei que você talvez não conhecesse.
Talvez este tópico seja mais adequado para Feature e, em seguida, a equipe de produto possa opinar e avaliar se é uma adição adequada.
2 curtidas
Eu preferiria uma camada de personalização dedicada relacionada a CSS nas configurações do componente com um botão para ativá-la ou desativá-la. Para qualquer coisa relacionada a HTML, é melhor fazer um fork do componente, pois não faria sentido em uma camada separada, acredito. Será mais fácil para um usuário gerenciar, reduzindo o inchaço desnecessário do componente. 
4 curtidas
Isto é algo que @david e eu discutimos recentemente.
Acho que a ideia vale a pena considerar, mas precisamos pensar cuidadosamente sobre os riscos – o sistema de temas já é bastante flexível e já existem muitas maneiras pelas quais as pessoas se metem em apuros, o que nem sempre é aparente imediatamente.
Com temas, componentes e personalizações manuais sobre um Discourse em constante mudança, não é muito difícil se expor a alterações que quebram em algum nó do grafo de dependência que eles constroem para si mesmos.
Faremos algum trabalho de tema em um futuro não muito distante que colocará nosso sistema de temas à prova de várias maneiras que podem nos levar a priorizar algumas mudanças aqui, mas, ao fazer isso, pensaremos mais profundamente sobre como habilitamos personalizações mais sustentáveis. Ainda não está claro onde isso nos levará, mas pode informar nossas opiniões sobre esta solicitação.
4 curtidas