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.
6 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. 
3 Likes