プラグインのスタイルシート：色にはCSSカスタムプロパティの使用が必須

開発
1

数日後、コアに この PR をマージし、プラグインのスタイルシートのコンパイル方法を変更します。この変更は、プラグインのスタイルシートで使用される SCSS 色変数に影響します。tl;dr（要約）は、それらを CSS カスタムプロパティに置き換える必要があるということです。ほとんどのプラグインはすでに更新済みで、多くの場合、これは単純な変更です。SCSS 変数を CSS カスタムプロパティに置き換える必要があります：

-   background-color: $primary-low;
+   background-color: var(--primary-low);

詳細な例や、より複雑な色の変換の处理方法については、Update themes and plugins to support automatic dark mode のガイドをご覧ください。（このガイドがあれば、プラグイン作成者がスタイルが正しく機能することを確認するために必要な情報はすべて揃っています。）

なぜこの変更を行っているのか疑問に思う方もいらっしゃるでしょう。以下をご覧ください。

以前は、コアとプラグインのスタイルシートは、SCSS 色変数が使用される場所にはテーマの色_scheme_を含めるために、テーマごとにコンパイルされていました。つまり、多くのテーマを持つサイト（またはマルチサイト環境）では、必要なすべての組み合わせをカバーするために、コアとプラグインのスタイルシートの数をアクティブなテーマの数で乗算する必要があったため、プリコンパイルに非常に時間がかかっていました。

2020 年 8 月以降、自動ダークモード切り替えをサポートするために、色変数を CSS カスタムプロパティとして格納する別の色定義スタイルシートを追加しました。この変更により、色_scheme_をその場で切り替えることが可能になりましたが、同時に、ほとんどのスタイルシートから色が抽象化されました。CSS カスタムプロパティの魔法のおかげで、スタイルシートをコンパイルする際に各テーマを読み込むことなく、色をどこでも（コア、プラグイン、テーマ）参照できるようになりました。

過去数ヶ月間、すべてのプラグインを CSS カスタムプロパティを使用するように変換してきました。Discourse プラグインの大部分はすでに最新ですが、まだ色に SCSS 変数を使用しているプラグインがわずかに存在する可能性があり、それらも更新する必要があります。

「いいね！」 10
2

明確なご説明ありがとうございます。私にもほとんど理解できました！

これにより、これらのルールに従わないテーマコンポーネントを持つサイトでのアップグレードや再構築が失敗する可能性がありますか？別の理由で発生した、Failed to Bootstrap, due to discourse-alt-logo theme component のようなケースです。

もしそうなら、ビルドログを解釈できない人々にとってエラーメッセージをより明確にする方法はありますか？例えば「アップグレードする前に x プラグインを削除してください」といったメッセージを追加するとか。あるいは、より良い方法として、そのような変更が予定されていることが分かっている時点で、管理パネルでユーザーに警告する仕組みはありますか？（あるいは、すでにそのような機能があるが、誰も読んでいないのかもしれません）。

「いいね！」 2
3

いいえ、これによってリビルドが失敗することはありません。更新されていないプラグインの色が正しく表示されなくなるだけです。これは自作プラグインでしか発生しないはずです。Meta に公開されているほとんどのプラグインを確認し、最新の状態になっていることを確認しました。

リンクされている問題は、この変更とは無関係です。これはテーマコンポーネントに関するもので、自動更新がマークされたテーマコンポーネントが自動更新できない場合、現在リビルドをブロックする仕組みになっています。

「いいね！」 4
4

あ、よかった。ごめんなさい。まだこれらの部品に慣れようとしています。

「いいね！」 2
5

ダークモードで問題が発生しました。引用テキストの色設定は、どこで、どの設定を変更すればよいでしょうか？

公開カテゴリでは問題ありませんが、PMのバブル内では読みづらくなっています。

いくつか検索してみましたが、正しい用語が見つかりませんでした。

これにはトピックへのリンクも影響しています。

Screenshot_20211028-184012
Screenshot_20211028-1840121080×2340 355 KB