As shown in the figure below, normal plugins do not have customized “css+html”, while most “theme components” usually need to adjust “css+html”, which leads to us creating a large number of corresponding custom css, which makes it difficult for us to identify
2 Likes
Generally we recommend using github or a similar version control system, as this makes it easier to track your code over time.
We previously had a CSS/HTML button on all themes and theme components, but when editing a remote theme, upstream changes in the remote repository would override local customization and it was a very poor experience that made people afraid to update.
I guess one possible solution would be to keep the customization layer separate from the remote repository, but that’s essentially what we recommend now (use a theme component for local customization to a remote theme), but maybe with a couple fewer steps.
7 Likes
One solution, especially for theme components, would be to fork the theme components and make your changes in your own fork.
1 Like
What I mean is that when we use other people’s plug-ins, in many cases we users need some custom CSS to adjust the appearance, but those plug-ins do not have the option of custom CSS, which leads to us having to create independent CSS plug-ins to match the corresponding plug-ins, which leads to a lot of messy plug-ins, which is very confusing.
So I hope the official can make support for customization when using plug-ins on github, for example: automatically attach customizable css+html options after installing the plug-in. If we don’t set it, then there is no need to save any data. If we set it, then data is generated and stored according to the “plug-in ID”. Of course, I don’t know how to do it specifically.
Please look at the amount of custom CSS I have and you will really understand how complicated this is. I often can’t find my custom CSS files because of other people’s GitHub plugin updates…
If you want your Discourse instance clear of independent theme components that’s responsible for adding custom css for a particular plugin, you could perhaps instead create a single theme-component that’s responsible for all your unique customizations you want for the plugins you have installed.
Inside that theme component, you can then split up all your files into multiple .scss files and import them in a main common.scss
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 Likes
I know there are many ways to implement custom CSS, but I posted this topic to make Discourse more useful and to give suggestions. I understand the result of your reply. In short, you are not interested in making Discourse more concise. Update your reply and this topic can be closed.
Ah, you’re right, my mistake I misunderstood. Was mainly wanting to point out a suggestion to help with your specific case and highlight the .scss file splitting feature we have for theme components I thought you might not be aware of.
Maybe this topic is better suited for Feature and then product team can chime in and assess whether it’s suitable addition.
2 Likes
I would prefer a dedicated CSS-related customization layer in the component settings with a button to enable or disable it. For any HTML-related, it’s best to fork the component, as it would not make sense in a separate layer I believe. It will be easier for a user to manage while reducing unnecessary component bloat. 
4 Likes
This is something that @david and I kicked around recently.
I think the idea is worth considering, but we need to think carefully about the risks – the theme system is already pretty flexible and there are many ways already that people get themselves into trouble, which isn’t always apparent immediately.
With themes, components, and manual customizations on top of a changing Discourse, it’s not too hard to expose oneself to breaking changes in some node of the dependency graph they construct for themselves.
We are going to be doing some theme work in the not too distant future that will put our theme system to the test in various ways that may lead us to prioritize some changes here, but in doing so, we are going to be thinking more deeply about how we enable more maintainable customizations. It’s not yet clear where that will lead us, but it may inform our opinions on this request.
4 Likes