これがあればとても助かります。
トラフィックの多い大規模なフォーラムでは、フォーラムがダウンするのは好ましくありません。私は毎回プラグインのインストールやアンインストールのたびに
./launcher rebuild app
を実行する必要があります。これによりフォーラムがしばらくダウンし、ユーザーが不満を抱いてしまいます。
管理GUIから直接Discourseのプラグインのインストール・アンインストールや、再構築・再起動を行える機能があれば大変助かります。
プラグインがアプリのリソースにビルド時に統合される仕組み、特に一部のプラグイン要素がバックエンドに影響を与えるため、これは不可能だと考えられます。
いくつかの軽減策:
-
可能な限りテーマコンポーネントでカスタマイズしてください。これらはオンラインで入れ替え、更新できます。
-
プラグインのセットを決定し、そのリストに固執してください。なぜセットアップを頻繁に変更する必要があるのでしょうか？
-
プラグインの更新のみが必要な場合は、オンラインアップグレードツールを使用してください。
-
新しいプラグインの追加は、コアアプリの根本的な変更により再ビルドを強いられたタイミングにスケジュールしてください。
「いいね！」 11
ここで私たちができる唯一の真の推奨事項は、事前に計画することです。それには代わりがありません。
変更したいプラグインの修正をテストして承認するには、小さなインスタンスを使用し、週または月ごとにライブサイトでそれらの変更を反映するための時間枠をスケジュールしてください。
これにより、ユーザーへの影響を大幅に抑えることができ、互換性の問題による追加のダウンタイムのリスクも大幅に軽減できます。
「いいね！」 4
複数の Web コンテナを持つ構成では、Web コンテナを一度に 1 つずつ再構築・デプロイすることで、再構築中のダウンタイムを確実に回避できます。
「いいね！」 5
@Faizan_Zahid さん、申し訳ありませんが、そのタイトルはもう少し良くできると思います。もしかして「Discourse」ではなく「プラグイン」をおっしゃりたいのでしょうか？私は、サーバーから Discourse を削除する機能を求めている人だと思っていたくらいです 
再構築を行わずにプラグインをインストール/アンインストールしたいとのことですね。残念ながら、それは現時点では不可能のようです 
再構築が必要になった際のダウンタイムを最小限に抑えたいというご要望は理解できます。これは最近も話題になったトピックです：「ゼロダウンタイム」設定に関するヘルプ（しかし、本来あるべき方向には進みませんでした）。
ここで必要なのは、おそらく 2 つの Web コンテナをセットアップする方法に関する丁寧なチュートリアル と、その活用方法についての説明でしょう。これが最も効率的な設定（おそらく最も複雑な設定でもあります）のようです。私はそのようなチュートリアルを作成するだけの知識が不足していますが、もし持っていれば作成していたでしょう。ご興味のある方はおられないでしょうか？
「いいね！」 3
上記を含む、さまざまな高度なユースケース向けの簡易ガイド作成というタスクを引き受ける予定です。これはバックログに載っています 
「いいね！」 2
Discourse が Docker を使用している場合は、Procourse インストーラーを利用できます。
これも再構築を行います。
「いいね！」 2
現在も動作していますが、AFAIK（私の知る限り）、Procourse は顧客へのサポートを停止しています。明確な保守ロードマップがない限り、これを推奨するのは非常にためらわれます。
「いいね！」 4
それは知りませんでした。Discourse の構造に大きな変更がなければ、引き続き動作するはずです。ただし、あくまで「はずです」です。もし作者がプロジェクトから離れてしまった場合、誰かに引き継いでもらえるかどうかが気になります。
時間の経過とともに、すべてのプラグインは更新が必要です。Discourse のプラグインは活発に開発されていても、小さな変更が時々問題を引き起こすことがあります。これを予測することはできず、ましてや誰にも依存できるものではありません。
プラグインのインストール自体を管理するプラグインがメンテナンスされていない場合、それは非常にリスクの高い提案です。それを楽観視して使い続けるのは、非常に悪い考えだと感じます。
これまでに、それを使用することに興味を示したクライアントは 2 社しかいませんでした。Procourse がもはや存在しないことが明確になると、両社とも移行することを強く望みました。
「いいね！」 1
これは、セキュリティが懸念される場合でも、DeVs がこの種の機能を Discourse に組み込むことを検討すべきだということに尽きます。コマンドラインで切り替え可能なオプションとして実装することも検討すべきです。
私の知る限り、その課題はそれよりも根本的なものです。現状のアプローチでは、マルチサイト環境では全く機能しません。
また、誤って互換性のないプラグインをインストールしてしまった場合、直接アンインストールすることはできません。SSH アクセスが必要です。
マルチサイトに関する問題を確認しました。Docker を使用していないマルチサイトでない場合にのみ許可するチェックを追加するだけで解決できるかもしれません。
そのため、多少の調整が必要になる可能性はありますが、マルチサイトではないインストールについては検討すべき事項です。
単一サイトのコンテナ向けに公式プラグインとして採用された場合でも同様です。
トピックをさらに下に読むと、プラグインの互換性に関する基本的なトラブルシューティングがどれだけ困難になるかがわかります。
これはロードマップに含めるべき事項です。Linux で GUI を使ってインストールする場合とコマンドラインを使う場合とでは、時としてそれほど大きな違いはありません。ただし、うまく機能させることに成功している例もあります。
非公式なインストールを使用する限り、システムが破損するリスクは常に存在します。そのため、テーマやテーマコンポーネントのように、プラグインをオン/オフで切り替えられる機能は理想的です。
最近、カテゴリアイコンが何らかの原因でシステムを破損させたという問題が発生しました。他の CSS 変更やコンポーネントがない基本的なテーマを使用していたにもかかわらずです。原因を特定するのに少し時間がかかりました。
奇妙なことに、最新の Discourse ベータ版を実行している別のテスト環境では問題なく動作します。