kgrier
(Kirk Grier)
80
Discourseのセルフホスティングで初期に「プラグインの再構築に失敗した」という問題に遭遇した経験から、既知の良いバージョンをコアにバンドルすること、そして潜在的により豊富な機能を提供することの重要性は理解できます。
顧客中心の組織であれば、コアプラグインの方向性、あるいは少なくともそのタイミングについてアンケートを取ったかもしれません。私がそれに気づかなかっただけかもしれませんが。ITツールプロバイダーとして、顧客（つまりエンドユーザー）がITを使って実際の作業をこなせるように支援する中で、多くの製品が過剰な複雑さへと改訂され、最終的に置き換えられていくのを見てきました。今やセルフホスティング者は必要のないプラグインを「rm -fr」することになるでしょう。それは理解できますし、私もその仲間入りをするかもしれません。私の経験では、追加のコードは統合の複雑さ、設定ミスのリスク、そして攻撃対象領域を増加させます。しかし、遅かれ早かれ、アプリ開発者が存在する前提としているものを削除することは、何かを壊すことにもつながります。
Discourseのジェダイたちの努力が、CDN統合を含む画像のための堅牢で維持管理されたスクリプト化されたクラウドストレージ方法の開発に向けられていれば、もっと良かったと思います。SMTPメール統合はそれに比べれば些細なものであり、それはMailGunなどでの変更によって壊れ、セルフホスティングサイトに苦痛をもたらしました。
david
(David Taylor)
81
確かに、これらのプラグインで rm -rf を使用することは強くお勧めしません。おっしゃるように、将来予期しない相互依存関係のリスクがあります。しかし、コア git リポジトリに差分が生じるため、docker_manager を介した UI 更新はほぼ確実に失敗します。
もちろん、これらのプラグインをデフォルトの「無効」状態のままにしておくことは完全にサポートされており、測定可能なパフォーマンスへの影響がないことを保証します。
「いいね！」 8
プラグインディレクトリ内に存在していても、プラグインが見つからないように除外する方法が必要です。
「いいね！」 2
セルフホスティング利用者や、私のように顧客にホスティングサービスを提供している方のために、新しいバンドルプラグインのいずれかが既に containers/app.yml に存在するかどうかをリストする簡単な grep を紹介します。
grep -E 'git clone .*(discourse-(adplugin|affiliate|ai|apple-auth|assign|calendar|chat-integration|data-explorer|gamification|github|graphviz|hcaptcha|login-with-amazon|lti|math|microsoft-auth|oauth2-basic|openid-connect|patreon|policy|post-voting|reactions|rss-polling|solved|subscriptions|templates|topic-voting|user-notes|zendesk-plugin|cakeday))' containers/app.yml
root として実行する必要があり、再構築する前に app.yml のプラグインセクションから手動で削除する必要がある行が出力されます。
「いいね！」 9
mcdanlj
(Michael K Johnson)
84
@pacharanero ありがとうございます！
containers.*.yml を参照するように変更することを検討してみてはいかがでしょうか。これにより、標準的な 2 コンテナのインストールを行った人も、代わりに web-only にいる場合でも役立ちます。結局のところ、コンテナ定義に含めたくないはずです。
@david cakeday を統合したら、これを最初の投稿に追加して維持することを検討していただけますか？
「いいね！」 2
このプロンプトから一度で正確に作成してくれたChatGPTに感謝します。
この投稿で言及されている各プラグインのGitHub URLをスクレイピングしてください
https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574#p-1810533-affected-plugins-3
それらをリストにまとめ、そのDiscourseのcontainers/app.ymlで「git clone」ですでに言及されているプラグインがあるかどうかを教えてくれるUnixコマンドを作成してください。
「いいね！」 3
mcwumbly
(Dave McClure)
86
表面的には、これはいつか検討すべき妥当なことのように思えます。たとえソースがディスク上に残っていても、起動時にどのプラグインがロードされるかされないかをより宣言的に定義する方法を持つことです。
とはいえ、それがどれほど実現可能か、あるいはどれほどの労力がかかるかはわかりません。
「いいね！」 3
david
(David Taylor)
87
確かに可能です。しかし、サポートや保守が必要なものが増え、複雑さが増します。また、シングルテナント環境（つまり、異なるテナントが異なるプラグインを望む共有ホスティング環境ではない）でのみ役立ちます。
むしろ、「無効化された」プラグインのUXとパフォーマンスを改善することに時間を費やす方が有益だと考えます（この大きなコアへのマージ以降、すでに着手しています）。
「いいね！」 10
Ethsim2
(Ethan )
88
また、プラグインを削除しようとしたこともありません。なぜなら、共有ホスティングのインストールを試みるのと同じように、メタへのバグレポートを危険にさらす可能性があると感じているからです。
「いいね！」 2
うーん、大変なアップデートでした。まず、再構築ログの混乱の中から問題を見つけるのは簡単ではありませんでした。見つけました。設定から削除すべき別のプラグインを見落としていたため、3回目の再構築でようやくその部分を通過しました。最初に設定の調整が必要であることを確認し、警告を発してくれていれば本当に助かったのですが。discourse-doctor は設定内のプラグインをチェックします（単純すぎますが、開始点として使用できます）ので、それを基盤として使用できます。3週間も経ってしまった今となっては遅すぎるかもしれませんが…。
しかし、それだけではありませんでした。db:migrate のエラーにも遭遇しました。2回再試行した後、discourse-doctor を実行したところ、再構築も実行され、奇妙なことに成功しました。そのコードを確認しましたが、何もしておらず、私たちが再構築を呼び出すのと同じ方法で呼び出しています。したがって、何らかの理由で3回目の試行で db:migrate が成功したように見えますか？他の人が必要としたような手動のプラグイン削除手順、依存関係の調整、またはデータベースの変更を必要としなかったのは幸運でした。db:migrate を複数回実行すると、最終的に成功するようになるということは期待されていますか？何も壊れていないことを願うばかりです…。
「いいね！」 2
sam
(Sam Saffron)
90
以前からインストールされていましたが、以前のバンドルされたプラグインの残りの部分とともにUIからは省略されていました。UIが改善され、存在するすべてのものが適切に表示されるようになりました。（CSSで非表示にされていたChatなど、多くのものが省略されていました）
これが導入されてから非常に短期間で、内部開発チームのベロシティが増加したことをすでに実感しています。より安定した製品につながっており、非常に満足しています。
後戻りする計画はありません。新しい世界に適応する必要があります。
「いいね！」 4
sam
(Sam Saffron)
このトピックを分割しました:
91
3件の投稿が新しいトピックに分割されました：ヘルプミーデバッグ失敗したマイグレーション
IMO、プラグインがインストールされていないために何か問題が発生した場合、それ自体がバグです。コアはプラグインに依存すべきではありません。プラグイン自体は、それぞれのページで要件を明確にリストする必要があります。
しかし、はい、これはセルフホスト版を今後さらに不安定にするでしょう。セルフホスターがこれらの問題につまずくことになるからです。これとフォークされたスレッドの間で、セルフホスターの安定性がチームにとって高い優先事項であるという印象は本当に受けられません。
「いいね！」 2
gerhard
(Gerhard Schlager)
94
事前にそのことを考えていなかったため、承認の一部が欠落している可能性があります。しかし、Crowdin のプラグイン プロジェクトからコアにかなりの部分を移行することができました。プロジェクト間で承認を移行するためのツールができたので、次回はもっとうまくやります。
いいえ、事前に確認しませんでしたが、後で確認しました。プラグインに Crowdin で未回答のコメントはありませんでした。Crowdin のプラグインに投稿されたすべてのコメントを保存する内部ツールがあります。例えば、Crowdin がソース文字列が更新されたためにコメントを削除した場合に、欠落したコメントを Crowdin に再度投稿するためにも使用できます。ただ、これを実装することは優先順位が高くありませんでした。
「いいね！」 6
ここにさらにオプションがあると非常に便利です。
「有効なプラグイン」
これにより、「インストール済みプラグイン」の最初の巨大なリストを回避できます。
また、これを容易にするために：
- プラグインセクションにカスタムリンクを許可する（おそらく）
- このドロップダウンがルートパラメータフィルターに反応するようにする：
したがって：
https://example.com/admin/plugins?filter=enabled
「いいね！」 12
Heliosurge
(Dan DeMontmorency)
98
同意します。有効なコアインストール済みプラグインのリストを表示するオプションがあるかもしれません。すべてのプラグインを表示するのではなく。追加のフィルタリングオプションは間違いなく良いでしょう。
「いいね！」 1
Heliosurge
(Dan DeMontmorency)
99
その意見には同意します。Imho、本当の断絶は、それらをプラグインとしてリストし続けることです。
マージされたら、「コア機能」のようなブランド名に変更すべきです。プラグインは、インストールできるオプションコンポーネントと見なされるからです。メインプログラムの一部とは対照的です。したがって、アンインストールされることを意図していないのに、それらをプラグインとしてリストし続けるのは、不適切な名称だと思います。
テーマコンポーネントにリストされていない「パーソナルバブル」のような、コアにマージされたTCと同様です。確かに、その特定のケースでは、以前のTCを無効にすることはできません。以前の状態に戻したい場合は、変更を元に戻すためにTCを作成する必要がありました 
Heliosurge
(Dan DeMontmorency)
100
これにより、「インストール済みプラグイン」の最初の巨大なリストを回避できます。
追加のフィルタリングオプションには間違いなく同意します。無効なプラグインのオプションも同様に。
しかし、さらに考え、より多くの投稿を読んだ後。プラグインがコアとマージされた場合。それらはもはやプラグインと呼ばれるべきではなく、プラグインにリストされるべきではありません。しかし、コア機能またはオプション機能のようなものかもしれません。これらはもはやアンインストールできるものではないため。
「いいね！」 1
適切に設計されたフォーラムソフトウェアは、実行するために広告コードを必要とする理由はありません。
Discourseがアンチ機能を組み込むことを決定した場合、人々が強制されるのは、Discourseをフォークするか、他のものに移行することだけです。ビッグテック/広告のようなものが好きではない私たちの一部は、これについて非常に強く感じています。Discourseは、どれだけ強くプッシュされても、私たちにそれを強制することはありません。（Ubuntuはこれを私たちに試しましたが、今では私の最もスターの多いリポジトリは広告を削除するものです。）
Heliosurge
(Dan DeMontmorency)
102
よくわかりません。広告コードとは、オプションのアドオン/インストールとして残すのではなく、コア製品に統合されたプラグインを意味しますか？もしそうなら、過去を振り返ると、さまざまな「広告コード」がコアに統合されていたことがわかります。
DeVチームの観点からは、多くのプラグインが、コアプログラムに統合する前に、より柔軟なテストを可能にするためにプラグインとして開始された可能性があります。
ソフトウェアと同様に、人々が使用しない機能を選択して無効にし、機能をアンインストールする方法を見つけることはよくあることだと理解できます。
最近統合されたプラグインの多くは、おそらく使用しないだろうと認めますが、単純に無効にしてフィルタリングすることは、すべての人にとって良いことです。
チームが述べているように、ホスト型システム向けのアドオンで物事を容易にすることが意図されていることは理解しています。
さて、私の意見では、管理インターフェイスは、かつてそうであったように、よりカスタマイズ可能であるべきです。これは、人々が別のプラットフォームから移行する際に、移行元のプラットフォームと同様のレイアウトの管理インターフェイスを読み込めるようにするのにも役立ちます。Linuxが他のOSを模倣することでこれを行うのと似ています。しかし、それは別のトピックです。
Discourseがブロートウェアに向かっているように感じていることは理解できます。Reactorは、Windows NTがいかに軽量になり得るかを示しました。
