Como se muestra en la figura a continuación, los complementos normales no tienen “css+html” personalizados, mientras que la mayoría de los “componentes temáticos” suelen necesitar ajustar “css+html”, lo que nos lleva a crear una gran cantidad de CSS personalizados correspondientes, lo que dificulta nuestra identificación.
2 Me gusta
Generalmente recomendamos usar GitHub o un sistema de control de versiones similar, ya que esto facilita el seguimiento de su código a lo largo del tiempo.
Anteriormente teníamos un botón CSS/HTML en todos los temas y componentes de temas, pero al editar un tema remoto, los cambios de upstream en el repositorio remoto anularían la personalización local y fue una experiencia muy pobre que hizo que la gente tuviera miedo de actualizar.
Supongo que una posible solución sería mantener la capa de personalización separada del repositorio remoto, pero eso es esencialmente lo que recomendamos ahora (usar un componente de tema para la personalización local de un tema remoto), pero quizás con algunos pasos menos.
7 Me gusta
Una solución, especialmente para los componentes de temas, sería bifurcar los componentes del tema y realizar sus cambios en su propia bifurcación.
1 me gusta
Lo que quiero decir es que cuando usamos complementos de otras personas, en muchos casos nosotros, los usuarios, necesitamos CSS personalizado para ajustar la apariencia, pero esos complementos no tienen la opción de CSS personalizado, lo que nos obliga a crear complementos CSS independientes para que coincidan con los complementos correspondientes, lo que genera muchos complementos desordenados, lo cual es muy confuso.
Por lo tanto, espero que los desarrolladores oficiales puedan admitir la personalización al usar complementos en GitHub, por ejemplo: adjuntar automáticamente opciones de CSS+HTML personalizables después de instalar el complemento. Si no lo configuramos, entonces no es necesario guardar ningún dato. Si lo configuramos, entonces se generan y almacenan datos de acuerdo con el “ID del complemento”. Por supuesto, no sé cómo hacerlo específicamente.
Por favor, miren la cantidad de CSS personalizado que tengo y realmente entenderán lo complicado que es esto. A menudo no puedo encontrar mis archivos CSS personalizados debido a las actualizaciones de complementos de otras personas en GitHub…
Si deseas que tu instancia de Discourse esté libre de componentes de tema independientes que sean responsables de agregar CSS personalizado para un plugin en particular, podrías, en cambio, crear un único componente de tema que sea responsable de todas las personalizaciones únicas que desees para los plugins que tengas instalados.
Dentro de ese componente de tema, puedes dividir todos tus archivos en múltiples archivos .scss e importarlos en un common.scss principal.
mi-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 Me gusta
Sé que hay muchas maneras de implementar CSS personalizado, pero publiqué este tema para hacer Discourse más útil y dar sugerencias. Entiendo el resultado de tu respuesta. En resumen, no te interesa hacer Discourse más conciso. Actualiza tu respuesta y este tema se puede cerrar.
Ah, tienes razón, fue un error mío, entendí mal. Principalmente quería señalar una sugerencia para ayudarte en tu caso específico y destacar la función de división de archivos .scss que tenemos para componentes de temas, que pensé que quizás no conocías.
Quizás este tema sea más adecuado para Feature y luego el equipo de producto pueda intervenir y evaluar si es una adición adecuada.
2 Me gusta
Preferiría una capa de personalización dedicada relacionada con CSS en la configuración del componente con un botón para habilitarla o deshabilitarla. Para cualquier cosa relacionada con HTML, es mejor bifurcar el componente, ya que no tendría sentido en una capa separada, creo. Será más fácil de gestionar para un usuario y reducirá la hinchazón innecesaria del componente. 
4 Me gusta
Esto es algo que @david y yo discutimos recientemente.
Creo que la idea vale la pena considerarla, pero debemos pensar cuidadosamente en los riesgos: el sistema de temas ya es bastante flexible y ya hay muchas maneras en que las personas se meten en problemas, lo que no siempre es aparente de inmediato.
Con temas, componentes y personalizaciones manuales además de un Discourse cambiante, no es muy difícil exponerse a cambios disruptivos en algún nodo del grafo de dependencias que construyen por sí mismos.
Vamos a realizar algunos trabajos de temas en un futuro no muy lejano que pondrán a prueba nuestro sistema de temas de diversas maneras, lo que podría llevarnos a priorizar algunos cambios aquí, pero al hacerlo, pensaremos más profundamente en cómo permitimos personalizaciones más mantenibles. Aún no está claro a dónde nos llevará eso, pero puede informar nuestras opiniones sobre esta solicitud.
4 Me gusta