Discourseコアに人気のプラグインをさらに同梱

今後数週間かけて、多くの人気のDiscourseプラグインをコアリポジトリに移行します。これにより、Discourseにはデフォルトでより多くのプラグインが含まれるようになり、それらをすべてテストして最新の状態に保つことが容易になります。

これらのプラグインはすべてデフォルトで無効のままなので、既存のコミュニティに目に見える影響はありません。discourse.orgのようなマネージドホスティングサービスを使用している場合は、何もする必要はありません。

セルフホスト型コミュニティ

Discourseをセルフホストしており、これらのプラグインのいずれかを既に使用している場合は、次の再構築の前にapp.ymlファイルから関連する行を削除するように求められます。

開発環境

ローカルでプラグインのいずれかを既にインストールしていて、Discourseコアの最新バージョンをプルした場合、次のいずれかの状況が発生します。

  1. プラグインにシンボリックリンクを使用している場合、git pull中にエラーが発生します。問題を解決するには、シンボリックリンクを削除してから、git pullを再度実行してください。

  2. プラグインを直接クローンしている場合、コアのgit pullは成功しますが、ネストされたgitリポジトリによって予期しない「ステージングされていない変更」が発生します。これを解決する最善の方法は、影響を受けるディレクトリを削除してから、mainからrestoreすることです。例:

    rm -rf plugins/discourse-reactions
    git restore plugins/discourse-reactions
    

対象プラグイン

「いいね!」 65

最初の投稿で完全な HINT 行を提供していただきありがとうございます。これにより、今朝のビルドの失敗を診断できました :blush:

「いいね!」 17

ありがとうございます。開発やプログラミングに関する知識が乏しいのですが、それでも質問させてください。本来は基本的なインストールに追加されるコンポーネントであるこれらのプラグインは、将来的にプラグインとしての性格を失い、まったくプラグインと呼ばれずに基本的なインストールの一部となることはありますか?

「いいね!」 3

はい、そうなる可能性があります。特に、認証プラグイン(例:apple-auth)は、他の組み込み認証方法(例:Google、Facebookなど)と同様に、コアに吸収される可能性が非常に高いです。

「いいね!」 3

デフォルトでさらに多くのディスコースを準備し、新しいインストールを容易にする興味深い動きです。

次のことに関する質問が1つあります。

次の再構築の前に、app.yml ファイルから関連する行を削除するように求められます。

管理者のアップグレードページからアップグレードボタンをクリックする前/ときに、プロンプトまたは警告メッセージも表示されますか?

「いいね!」 3

私の経験から記憶している限りでは、最初にdockerをアップデートできるようになります。dockerをアップデートすると、コマンドラインからアップデートする必要があること、およびその方法を説明するメッセージがアップデートUIに表示されます。

その後、コマンドラインでアップデートすると、上記の最初の投稿で説明したように、app.ymlから削除する必要がある各プラグインのHINTが表示されます。

「いいね!」 4

これは良いアップデートですが、本当に必要でしたか? 再構築の失敗は少し厳しすぎると感じます。UIの警告や自動更新(または完全に無視すること)の方が、「今すぐ削除しろ」と銃を突きつけられるより良かったでしょう。

「いいね!」 6

これは先週、コマンドラインからアップデートしようとして失敗したとき(reactions プラグイン)に引っかかりました。

今朝、コマンドラインからのアップデートが再び失敗したとき(data explorer プラグイン)にも引っかかりました。

アップデートプロセスが開始される前に、コマンドラインで警告が表示されることを強く希望します。その後、必然的に失敗します。

わずか 2 週間で 2 回もアップデートが失敗し、問題のデバッグ、設定の編集、再試行などに費やす時間の間、すべてが壊れているため、軽いパニック状態になりながら、Discourse がオフラインになりました。

「いいね!」 8

別の問題があります。

Gemの依存関係。

冗長なプラグインのクローンを削除するだけではありません。

Gemのバージョン競合の問題もあります。

コアプラグインが大幅に遅れているため、私のプラグインのいくつかで特定の依存関係をダウングレードするプロセスを実行しています。

したがって、この動きは不必要に依存関係を追加し、再構築をより壊れやすくすると私は思います。

「いいね!」 3

2件の投稿が新しいトピックに分割されました:プラグインページへの改善提案、コアにバンドルされるプラグインが増えたため

まもなく追随する動きは、コアプラグインからgemラインを削除し、モノリスgemファイルに移行することです。

「いいね!」 3

興味があるのですが、このプラグインリストは実際のDiscourseのインストールから取得したのですか?私のメインのインストールのほぼ50%と一致しています!

「いいね!」 2

これらのプラグインをすべてコアにバンドルすると、フォーラムが肥大化するのではないかと疑問に思っています。たとえば、管理者がフォーラムに含めたくないプラグイン(例:Discourse AI)があるかもしれませんが、追加するしか選択肢がないでしょう。もちろん無効にすることはできますが、追加されたファイルなどがフォーラムを遅くするのではないかと疑問に思っています。

「いいね!」 2

クライアント側では、Discourse は無効化されたプラグインの JavaScript アセットを提供しないため、そこへの影響はありません。

サーバー側では、適切に実装されたプラグイン(これらはすべて該当します)の場合、無効化されているプラグインのカスタマイズはバイパスされます。したがって、技術的には有効/無効の状態を確認するためのわずかなオーバーヘッドがあるかもしれませんが、それはごくわずかであるはずです。

ここでマージしているプラグインは、discourse.org ホスティング上のすべての Discourse インスタンスで実行しているものです。そのため、すべて大規模で十分にテストされています。

「いいね!」 15

承知いたしました。明確にしていただきありがとうございます!

「いいね!」 2

リリース直前にすべてを一度に行う理由があるのでしょうか?空き時間にこれを行う翻訳者にとって、2週間で3,000件の追加文字列はかなりの量です。また、以前にプラグインが翻訳されていた言語であっても、3,000件すべてのテキストを再度校正する必要があります。時々、3,000件よりも300件の方が管理しやすいでしょう。

「いいね!」 6

For self-hosted communities already running one or more of these plugins, will the plugins lose config data when removed from app.yml and folded into core?

I’ve got the AI plugin set up exactly how I want it; if I need to reconfigure it (or at least write down the config options so I can re-add them), it’d be nice to know now. :+1:

すでにこれらのプラグインのいずれか、または複数を実行しているセルフホスト型コミュニティでは、プラグインが app.yml から削除されてコアに統合される際に設定データが失われますか?

AI プラグインは希望どおりに設定されています。再設定する必要がある場合(または少なくとも再追加できるように設定オプションを書き留める必要がある場合)は、今知っておくと便利です。:+1:

「いいね!」 6

Crowdinの翻訳メモリを活用することで、翻訳者がゼロから翻訳し直す必要がないように、できる限りスムーズに進められるように努めてきました。しかし、それでも校正すべきものは多いという点には同意します。

ここでさらに自動化できることはないかと思っています。例えば、プルーフリードを必要とせずに、これらのプラグインからの文字列を「自動承認」できるかもしれませんね :eyes:

すべて設定/データは維持されます。

「いいね!」 10

UI に表示される、失敗することがわかっている再構築を促すメッセージは、実に洗練されていないと感じました。

少なくとも、最小限の Docker マネージャーバージョンを実行しているサイトのこのトピックにフラグを立てる方法はありませんでしたか?

「いいね!」 2

このメタトピックは、実際には見たくないものでしょう。

難しさがあるのは、app.ymlからどのプラグインを削除すべきで、どれを削除すべきでないかを知ることです。