(ちなみに @Heliosurge、これ以前にも話題に出たと思うんだけど):
discourse_theme gem をインストールしたくないなら、もっと簡単だよ。テーマは zip ファイルとしてアップロードできるし、管理画面で直接かなり多くのことを構築できるよ。
(ちなみに @Heliosurge、これ以前にも話題に出たと思うんだけど):
discourse_theme gem をインストールしたくないなら、もっと簡単だよ。テーマは zip ファイルとしてアップロードできるし、管理画面で直接かなり多くのことを構築できるよ。
明らかに、このトピックは完全に本題から逸れてしまいました。これは、異論を唱えるスレッドではいつも起こることです。私はテーマコンポーネントの使用について議論するつもりはありませんが、それでも皆様のおかげで感謝しています。
どうして話がそれてしまったのでしょうか?質問に対して人々が意見を述べているだけなのに、完全にトピックに沿っているように見えるのですが?
これで必要な情報はすべて揃ったので、好きな設定を実装できますか?
どのようにして脱線してしまったのですか?
OPの「意見」が「OPが求めているものを揶揄するもの」へと変化していったことについては、ある程度同意します。
これ以上議論する必要はないと思います。したがって、このトピックに別の解決策を提案する人がいない限り、ここで議論を終了してもよいでしょう。
私も、いくつかの投稿には不要な攻撃性があるという点には同意します。
私は、ホームページにボタンを追加する件について、TC(テーマコンポーネント)に言及したに過ぎません。これはすでに複数のコンポーネントによって実証されています。セキュリティ上の問題でない限り、TCを採用するのが最適です。
なお、私はテーマやテーマコンポーネントに関してどのような課題を抱えているのか興味があります。プラグインは、セキュリティや、コア関数の変更のようにTC内では実現できない機能のために使用されます。もしよろしければ、友好的なプライベートメッセージ(PM)でこの件について話し合うことも可能です。
TCのもう一つの利点は、必要に応じてサイト内のWeb UIでコードを編集できることです。
私がプラグインルートで問題点として見ているのは、コアにマージされた公式プラグインでさえ、プラグインやDiscourse自体の更新にGitを使用している点です。
それを実現する方法は本当にあるのでしょうか?
app.yml でボリュームサポートを使用して、ホスト上のフォルダをコンテナ内のプラグインフォルダにマウントできます。