Как показано на рисунке ниже, обычные плагины не имеют кастомизированного «css+html», тогда как большинство «компонентов темы» обычно требуют настройки «css+html», что приводит к созданию большого количества соответствующих пользовательских CSS-файлов, что затрудняет их идентификацию.
2 лайка
Как правило, мы рекомендуем использовать GitHub или аналогичную систему контроля версий, так как это упрощает отслеживание изменений в коде с течением времени.
Ранее во всех темах и компонентах тем была кнопка CSS/HTML, однако при редактировании удалённой темы изменения в удалённом репозитории могли переопределять локальные настройки, что приводило к крайне неудовлетворительному опыту и заставляло пользователей опасаться обновлений.
Возможно, одно из решений — сохранять слой кастомизации отдельно от удалённого репозитория, но по сути это то, что мы рекомендуем сейчас (использовать компонент темы для локальной настройки удалённой темы), возможно, с меньшим количеством шагов.
7 лайков
Одним из решений, особенно для компонентов темы, будет создание форка компонентов темы и внесение изменений в вашу собственную копию.
1 лайк
То, что я имею в виду, заключается в следующем: когда мы используем плагины других людей, во многих случаях нам, пользователям, нужен собственный CSS для настройки внешнего вида, но у этих плагинов нет опции для кастомного CSS. Это вынуждает нас создавать отдельные CSS-плагины, соответствующие основным плагинам, что приводит к большому количеству запутанных плагинов и создаёт путаницу.
Поэтому я надеюсь, что официальные разработчики добавят поддержку кастомизации при использовании плагинов на GitHub. Например: автоматически добавлять опции для настраиваемого CSS и HTML после установки плагина. Если мы ничего не настроим, данные не будут сохраняться. Если же мы что-то настроим, данные будут генерироваться и храниться в соответствии с «ID плагина». Конечно, я не знаю, как именно это реализовать.
Пожалуйста, посмотрите на объём моего кастомного CSS, и вы действительно поймёте, насколько всё сложно. Из-за обновлений чужих плагинов на GitHub я часто не могу найти свои файлы с кастомным CSS…
Если вы хотите, чтобы ваш экземпляр Discourse был свободен от независимых компонентов тем, отвечающих за добавление пользовательских стилей CSS для конкретного плагина, вы можете вместо этого создать один компонент темы, который будет отвечать за все уникальные настройки, которые вы хотите применить к установленным вами плагинам.
Внутри этого компонента темы вы можете разделить все свои файлы на несколько .scss файлов и импортировать их в главный файл 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 лайка
Я знаю, что существует множество способов реализации пользовательских CSS-стилей, но я создал эту тему, чтобы сделать Discourse более полезным и внести предложения. Я понял суть вашего ответа. Коротко говоря, вы не заинтересованы в том, чтобы сделать Discourse более лаконичным. Обновите ваш ответ, и эту тему можно будет закрыть.
Ах, вы правы, моя ошибка, я неправильно понял. Я в основном хотел предложить идею, которая поможет в вашем конкретном случае, и обратить внимание на функцию разделения файлов .scss для компонентов темы, о которой вы, возможно, не знали.
Возможно, эту тему лучше перенести в #feature, чтобы команда продукта могла подключиться и оценить, подходит ли это как дополнение.
2 лайка
Я бы предпочёл отдельный слой кастомизации, связанный с CSS, в настройках компонента, с кнопкой для его включения или отключения. Что касается HTML-изменений, то лучше всего форкнуть компонент, так как, на мой взгляд, выделение их в отдельный слой не имеет смысла. Это упростит управление для пользователя и избавит от ненужного раздувания компонента. 
4 лайка
Это то, что мы с @david недавно обсуждали.
Я считаю, что идея заслуживает рассмотрения, но нам нужно тщательно взвесить риски — система тем уже довольно гибкая, и существует множество способов, которыми пользователи сами создают проблемы, что не всегда сразу очевидно.
С учётом тем, компонентов и ручных доработок поверх постоянно меняющегося Discourse, довольно легко столкнуться с нарушениями из-за изменений в какой-либо части графа зависимостей, который пользователи выстраивают для себя.
В ближайшем будущем мы планируем провести работу с темами, которая в различных аспектах проверит нашу систему тем на прочность. Это может привести к тому, что мы отдадим приоритет некоторым изменениям здесь. При этом мы будем глубже продумывать, как обеспечить более поддерживаемые кастомизации. Пока неясно, к чему это приведёт, но это может повлиять на наше мнение по данному запросу.
4 лайка