提案されているのは、コアにバンドルされているプラグインがapp.yamlにリストされている場合、無視されるということです。app.yamlに含めることは冗長であり、所有者は削除できるという通知とともに。
私も、app.yamlにプラグインがリストされている限り、アップデートの失敗のリスクが常にあるのは少し迷惑だと感じています。そのため、アップデートを行うたびに、プラグインのいずれかがコアに追加されていないかを確認する必要があります。
「いいね！」 3
なぜSysopのためにスクリプトを用意しないのですか？
私は、どのプラグインが公式であるかなどを把握するために、チームや作成者別にプラグインを整理しています。しかし、Discourseをより使いやすくするというのであれば、それはチーム側で行う必要があります。
ユーザーがPostreq（？）のアップグレード失敗により、壊れたアップグレードを抱えている場合に、人々を支援したときとそれほど違いはありません。
プラグインの場合、コマンドラインを使用せずにプラグインのインストールとアンインストールを簡素化するProcourse Installerのコンセプトがまさに素晴らしいアイデアでした。
確かに、何か問題が発生した場合に、もう少し洗練させる必要があったかもしれませんが、それはログファイルや、必要に応じてコマンドラインからの簡単なフォールバックで十分対応できたはずです。セルフホスティングをより魅力的にするために必要だったことは理解していますが、有料プランを選択するメリットも十分にあります。
このタイプのプラグインマネージャーは、ホストプランでプラグインをインストールできるように、作成またはフォークすることもできます。特定のプランで必要とされないプラグインもあるためです。
「いいね！」 1
確かに、以前チャットがバンドルされていたことに関する投稿を見落としており、インストールしようとしました。プラグインのタグは更新されていなかったと思います。もちろん、理論上は不要なエントリとして削除できることを完了した再構築で通知して、エントリを無視できたかもしれないのに、プラグインをインストールしようとしたため、サイトはクラッシュしました。
「いいね！」 1
フィードバックありがとうございます！
これでこの件は終了できると思います。希望する同僚が返信する機会を与えるためにタイマーを設定します。
whos-online はコアに含められますか？
最近、より多くの公式プラグインをコアにバンドルする取り組みが行われている中で、「Who’s Online」プラグインが組み込みの対象として検討されているかどうか疑問に思いました。
公式ホスティングプランで利用可能（プラグインの割り当てに含まれる）であることに気づいたので、これがより広範な採用に向けた動きを示しているのかどうか興味があります。
パフォーマンスの制約や哲学的な適合性により、app.yml で特に指定されない限りデフォルトでオフのままにする必要がある場合は、完全に理解できます。
ありがとうございます！
「いいね！」 2
現在、これ以上プラグインをコアに移動する予定はありません。Cakedayが最後でしたが、以前デフォルトで有効になっていた方法にいくつかの複雑さがあったため、メインのバッチとは別に処理する必要がありました。
プロセスのフラストレーションについては完全に理解しています。確かに、私が望むほどスムーズではありません。背景を説明すると、根本的な問題は、app.ymlファイルがDiscourseの設定ファイルではないということです。これらはpupsの設定であり、プラグインのインストール行は単なるシェルコマンドです。
Discourse固有のロジックをpupsに持ち込み、特定のシェルコマンドを無視させることは実際にはオプションではありません。このツールはDiscourse専用ではないからです。さらに、多くの人が、知らないうちにブートストラップ中に実行されるシェルコマンドを変更されることに不満を感じるだろうと推測します。
そのため、利用可能なツールで私たちが見つけた最もクリーンなソリューションにたどり着きました。CLI再構築を強制し、影響を受ける行を構成から削除するように求めるメッセージを表示します。
「いいね！」 5
興味深い投稿ですね、Davidさん！
OP of the Who’s Online plugin topicで気になる点を見つけました。
このプラグインのインストールには注意してください
「インストール」は、技術的に正しいのであれば、「有効化」と表現した方が良いと思います。
現在の表現では、追加のバンドルされたプラグインが存在することが哲学的な懸念やパフォーマンスに関する懸念であるかのような印象を与える可能性がありますが、実際にはそれが有効化されているかどうかだけです。以前は有効化されていなかった新しいコアプラグインは、再構築後にデフォルトで無効になるため、リスクはコアと一緒にインストールされていることではなく、それを有効にすることにあります。
それは必ずしも真実ではありません。Disabled plugins still causing performance impact を参照してください。
現在、その特定の問題は（ほとんど）バンドルされたプラグインで解決されましたが、他のプラグインではまだあちこちで発生している可能性があります。
「いいね！」 2
discourse-categories-suppressed プラグインは、選択したカテゴリを「最新」フィードから非表示にするためのシンプルでオプションの UI を追加します。これは、次の場所にある単一のドロップダウンを通じて統合されます。
管理者 → 設定 → カテゴリ
「ホームページから抑制されたカテゴリ」
これは非常に自然なコア設定のように思えます。特に次の理由によります。
• 公式であり、積極的にメンテナンスされている
• 管理者がオプトインしない限り、デフォルトでは無効のままです
• 多くのコミュニティ（私のコミュニティを含む）は、「最新」を主要なランディングビューとして利用しており、そこに表示されるものをより細かく制御したいと考えています
このプラグイン（デフォルトでは無効のまま）をバンドルすることを検討していただけますか？これにより、管理者は追加のインストールなしでこのトグルを使用できます。
ご検討いただきありがとうございます。多くのサイトがすぐに利用できることから恩恵を受けるであろう、小さな UI の好みのように思えます。
「いいね！」 3
このトピックは2日後に自動的に閉じられました。返信はもう受け付けられません。
これが意図されたものかどうかはわかりませんが、報告しておきます。
私たちは古い安定版の v3.5.4 を使用しており、cakeday プラグインを使用していました。しかし、cakeday がコアにマージされたため（同じ Discourse バージョンの）リビルドが機能しなくなりました。そこで、yml ファイルでプラグインを無効にしたところ…消えてしまいました。これで再びビルドは行われますが、管理画面には機能がインストールされている兆候がないため、ケーキの日が表示されなくなりました。
古い安定版を使用していることが原因だと思いますが、Discourse の同じバージョンのリビルドとしては予期せぬ結果でした。
cakeday プラグインは 3.5.4 にバンドルされていないため、それが見えなくなったのはそのためでしょう。
それらが失敗し始めた理由が本当にそれだと確信していますか？もし次のようなものを見たのであれば:
HINT: プラグイン ‘$plugin’ は Discourse にバンドルされるようになったため、コンテナ設定に含めるべきではありません
残念ながら、cakeday プラグインが設定ファイルに含まれている場合、失敗した再構築に対してこれが表示されます。これは、人々に問題について警告するための最も効率的な方法でしたが、古いコアバージョンを実行している人にとっては混乱を招く可能性があります。
したがって、cakeday プラグインが必要な場合は、app.yml ファイルに再度追加して再構築できるはずです。失敗の原因は別のものであり、それはすでに解決したのだと思います。
ちなみに、サポートされているバージョンにアップグレードすることを強くお勧めします。3.5 はセキュリティ更新を受け付けておらず、攻撃に対して脆弱になる可能性があります。
そのように見えます:
'docker_manager' にクローン中...
I, [2026-03-09T15:05:49.126710 #1] INFO -- : > cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git
fatal: destination path 'discourse-cakeday' already exists and is not an empty directory.
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `spawn'
exec failed with the params {"cd"=>"$home/plugins", "cmd"=>["git clone https://github.com/discourse/docker_manager.git", "git clone https://github.com/discourse/discourse-cakeday.git", "git clone https://github.com/discourse/discourse-whos-online.git", "git clone -b no-regional-flags https://github.com/mentalstring/discourse-nationalflags.git", "git clone https://github.com/discourse/discourse-yearly-review.git", "git clone https://0fa273b19b56a1a58c41484d49a01d99f1b5b8d2@github.com/mentalstring/custom-username-validator", "git clone https://github.com/discourse/discourse-saved-searches"]}
bootstrap failed with exit code 128
---
HINT: The plugin 'discourse-cakeday' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-cakeday' from your containers/web_only.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
app.ymlにプラグインを再追加すると、上記のようになります。すぐに削除するとビルドは再び機能します。このプラグインだけが問題のようです。
バージョンが古いことは承知しており、アップグレードはロードマップ上にあります。ただし、実行しているバージョンを変更していないにもかかわらず、3.5.4が（プラグインありで）正常にビルドされていた状態から、プラグインありではビルドできなくなり、プラグイン経由でもコア経由でもプラグインの機能を取り戻す方法がないように見えることを指摘しておきたいだけです。
「いいね！」 1
興味深いですね！私たちのDockerイメージにdiscourse-cakedayが含まれるようになり、コアが3.5に「ダウングレード」されたときに空のディレクトリが残されるためかもしれません。
git clone https://.../discourse-cakeday行の前にrm -rf discourse-cakedayを追加すると、それがクリーンアップされるはずです。したがって、次のようになります。
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- rm -rf discourse-cakeday
- git clone https://github.com/discourse/discourse-cakeday
「いいね！」 4
はい、うまくいきました。再び動作するようになりました。ありがとうございます！
「いいね！」 2
少し脱線してしまい申し訳ありませんが、これ以上適切なトピックはないと思いますし、以前の問題とも多少関連しています。
前回のメッセージ以降、discourse/docker_managerでさらに変更が加えられ、古いバージョンのビルドでさらに多くの問題が発生していると思われます。今日の再ビルド後、以下のようなエラーが出て、Discourseの管理セクション全体が動作しなくなりました。
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/admin/models/admin-plugin` imported from `discourse/plugins/docker_manager/discourse/models/repo`
ymlで以下を使用することで、ビルドを修正することができました。
- git clone https://github.com/discourse/docker_manager.git && cd docker_manager && git reset --hard 314bbd78c200860c76bb62ced65b40e7cde5aa02 && cd ..
どれが問題のあるコミットだったのかは不明ですが、これで再び動作するようになりました。
分かっています、分かっています、アップグレードしなければなりません（本気です）。しかし、何らかの理由で計画よりも長く古いバージョンに留まらざるを得ない私達のような人は他にもいるでしょうし、バージョンを変更せずに古いビルドが壊れるのは少し予期せぬことです。
とにかく、アップグレードするまでの回避策は見つかったので、同じ状況にある他の人々の役に立つかもしれないと思い、共有しておきます。
「いいね！」 1
Discourseコアのバージョンはどれですか？まだ3.5ですか？
はい、3.5.4です。近いうちにアップグレードしたいと思っています。
「いいね！」 1