セーフモードへのサーバーサイドプラグイン無効化の追加

開発
1

問題が発生し、サードパーティのカスタマイズを使用している場合、多くのユーザーは最初にセーフモードを試す傾向があります。これは当然のことです。問題の原因がどこにあるかわからないからです。

ただし、セーフモードは JavaScript のみを無効化します。サーバーサイドのコードが関与している場合、通常は app.yml ファイル内のすべてのプラグインのコメントアウトを外すのが即座の解決策です。これは有効な方法ですが、再構築が必要であり、比較的「技術的」な作業です。技術に詳しくないユーザーにとって、app.yml でコメントアウトを行うことは容易に踏み切れるものではありません。

そこで、セーフモードでサーバーサイドのプラグイン無効化を追加する PR の実現可能性について考えています。セーフモードのコントローラー内で、以下のような実装を想定しています。

find_opts = {
  include_official: params["only_official"] != 'true',
  include_unofficial: params["no_plugins"] == "true"
}
      
Discourse.find_plugins(find_opts).each do |plugin|
  if plugin.enabled_site_setting.present?
    SiteSetting.set(plugin.enabled_site_setting, false)
  end
end

確かに、ユーザーがサイト設定を確認してプラグインをオフにすることで同じ効果を得ることは可能です。しかし、ユーザーは実際にそのような手順を踏むことは稀だと感じています。

「いいね！」 2
2

現在のセーフモードは現在のページのみを対象としており、新しいタブを開くかリフレッシュすると無効になります。したがって、テスト用途としては完全に安全です。

ご提案の内容は、設定を永続的に切り替えるものとなり、サイト全体に影響を及ぼすことになります。つまり、管理者にのみ制限を設ける必要があります。

ご提案の意図は理解しましたが、動作の大きな変更となります。

「いいね！」 3
3

その通りです。

重要な点は、非技術系のサイト管理者は、サイトが故障した際に動作を回復させる解決策を求めていることです。「セーフモード」は、それが実現できると（正しくても間違っていても）よく認識されています。これを可能にする方法の一つとして、追加の管理者用セーフモード制御を導入するという案があります。

/admin/plugins 経路に大きなボタンを追加して、同じ方法で全てのプラグインを自動的に無効化することも考えられますが、それが同様の効果をもたらすかどうかは疑問です。もしかしたら効果があるかもしれません。

また、現在の Discourse プラグインアーキテクチャの範囲内で比較的実現可能であるという点も、この案に惹かれる理由の一つです。

「いいね！」 5
4

@sam、どう思いますか？

5

通常、プラグインを破損させるのは互換性のないコアの変更であり、問題のあるプラグインを含めると、起動やブートストラップすら行われないことがよくあります。

すべてのプラグインをオフにする機能は、正しく機能させるためには何らかの方法でアプリを再起動する必要があります。

私は、プラグインディレクトリ内のファイルを移動してプラグインを簡単に無効化/有効化し、アプリを再起動できるようにする Docker マネージャープラグインの変更には賛成です。これにより、デバッグが迅速に行えるようになるでしょう。

「いいね！」 4
6

それも良いと思います。

ただし、サーバーサイドのプラグイン API でラップされたコードに起因するエラーも決して少なくないと感じています。これはこれで対応されるはずです（そう思います）。

現状では、「セーフモード」（あるいはそれに類するもの）も、破損による問題に対する完全な解決策ではありません。プラグインを自動的に無効化する機能を追加すれば、より良い解決策となり、フル再起動や設定変更が必要なケースを減らすことができます。また、非技術的なサイト管理者の視点にもより沿ったものになるでしょう。

私は、比較的容易な段階的な改善を求めています。おそらく、Docker マネージャーの変更も、技術的な観点からは同様にシンプルなものではないでしょうか。

7

はい、可能であれば将来的に、コンテナの再ビルドなしで動作する「すべてのプラグインを無効化」する単一のブール値を管理設定に追加できれば、非常に素晴らしいことです。ただし、Discourseの開発者ではないため（node.js と vuejs アプリ開発の経験が 1 年あるのみですが）、直感的にはこれは簡単な変更ではなく、アーキテクチャ全体に大きな変更を伴うものだと感じます。

以前の LAMP フォーラムにはこの機能があり、プラグインが原因の誤りを素早く特定するために、このブール値を何度も使用しました。しかし、ソフトウェアのアーキテクチャがあまりにも異なるため、比較すること自体が役立たないほどです。

私個人としては、Discourse チームが何か良い解決策を考案してくれると確信しています。多くのユーザーがプラグインに依存しており、時間の経過とともに新たな課題（ドラゴン）が現れることになるでしょう。

ご確認いただき、ありがとうございます。

「いいね！」 1
8

私にとって大きな要因は、この機能が 100% セルフホストユーザー向けになることです。コアにプラグイン用のセーフモードを持ち込むのはあまり望ましくありません。私たちがそれを使用するとは考えにくく、5 つのクラスター間で再起動を調整するのは困難です。

Docker マネージャーがここで適切な手段です。既にアプリの再起動をサポートしており、あなたの提案が機能するために必要なものです。また、Discourse コアの変更なしに必要なすべての処理を行うことができます。

「いいね！」 5
9

わかりました。そこに集中します。

「いいね！」 4