(ちなみに @Heliosurge、これ以前にも話題に出たと思うんだけど):
discourse_theme gem をインストールしたくないなら、もっと簡単だよ。テーマは zip ファイルとしてアップロードできるし、管理画面で直接かなり多くのことを構築できるよ。
(ちなみに @Heliosurge、これ以前にも話題に出たと思うんだけど):
discourse_theme gem をインストールしたくないなら、もっと簡単だよ。テーマは zip ファイルとしてアップロードできるし、管理画面で直接かなり多くのことを構築できるよ。
明らかに、このトピックは完全に本題から逸れてしまいました。これは、異論を唱えるスレッドではいつも起こることです。私はテーマコンポーネントの使用について議論するつもりはありませんが、それでも皆様のおかげで感謝しています。
どうして話がそれてしまったのでしょうか?質問に対して人々が意見を述べているだけなのに、完全にトピックに沿っているように見えるのですが?
これで必要な情報はすべて揃ったので、好きな設定を実装できますか?
どのようにして脱線してしまったのですか?
OPの「意見」が「OPが求めているものを揶揄するもの」へと変化していったことについては、ある程度同意します。
これ以上議論する必要はないと思います。したがって、このトピックに別の解決策を提案する人がいない限り、ここで議論を終了してもよいでしょう。
私も、いくつかの投稿には不要な攻撃性があるという点には同意します。
私は、ホームページにボタンを追加する件について、TC(テーマコンポーネント)に言及したに過ぎません。これはすでに複数のコンポーネントによって実証されています。セキュリティ上の問題でない限り、TCを採用するのが最適です。
なお、私はテーマやテーマコンポーネントに関してどのような課題を抱えているのか興味があります。プラグインは、セキュリティや、コア関数の変更のようにTC内では実現できない機能のために使用されます。もしよろしければ、友好的なプライベートメッセージ(PM)でこの件について話し合うことも可能です。
TCのもう一つの利点は、必要に応じてサイト内のWeb UIでコードを編集できることです。
私がプラグインルートで問題点として見ているのは、コアにマージされた公式プラグインでさえ、プラグインやDiscourse自体の更新にGitを使用している点です。
それを実現する方法は本当にあるのでしょうか?
app.yml でボリュームサポートを使用して、ホスト上のフォルダをコンテナ内のプラグインフォルダにマウントできます。
ソースコードを、どこに保管しているかにかかわらず、discourse/plugins ディレクトリにコピーする方法は任意のものをご利用いただけます。git clone がお好きでない場合は、rsync や cp -a をご利用いただけます。お好きな方法でプラグインを VM にコピーし、git clone が行うようなコピーを行うコマンドを挿入してください。
ソースコードを保管している場所から discourse/plugins ディレクトリにコピーする方法は、自由に選択できます
これこそが正しい回答でしょう。質問の本来の条件を尊重しています。このスレッドは、ポジティブでサポート的なコミュニティの姿を示すという点では、あまり良いものではありませんでした。
@Falco @pfaffman ありがとうございます。ご回答により、私の疑問は解消されました。
ホストマシンからローカルプラグインをDiscourseに読み込もうとしている方の参考になればと、私の app.yml 設定をここに残しておきます。
## Dockerコンテナはステートレスです。すべてのデータは/sharedに保存されます。
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
- volume:
host: /var/discourse/plugins
guest: /var/plugins
## プラグインはここに配置します。
## 詳細は https://meta.discourse.org/t/19157 を参照してください。
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- cp -a /var/plugins/. $home/plugins/
私の環境では、カスタムプラグインをすべてホストの /var/discourse/plugins に保存しています。
マウントされたディレクトリはコンテナ内で /var/plugins として利用可能になり、after_code フック実行時に以下のコマンドが実行されます。
cp -a /var/plugins/. $home/plugins/
これにより、マウントされたすべてのプラグインがDiscourseの標準プラグインディレクトリ($home/plugins、通常は /var/www/discourse/plugins)にコピーされます。
この方法により、gitベースのプラグインインストールやサードパーティのホスティングサービスに依存することなく、ホストから直接プラグインを管理することが可能になります。
素晴らしい。うまくいったようで何よりです!
プラグインをコピーする代わりに、シンボリックリンクを作成することもできます。そうしておけば、プラグインへの変更は(アセットの移行やコンパイルが必要ない場合など、少なくとも一部のケースでは)コンテナを再起動するだけで適用されます。
こんにちは、気になったので質問ですが、移行とデータベースの変更はどのように処理していますか?
これらはプラグインのインストール方法とは無関係です。プラグインが存在する場合、マイグレーションは処理されます。
マイグレーションとデータベースの変更はどのように処理していますか?
通常、コンテナを再構築します。ただし、特殊な状況を除きます。ただし、以下を実行することもできます。
rake db:migrate
また、アセットのプリコンパイルも可能です。ただし、特定のニーズがあり、Rails に精通している場合を除き、推奨しません。