図に示すように、通常のプラグインにはカスタマイズされた「css+html」がありませんが、ほとんどの「テーマコンポーネント」は通常「css+html」の調整を必要とします。これにより、大量の対応するカスタムCSSが作成され、特定が困難になります。
「いいね！」 2
一般的に、コードの経時的な追跡を容易にするため、GitHubまたは同様のバージョン管理システムの使用をお勧めします。
以前は、すべてのテーマとテーマコンポーネントにCSS/HTMLボタンがありましたが、リモートテーマを編集する際、リモートリポジトリでのアップストリームの変更がローカルのカスタマイズを上書きしてしまい、非常に悪い体験であったため、人々は更新を恐れていました。
おそらく1つの可能な解決策は、カスタマイズレイヤーをリモートリポジトリから分離しておくことですが、それは基本的に現在お勧めしていること（リモートテーマへのローカルカスタマイズにはテーマコンポーネントを使用する）と同じですが、手順がもう少し少ないかもしれません。
「いいね！」 7
特にテーマコンポーネントの場合、テーマコンポーネントをフォークし、独自のフォークで変更を加えることが1つの解決策になります。
「いいね！」 1
「つまり、他の人のプラグインを使用する場合、多くの場合、ユーザーは外観を調整するためにカスタムCSSを必要としますが、それらのプラグインにはカスタムCSSのオプションがなく、対応するプラグインに一致させるために独立したCSSプラグインを作成する必要があり、多くの乱雑なプラグインにつながり、非常に混乱します。
そのため、GitHubでプラグインを使用する際に、例えば、プラグインをインストールした後にカスタマイズ可能なCSS+HTMLオプションを自動的に添付するなど、公式にカスタマイズのサポートをしてもらいたいと思います。設定しない場合は、データを保存する必要はありません。設定した場合は、データは「プラグインID」に従って生成および保存されます。もちろん、具体的にどのように行うかはわかりません。
私のカスタムCSSの量を見ていただければ、これがどれほど複雑であるかを本当に理解していただけるでしょう。他の人のGitHubプラグインの更新のために、カスタムCSSファイルを見つけられないことがよくあります…
もし、特定のプラグインのためにカスタムCSSを追加する独立したテーマコンポーネントをDiscourseインスタンスから削除したい場合は、代わりにインストールしたプラグインに固有のカスタマイズすべてを担当する単一のテーマコンポーネントを作成することを検討できます。
そのテーマコンポーネント内で、すべてのファイルを複数の.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