WordPressの古いバージョンを4.7に自動更新する提案
公開: 2019-08-09WordPressの寄稿者、開発者、およびコミュニティメンバーは、現在、古いバージョンのセキュリティサポートに関する新しいポリシーを実装する提案について議論しています。 先週、セキュリティチームのリーダーであるJake Spurlockが、セキュリティ修正を古いバージョンにバックポートするためのさまざまなアプローチについてフィードバックを求めたときに、議論が始まりました。 この議論に続いて、Automatticが後援するWordPressコアへのフルタイムの貢献者であるIan Dunnは、新しいポリシーを進めるための提案を発表しました。
最新の6バージョンをサポートし、サポートされていないサイトをサポートされている最も古いバージョンに自動更新します。
つまり、現在サポートされているバージョンは4.7 – 5.2であり、3.7 –4.6ブランチは最終的に4.7に自動更新されます。
実際には、各ブランチに約2年間のサポートが提供され、現在のサイトの約10%が最終的に4.7に自動更新されます。 5.3がリリースされると、サポートされている最も古いバージョンは4.8になります。
Dunnは、サイトの小さなサブセットをテストして問題を特定してから、古いサイトをあるメジャーバージョンから次のメジャーバージョンに徐々に更新する(一度にすべてではない)ことを含む、新しいポリシーを実装するための詳細な計画の概要を説明しました。 サイト管理者は、自動更新の少なくとも30日前に、オプトアウトする機会を提供する管理者の電子メールと通知で通知されます。
この提案には数十のコメントが寄せられており、一部の寄稿者は支持し、一部はロールアウトの変更に賛成し、その他は古いサイトをメジャーバージョンに自動更新するという考えに明確に反対しています。
一般的な懸念事項の1つは、電子メールアドレスが機能していないか、管理ダッシュボードに十分な頻度でログインしていないために、多くの管理者が通知を受け取らないことです。 反対派はまた、アップグレードに失敗したサイトのフォールバックがあるとしても、プラグインやテーマの問題のために、WordPressが検出できない方法で壊れている可能性があると主張しています。
「バックエンド通知は、信頼できる電子メール通信の欠如を補うことすらできません」と、GlennMessersmith氏は述べています。 「サイトが開発された後は、バックエンドに踏み込むことのないサイト所有者がたくさんいます。 これらは、電子メールアドレスが長年の開発者のものであるために電子メール通知を受け取らないまさにその人々です。
「いかなる種類のエラー検出も、通知を見たことがない人のためのセーフティネットとして機能する方法はありません。 サイトの所有者が自分のサイトを「壊れている」と見なす可能性のあるさまざまな方法がありますが、更新スクリプトでは検出できなかった可能性があります。」
放棄されたサイトが壊れたり、管理者が放棄されたプラグインに大きく依存したりすることへの懸念に応えて、ダンは、現在の提案ではこれらのタイプの状況が避けられない可能性があることに同意しました。
「私は間違いなくその状況に共感することができますが、どこかに線を引く必要があります」とダンは言いました。 「私たちには無制限のリソースはありません。現在のポリシーは、WordPressエコシステム全体に悪影響を及ぼします。
「実際には、選択は純粋に良いことと純粋に悪いことの間では決してありません。 それらは常に競合するトレードオフの間にあります。
「少数のサイト所有者がサイトをアップグレードするために余分な作業をしなければならないのは悪いことですが、壮大な計画では、セキュリティチームが非常に面倒なサポートポリシーによって妨げられるよりもはるかに優れています。 。」
提案者は、「誰も更新を強制されることはないだろう」と主張しています。 反対派は、ユーザーにオプトアウトを要求することは同意ではないと主張します
サイトを壊す可能性があるという問題に加えて、提案に反対する人々は、サイト管理者からの明示的な同意を得ずに更新を強制するWordPressに参加していません。 メジャーコアリリースの自動更新をオプトインする方法をユーザーに提供することは、Matt Mullenwegが2019年に取り組むことを特定した9つのプロジェクトの1つです。ただし、この提案の計画は、3.7のサイト所有者を必要とするという点でより積極的です。 – 4.6ブランチは、4.7に段階的に自動更新されたくない場合にオプトアウトします。
「彼らは何があっても代理店を維持し、誰も更新を余儀なくされることはなく、誰もが自分のサイトを管理し続け、必要に応じてオプトアウトすることができます」とダン氏は述べています。 「デフォルトでオンになっているものは、誰かに何かを強制することとは大きく異なります。 オプトアウトを非常に簡単にします—プラグインをインストールするだけで、設定は必要ありません—オプトアウトの手順は、すべての電子メールと管理者への通知に含まれます。」
Dunnは、これらの更新を誰が受け取るかに関するコメントでさらに明確にしました。
強制されることはなく、代わりにオプトアウトプロセスになります。 誰かがすでにメジャーバージョンへの自動更新を無効にしている場合、それは尊重され、そのサイトは更新されません。
誰かが電子メールのオプトアウトリンクをクリックした場合、または管理者通知のオプトアウトボタンをクリックした場合、更新も無効になります。
アップデートを受け取るのは、次の人だけです。
1)アップデートが欲しい
2)気にしない
3)サイトまたは電子メールアカウントを放棄しました
ディスカッションの何人かの参加者は、4.7でこれらのサイトを取得するプロセスが、オプトアウトしない人に更新を強制するのではなく、同意をオプトインできない理由を尋ねました。 オプトアウトメカニズムがどれほど便利であっても、オプトアウトメカニズムを導入しても同意にはなりません。 このプロセスを余儀なくされる多くのサイト所有者は、3.7リリースの投稿で機能が説明されているように、メンテナンスとセキュリティの更新を選択し、サイトを離れて「スリープ中に更新」を実行しても安全だと考えていました。
「安全でないサイトは悪いですが、間違いなく、このメカニズムによって自分に与えられた力を遡及的に拡大することはもっと悪いことです」と、UpdraftPlusの作成者であるDavidAndersonは言いました。 「潜在的に、それは不安よりも信頼と評判を損なう可能性があります。 私は、巨大なダッシュボードの醜い、削除できない古いバージョンの通知が、今後の放棄と更新の必要性を警告する方が良いと主張します。 サイトの所有者に責任を負わせます。 乳母を演じたり、信頼を乱用したり、サイトを壊したりして、巻き添え被害がどのように必要だったかについてブログに投稿しないでください。 壊れた場所に目覚めた人は誰もそれに満足しません。」

WordPress 3.7のリリースリーダーであり、WordPressの自動バックグラウンド更新機能の共著者であるAndrew Nacinは、提案の背後にいる人々に、WordPressは最新のメジャーバージョンのみをサポートし、古いバージョンを公式にサポートしたことはないことを明確にするよう促しました。
「確かに、バックポートするには多くの作業が必要です」とNacin氏は述べています。 「しかし、WordPressはバージョン間で下位互換性があり、WordPressユーザーは実行中のバージョンについて心配する必要はなく、サイトを最新の状態に保つ必要があるということです。我々はできます。"
Nacinは、自動更新を導入するための元の戦略についてより多くのコンテキストを提供しました。これには、自動更新としてメジャーリリースを段階的に移行し、すべてのサイトが最終的に最新バージョンになるようにすることが含まれます。
まず、自動バックグラウンド更新を最初にリリースしたとき、次の大きな推進力は、今後数年間でメジャーリリースの自動更新を取得することだと考えました。 実際には、これはいつでも実行でき、実際、3.7はこれをフラグとしてサポートしていました。 しかし、サンドボックス化、ホワイトスクリーン保護、ロールバック機能の改善などにエネルギーを投資するという考えでした。そのため、メジャーバージョンの成功率はマイナーバージョンと同じくらい高かったのです。 (失敗率は、コピーする必要のあるファイルの数に比例して変化します。また、ファイルを変更するだけでなく、追加する必要がある場合はさらに複雑になります。)これを実行すると、すべてのサイトの更新を開始するだけです。最新バージョンに変更し、バックポートを停止します。 明らかに、私たちはまだここに到達していません。
彼は、全体的な提案は「素晴らしい計画」であるとコメントしましたが、更新しても安全であり、WordPressは最新バージョンのみをサポートすることを意図していることをユーザーに伝えることの利点を強調しました。
ディスカッションのほとんどの参加者は、セキュリティチームが古いバージョンのWordPressへのバックポート修正を中止することに賛成しています。 対戦相手にとって未解決のままの問題は、なぜ古いサイトを強制的に更新するのがWordPressの責任なのかということです。
「メジャー/最新バージョンに管理されていないサイトを更新するのはWordPressの決定ではないと思いますが、それらのブランチの維持は停止されるべきだと思います」とWillStocks氏は述べています。 「あなた(WordPress)は、インフラストラクチャやビジネスプロセスを所有していないか、それらのサイトを管理するためのサポートを理解していません。 これらのサイトが現在もそのバージョンであり、過去にアップグレードされていない理由もあります。」
メジャーバージョンへの合意に基づかない更新を強制することなく、セキュリティチームの限られたリソースを尊重するために、まだ線を引くことができる他のアプローチがあります。 WPCampusのディレクターであるRachelCherryはこの提案についてコメントし、WordPressにこれらのサイトを更新する前に同意を確立するよう強く求めました。
強制的な更新が技術的な問題を引き起こし、実際の問題を完全に見逃してしまうかどうかという問題に取り組んでいます。
彼らが同意を与えていないときに人々のソフトウェアを強制的に更新することについて話し合っています。
そして、何のために? ここでの本当の問題は何ですか? 古いバージョンの更新について心配したくないので?
この問題を解決する方法は他にもあります。
リリースのEOLサポートに関する明確なポリシーを作成できます。
コアに設定を追加して、ユーザーが自動更新を希望するかどうかを選択できるようにすることができます。これにより、意思決定者になります。 その後、同意を得ます。
更新に関する教育とコミュニケーションに取り組むことができます。
サイトが古くて安全ではないことを、教育やベストプラクティスへのリンクとともに、できるだけ早く更新する必要があることをメールでお知らせします。 それでも助けが必要な場合は、専門家に連絡するように勧めてください。
この問題は今後修正することができますが、許可メカニズムを導入したことがないという理由だけで、遡及的な同意を暗示しているわけではありません。
誰かが自分のサイトを更新しなかった場合、彼らは理由で更新しました。 または無関心。 いずれにせよ、私たちはこのように立ち入り、人々のウェブサイトを変更する権利はありません。
議論の参加者は、提案された政策変更の潜在的な影響にまだ取り組んでいます。 マイナーアップデートは、自動アップデートとして非常に信頼できることが証明されています。 Dunnは、3.7.29の自動更新には3.7.28にロールバックする必要のある障害が1つだけあったと報告しました。 自動更新システムを使用して、これらがまだ完全にテストされていない古いサイトにメジャー更新をプッシュします。
「3.7-> 5.xリリースを自動更新するかどうかにかかわらず、これが将来(5.x-> x.x +)に開始する予定であることを明確にすることを完全にサポートします」とJeremy Felt提案にコメントした。 「これをサポートするインフラストラクチャとコードのテスト作業は、どちらの方法でも絶対に行う必要があります。」 Felt氏はまた、提案されたリリースの段階的な展開スケジュールと、自動更新を無効にするための公式にサポートされたプラグインを提供する計画に感謝していると述べました。
提案についてはまだ議論が続いていますが、サイト所有者がハッキングされる可能性を防ぐことを目的としている場合でも、WordPressが明示的な同意なしにメジャーバージョンの更新を強制する権利があるかどうかについて、参加者の間で根本的な意見の相違があるようです。 。
「確かに、これまでのところ大きな懸念事項のようです。私たちの多くはこれらの高潔な意図を気に入っていますが、インターネットの慈悲深い大君主であることがWPの前進にとって良いイメージであるかどうかはわかりません。 」とプラグイン開発者のフィリップ・イングラムは語った。
