このプロンプトは表示されませんでした。しかし、エラーログに従って行を削除しました。現在、再構築中です。
編集:破損を導入し、20分間オフラインにしたことを除けば、アップグレード前にこれらのプラグイン行を削除しない場合、プリインストールされたプラグインのこの追加された肥大化は本当に必要なのでしょうか?
全体像について興味があります。これらのプラグインをデフォルトでバンドルする理由は何ですか?
個人的には、Windows、モバイルOS、および一部のソフトウェアがデフォルトでプリインストールされたコンポーネントを増やす(BLOAT)という方向性に似ているように感じます。これは、多くの人が一般的に避けようとすることです。
この変更は、実装される前にコミュニティと議論されたことと思います。もしそうであれば、繰り返し返信する必要はありません。関連する議論や発表へのリンクを含めていただければ、この決定がどのように、そしてなぜ行われたのかを読むことができます。
皆さん、ありがとう!
「いいね!」 1
Moin
104
このトピックなので、おそらくすでに読んでいると思いますが:
「いいね!」 1
より一般的なプラグインをバンドルすることで、より多くのサイトが独自のJSをコンパイルする必要がなくなるという利点を享受できるようになり、ビルド時間とリソースコストが削減されます。
「いいね!」 5
セルフホストで、デフォルトのインストールです。
バンドルされたプラグインをいくつか使用しているため、まだアップグレードボタンをタップしていません。怖くはありません。数ヶ月前のDBアップグレードも乗り越えました。
app.yml を op のリストから更新する方が良いですか(もちろんバックアップしてから)、それともUIに意味のあるエラーメッセージが表示されて、削除して停止すべきものがわかるのでしょうか?
「いいね!」 1
再構築する前に app.yml から削除する必要があるプラグインをリストするには、この grep を使用できます。
このプラグインの更新後、この方法で Discourse をすべて再構築しましたが、失敗はありませんでした。
「いいね!」 2
Heliosurge
(Dan DeMontmorency)
109
それはトピックのタイトルで答えられています。人気があるということは、一般的にインストールされて使用されていることを意味します。セルフヒップスターのためにそれらをバンドルすることは、インストールに時間をかける必要がないことを意味します。多くのプラグインとTCは、最終的にコアプログラムにマージされました。
これらをプラグインとして開始することの利点は、開発者が消費者の好みをテストし、それらを完全に開発するための時間を得られることです。
確かに、新しくバンドルされたコアを使用しないさまざまなコミュニティがあるでしょう。しかし、より大きな指標は、これらがセットアップ後にインストールされることが多いことを示している可能性が高いです。そして、もちろん、彼らはまた、ベースティアで使用されたプラグインと使用されなかったプラグインの有料ホスティングからの指標も持っています。
再構築前に2つのプラグインを見逃しました。しかし、エラーログは、以前は上にスクロールして問題を確認する必要があったのに比べて、これを簡単に特定できるように大幅に改善されました。
Davidが言及したプロンプトは、再構築エラーであるか、Web更新用のプラグインページにあるかのどちらかだと思います。
「いいね!」 1
Heliosurge
(Dan DeMontmorency)
110
心配いりません。質問を投稿する前に答えを見つけるのは、いつも簡単ではありません。
私もapp.ymlを更新しました。
コメントを使用して、プラグインプロバイダーごとに整理し、並べ替えやすくしました。とはいえ、それでも少し面倒でした。数投稿前に、再構築する前にチェックする方法を投稿した人がいたと思います。
「いいね!」 2
ダン、ありがとうございます。app.ymlを編集します。
「いいね!」 1
正直なところ、これは告知スレッドだったので、ここにきてコメントを始めました。アップデートが失敗し、最初に編集する必要があるという通知を受け取らなかったからです。その後、それが解決されたら投稿を編集しました。しかし、これが唯一の公開ディスカッションであれば、感謝します。
利点は理解できますが、欠点も間違いなくあります。そのため、すべてのDiscourseフォーラムオーナーがプラグインに賛成するとは限りません。そのため、オプションとして提供できればよかったと思います。アップデート中に単一のプロンプトを表示するか、管理エリアの設定または通知で、次のアップデートの前に好みを設定するようにリマインダーを表示するなどです。
日付別に組み込まれたプラグインを一覧表示するページはありますか?Web管理画面からアップグレードして失敗するのが好きではありません。私は3.5.0.beta9-dev(04dbc622ab)を使用しています。
おそらく、アップデートがインストールされた日付/バージョンが記載されたページを見落としていたのかもしれません。よろしくお願いします。
「いいね!」 1
Discourse リポジトリの plugins ディレクトリを確認できます。
私の見たところでは、ここから始まるようです。
その多くは、このページにもあります。
「いいね!」 1
Moin
115
これはどのように機能しますか?デフォルトで有効になっているように見えます。
「いいね!」 1
おそらく、それらが最も人気のあるプラグインであり、ほとんどの人がすでにそれらのいくつかを組み合わせて使用している(あなた自身もそうである)という考えです。それらは実際には「ブロート」ではありません。なぜなら、それらはほとんどフットプリントがなく、あなたがそれらのどれも使用する必要がないからです。これは、私が望まない20個のプログラムがWindowsにインストールされているのとは大きく異なります。これらはオン/オフのトグルであり(ほとんどの人は見ることがなく、管理者であるあなたも、あなたがすでに使用していない/変更していない300の他のもののリストにあります)、常に表示されたり、実際のスペースを占有したり、デフォルトで何かを実行するように設定されたりするものではありません。私が望まないメモ帳プログラムがデフォルトでインストールされているということは、私が2つ持つことになるということです。私が望まないプラグインがあるということは、パネルにオプションが座っているだけということです。
また、サードパーティのフォーラム(または無限のGitHub)を検索して、そもそも存在すら知らないものを探すよりも、オン/オフスイッチがある方がはるかに簡単です。実際に、これらのうちのいくつかが存在することに初めて気づきました。
「いいね!」 5
3.5.0.beta9-dev (df03ef6d05)にようやくアップデートする時間が取れました。
セルフホストの標準インストールです。
プラグインの行を削除するようにapp.ymlを編集しました(上記のDanのアドバイス通り)。その後、アップデートプロセスを開始しました。いつものように、まずDockerマネージャーをアップデートする必要がありましたが、それは正常に完了しました。Dockerマネージャーがアップデートされると、新しい(私にとっては)メッセージが表示されました。
以前に再構築を行ったことがあったので、やり方はわかっていましたし、Puttyはまだサーバーに開いていたので不便はありませんでしたが、UIでアップデートできなかったことには少し驚きました。私のようなセルフホスト初心者の皆さんのために、注意喚起として投稿しています。それ以外は、アップデートは順調に進み、すべてが実行され、機能しています。チームとコミュニティに感謝します。
「いいね!」 3
david
(David Taylor)
119
solved、topic-voting、templatesについては、プラグイン自体は有効になっています。しかし、これらのプラグインは、特定のカテゴリで機能が有効にならない限り、何も行いません。
「いいね!」 4
互換性の維持にもっと配慮し、サイトを更新するたびに半日を無駄にさせないでほしいです。コードを少し整理するだけで、人々のサイトを壊したり、時間を無駄にしたりする価値はありません。
率直に言って、数ヶ月ごとにサイト全体が壊れ、私の専門分野ではないことを修正する方法を見つけなければならないことにうんざりしているので、Discourseの代替を探し始めています。
ご不便をおかけして申し訳ありません。バンドルされたプラグインで具体的にどのような問題が発生したのか分かりかねますが、
アップグレードをできる限り簡単かつ直接的に行うよう努めておりますが、このような大きな変更の場合、どうしても多少の摩擦が生じることは避けられません。今回は、サイトの設定を変更する方法に関する具体的なエラー出力を追加し、修正を可能な限り簡単にするようにしました。
「いいね!」 3
pfaffman
(Jay Pfaffman)
131
Discourse_docker はコマンドラインでの再構築が必要なタイミングを把握するのがあまり得意ではないという問題があると思います。そのため、管理パネルでアップグレードをクリックするだけでサイトを壊してしまう可能性があります。(少なくとも、人々が不満を言っているのはそのように見えます。)
以前はそれを行うコミットを見たことがあったと思いますが、今はそれほど見ていないと思います。私は自分で discourse_docker を(あまり)使用していないので、注意深く見ていません。
もしこのユーザーが UX からのアップグレードではなく再構築を実行していれば、次のようなことを行うだけで済みました。
./launcher start app
そして、都合の良い時にアップグレードの処理を待つことができました。
「いいね!」 5