エラーメッセージで reactions、data explorer、solved がまだ yml ファイルにあると表示される場合、それらは実際にある可能性が高いです。コメントアウトしたと思っても、二重に入力されている可能性はありませんか？
設定を確認し、サイトに対応する yml ファイルを編集したことを確認する価値は間違いなくあります。
「いいね！」 1
こんにちは
フォーラムを最新の 3.4.6 stable バージョンに正常にアップグレードしました。これまでは、認証のためにスタンドアロンの discourse-oauth2-basic プラグインを使用していました。
/admin/plugins に Oauth2 Basic ログインがありません。
私の Discourse のバージョンは 3.4.6 です。
ヒント: プラグイン「discourse-oauth2-basic」は現在 Discourse にバンドルされており、コンテナ構成に含めるべきではありません。
containers/app.yml ファイルから「git clone GitHub - discourse/discourse-oauth2-basic: A basic OAuth2 plugin for use with Discourse」の行を削除してから、もう一度試してください。
詳細については、Bundling more popular plugins with Discourse core を参照してください。
3.4.6 にアップグレードする前に、プラグイン discourse-oauth2-basic を削除する必要がありました。
何がうまくいかなかったのか、理解するのを手伝っていただけますか？
- プロセスを誤解していましたか？プラグインはまだ必要ですか？
- プラグインを削除した後、コアの OAuth2 機能 を有効にするために、見落とした追加の手順はありますか？
- それとも、単に設定を探す場所を間違っていますか？
ありがとうございます！
「いいね！」 1
うーん…安定版を使っているからではないでしょうか？
システムプロンプトに従い、discourse-oauth2-basic プラグインを削除した後、3.4.6 stable version へのアップグレードに成功しました。
しかし、現在、管理ダッシュボードから OAuth 2 Basic の設定オプションがなくなっていることが判明しました。
「いいね！」 1
もしあなたが安定版を使用している場合、8月初旬の次の安定版リリースまでは、このトピックのどれも適用されません。そのため、app.yml に oauth2-basic を戻す必要があります。元の障害は、他の理由によるものであったに違いありません。
残念ながら、「ヒント」ロジックはあまり賢くなく、安定版とテスト合格済みを認識していません。
「いいね！」 5
私もですが、これについて私たちに何ができるでしょうか？ lol ネイティブリソース、つまりプラグインを無効にしたとしても、セルフホスティングを始める初心者にとって良い解決策ではないと思います。
「いいね！」 2
@nat これを見て、私の引用文の翻訳と返信
「いいね！」 3
プラグインセクションのクローン行をコメントアウトしようとしましたが、プラグインをインストールしたいかのようにそれらの行を読み込んでいました。どうしてでしょうか？行を削除したら、最終的に機能しました。
アップグレードする際は、Discourseのコアに含まれるプラグインのリストを確認し、インストールするためにプラグインセクションに追加したり、app.ymlファイルにある場合はその行を削除したりしないようにする必要があります。
「いいね！」 2
これらはプリインストールされているため、インストール済みリストとは別にオプションを設けるべきだと思います。インストール済みリストは削除可能ですが、無効化しかできないものもあります。
おそらく、コアに統合されたプラグインは、「おすすめプラグイン」や「コアプラグイン」のようなものに分類されるべきでしょう。
もちろん、「すべて」のフィルターもあるかもしれません。
「いいね！」 2
彼らの提案は理想的ではありませんが、機能します。例：
## プラグインはここに追加します
## 詳細については https://meta.discourse.org/t/19157 を参照してください
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/pfaffman/discourse-allow-pm-to-staff.git
#- git clone https://github.com/discourse/discourse-hcaptcha.git
#- git clone https://github.com/discourse/discourse-calendar.git
- rm -rf discourse-adplugin
- rm -rf discourse-affiliate
- rm -rf discourse-ai
- rm -rf discourse-apple-auth
- rm -rf discourse-assign
- rm -rf discourse-login-with-amazon
- rm -rf discourse-lti
- rm -rf discourse-microsoft-auth
- rm -rf discourse-patreon
- rm -rf discourse-subscriptions
- rm -rf discourse-zendesk-plugin
（必要に応じて調整してください）
「いいね！」 6
7件の投稿が新しいトピックに分割されました：Discourseでのブートストラップの失敗のトラブルシューティング
実際には、安定版ブランチはLTSであり、かなり良好なLTSでもあります。セキュリティアップデートを受け取り、どのプラグインバージョンが互換性があるかが（.discourse-compatibilityファイルのおかげで）非常に明確です。これらすべてが機能するようになるまでには長い時間がかかったことは完全に認めますが、過去2年ほどで実現しました。これはチームによる素晴らしい成果です。
次に、あなたの発言の後半部分についてです。確かに、stableはしばしば望むべきではないものとして表現されています。しかし、Communiteqホスティングでは、過去2年半にわたり、クライアントに安定版（「安定性第一、年に2回の新しいアップデート、月に1回のセキュリティアップデート」）とテスト済み（「常に最先端、月に1回の新機能」）のいずれかを選択する無料の選択肢を提供しており、85%が安定版を選択しています。
理解しています。しかし、それは本番環境の問題ではなく、開発の問題ではありませんか？開発においてはそれを行っていることは完全に理解できます。しかし、デフォルトの本番環境インストールにこれらのプラグインを追加することは、プラグイン（定義上、デフォルトではないもの）を持つという考え方を基本的に無効にします。
私が実際に認識している唯一の本番環境の利点は、プラグインのアンインストールとマルチサイトホストという、非常に、非常にエッジな問題です。（繰り返しますが、これは良いことです。他のすべて本番環境の問題は時間とともに解決されました！）
それはセットアップスクリプトで、ユーザーがチェックできるプラグインのリストを表示し、それらをapp.ymlに追加することで解決することもできたはずです。
しかし、あなたはまだ異なるティアに対して異なる（サブ）セットのプラグインを提供しているのですよね？
「いいね！」 6
私もアプリ.ymlのコメント解除アプローチを好みます。
「いいね！」 1
これらのプラグインはすべて、セルフサービスプランにインストールされています。一部のティアではアクセスできませんが、アクセスできなくてもインストールされたままです。
この決定は変更しませんので、人々はこれを受け入れるしかありません。一部の人々が動揺していること、これに反対していることは理解していますが、これは単に変更されません。
これにより、開発中の速度が向上し、私たちの好みが定義され、大多数の人々が使用しているDiscourseがより安定することが保証されます。
他のプラグインもあります…コアプラグインだけがプラグインではありません。
「いいね！」 5
投稿が新しいトピックに分割されました：Discourse does not ship an LTS release
人気のプラグインとその機能をコアイメージに移行するのは理にかなっていると、私も完全に同意します。特に、それらがコア自体と同じコーダー（CDCK）から提供されている場合はなおさらです。これは他のソフトウェアプロジェクトでも一般的なプラクティスです。しかし、ブートストラップの問題を解決する必要があります。私はまだ楽観的です:sunny:
「いいね！」 1
再建できない理由です。
こちらの方が間違いなく良い方法でしょう。前の投稿のプラグイン削除コードを使用して実装することも可能です。
インストールスクリプトにそれを追加すると、最初からより良いオプションが得られ、プログラムでオプション機能をインストールするかどうかを選択できるのは一般的です。
互換性ファイルは素晴らしいです。ただし、私の意見では、互換性情報はトピックに追加されるべきです。TC/プラグインが Stable と Tests-passed の両方のインストール手順で利用可能かどうかを示すリンクまたは手順とともに。
「いいね！」 1
ガイドをありがとうございます。これは「automation」プラグインを除いてうまく機能しますが、チャットプラグインがそれに依存しているように見えるため、削除できません。
「いいね！」 1
オートメーションプラグインは、率直に言って削除されるべきではないものです。非常に多くの便利な潜在的な用途があります。より多くの自動化オプションを得るためには、私の意見では、より多くの時間を投資する必要があります。
しかし、RGJが指摘したように、最近本当に余分なものがマージされたアドオンを削除することによって、整理整頓するオプションがあるのはクールです。これらのオプションをインストールしたいかどうかは疑問視されるかもしれません。インストール後に別のスクリプトを作成して、セルフホストにとってより使いやすくすることもできます。これにより、app.ymlを編集する必要を避けたい人もいるかもしれません。