提案されているのは、コアにバンドルされているプラグインがapp.yamlにリストされている場合、無視されるということです。app.yamlに含めることは冗長であり、所有者は削除できるという通知とともに。
私も、app.yamlにプラグインがリストされている限り、アップデートの失敗のリスクが常にあるのは少し迷惑だと感じています。そのため、アップデートを行うたびに、プラグインのいずれかがコアに追加されていないかを確認する必要があります。
提案されているのは、コアにバンドルされているプラグインがapp.yamlにリストされている場合、無視されるということです。app.yamlに含めることは冗長であり、所有者は削除できるという通知とともに。
私も、app.yamlにプラグインがリストされている限り、アップデートの失敗のリスクが常にあるのは少し迷惑だと感じています。そのため、アップデートを行うたびに、プラグインのいずれかがコアに追加されていないかを確認する必要があります。
なぜSysopのためにスクリプトを用意しないのですか?
私は、どのプラグインが公式であるかなどを把握するために、チームや作成者別にプラグインを整理しています。しかし、Discourseをより使いやすくするというのであれば、それはチーム側で行う必要があります。
ユーザーがPostreq(?)のアップグレード失敗により、壊れたアップグレードを抱えている場合に、人々を支援したときとそれほど違いはありません。
プラグインの場合、コマンドラインを使用せずにプラグインのインストールとアンインストールを簡素化するProcourse Installerのコンセプトがまさに素晴らしいアイデアでした。
確かに、何か問題が発生した場合に、もう少し洗練させる必要があったかもしれませんが、それはログファイルや、必要に応じてコマンドラインからの簡単なフォールバックで十分対応できたはずです。セルフホスティングをより魅力的にするために必要だったことは理解していますが、有料プランを選択するメリットも十分にあります。
このタイプのプラグインマネージャーは、ホストプランでプラグインをインストールできるように、作成またはフォークすることもできます。特定のプランで必要とされないプラグインもあるためです。
確かに、以前チャットがバンドルされていたことに関する投稿を見落としており、インストールしようとしました。プラグインのタグは更新されていなかったと思います。もちろん、理論上は不要なエントリとして削除できることを完了した再構築で通知して、エントリを無視できたかもしれないのに、プラグインをインストールしようとしたため、サイトはクラッシュしました。
フィードバックありがとうございます!![]()
これでこの件は終了できると思います。希望する同僚が返信する機会を与えるためにタイマーを設定します。
whos-online はコアに含められますか?
最近、より多くの公式プラグインをコアにバンドルする取り組みが行われている中で、「Who’s Online」プラグインが組み込みの対象として検討されているかどうか疑問に思いました。
公式ホスティングプランで利用可能(プラグインの割り当てに含まれる)であることに気づいたので、これがより広範な採用に向けた動きを示しているのかどうか興味があります。
パフォーマンスの制約や哲学的な適合性により、app.yml で特に指定されない限りデフォルトでオフのままにする必要がある場合は、完全に理解できます。
ありがとうございます!
最近、より多くの公式プラグインをコアにバンドルする取り組みが行われていますが、「オンライン中のユーザー」プラグインも含まれるか検討されていますか?
現在、これ以上プラグインをコアに移動する予定はありません。Cakedayが最後でしたが、以前デフォルトで有効になっていた方法にいくつかの複雑さがあったため、メインのバッチとは別に処理する必要がありました。
将来このような変更を容易にするために、もっとできることがあるという点はよく理解しています。この場合、app.ymlに変更が必要だったため、セルフホスト者がコマンドラインで行う必要がありましたが、他にどのようなことができたのか分かりません。
![]()
プロセスのフラストレーションについては完全に理解しています。確かに、私が望むほどスムーズではありません。背景を説明すると、根本的な問題は、app.ymlファイルがDiscourseの設定ファイルではないということです。これらはpupsの設定であり、プラグインのインストール行は単なるシェルコマンドです。
Discourse固有のロジックをpupsに持ち込み、特定のシェルコマンドを無視させることは実際にはオプションではありません。このツールはDiscourse専用ではないからです。さらに、多くの人が、知らないうちにブートストラップ中に実行されるシェルコマンドを変更されることに不満を感じるだろうと推測します。
そのため、利用可能なツールで私たちが見つけた最もクリーンなソリューションにたどり着きました。CLI再構築を強制し、影響を受ける行を構成から削除するように求めるメッセージを表示します。
興味深い投稿ですね、Davidさん!
OP of the Who’s Online plugin topicで気になる点を見つけました。
このプラグインのインストールには注意してください
「インストール」は、技術的に正しいのであれば、「有効化」と表現した方が良いと思います。
現在の表現では、追加のバンドルされたプラグインが存在することが哲学的な懸念やパフォーマンスに関する懸念であるかのような印象を与える可能性がありますが、実際にはそれが有効化されているかどうかだけです。以前は有効化されていなかった新しいコアプラグインは、再構築後にデフォルトで無効になるため、リスクはコアと一緒にインストールされていることではなく、それを有効にすることにあります。
現在の表現では、追加でバンドルされたプラグインが存在することが哲学的な懸念やパフォーマンスの懸念であるかのような印象を与える可能性がありますが、実際にはそれらが有効になっているかどうかだけです。
それは必ずしも真実ではありません。Disabled plugins still causing performance impact を参照してください。
現在、その特定の問題は(ほとんど)バンドルされたプラグインで解決されましたが、他のプラグインではまだあちこちで発生している可能性があります。
discourse-categories-suppressed プラグインは、選択したカテゴリを「最新」フィードから非表示にするためのシンプルでオプションの UI を追加します。これは、次の場所にある単一のドロップダウンを通じて統合されます。
管理者 → 設定 → カテゴリ
「ホームページから抑制されたカテゴリ」
これは非常に自然なコア設定のように思えます。特に次の理由によります。
• 公式であり、積極的にメンテナンスされている
• 管理者がオプトインしない限り、デフォルトでは無効のままです
• 多くのコミュニティ(私のコミュニティを含む)は、「最新」を主要なランディングビューとして利用しており、そこに表示されるものをより細かく制御したいと考えています
このプラグイン(デフォルトでは無効のまま)をバンドルすることを検討していただけますか?これにより、管理者は追加のインストールなしでこのトグルを使用できます。
ご検討いただきありがとうございます。多くのサイトがすぐに利用できることから恩恵を受けるであろう、小さな UI の好みのように思えます。
このトピックは2日後に自動的に閉じられました。返信はもう受け付けられません。