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개의 좋아요
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개의 좋아요
One solution, especially for theme components, would be to fork the theme components and make your changes in your own fork.
1개의 좋아요
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개의 좋아요
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.
아, 맞아요, 제 실수였습니다. 오해했네요. 주로 여러분의 특정 상황에 도움이 될 수 있는 제안을 드리고, 테마 컴포넌트를 위한 .scss 파일 분리 기능을 강조하고 싶었어요. 해당 기능을 아직 모르고 계실 것 같아서요.
아마 이 주제는 Contribute > Feature 채널에 더 적합할 것 같습니다. 그러면 프로덕트 팀이 의견을 제시하고, 추가하기에 적합한지 평가해볼 수 있을 거예요.
2개의 좋아요
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개의 좋아요
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개의 좋아요