PHP 8.2: WordPress、プラグイン、開発者にとって何を意味するのか?

公開: 2022-12-14

PHP 8.2.0 は 2022 年 12 月 8 日にデビューしました。メジャー アップデートとして、パフォーマンスの向上、構文の簡素化、スタンドアロン型としてのnull 、 false 、およびtrueによる優れた型安全性がもたらされます。 WordPress 開発者に挑戦する可能性が高い最大の変更の 1 つは、動的プロパティを許可しない読み取り専用クラスの導入です。

動的プロパティは非推奨であり、PHP 9 または PHP 10 で致命的なエラーが発生する可能性があります。特に WordPress コアの場合、潜在的に苦痛を伴いますが、非推奨は重要な機能であり、PHP から開発者への贈り物です。

PHP の最近の進化と、WordPress 開発者がエンドユーザーに最も利益をもたらす新機能を活用しながら下位互換性を維持する方法を見てみましょう。

WordPress での PHP 開発についていく

WordPress コアは重要な下位互換性を維持しており、古いバージョンがサポートされなくなる予定のサポート終了日はありません。そのため、自社の製品またはサービスのライフ サイクルと、サポートする PHP のバージョンを決定するのは WordPress ビジネスの責任です。

最低でも PHP 7.4 が必要な WooCommerce とは対照的に、WordPress コアは現在、PHP 7.4 以降のみを推奨しています。 2018 年末にサポートが終了した PHP 5.6.20 でも動作します。WordPress プロジェクトはこれに注意し、サポートされていない PHP バージョンを使用すると「サイトがセキュリティの脆弱性にさらされる可能性がある」と警告しています。 (WordPress.org の要件)

幸いなことに、現在 PHP 5.6 を使用している WordPress サイトは全体の 5.1% にすぎず、さらに古いバージョンを使用しているのは 2% だけです。 20% は PHP 7.0 から 7.3 を使用しており、最大のグループ (56.7%) は PHP 7.4 を使用しています。 (WordPress.org統計)

残念ながら、PHP 7.4 は 2022 年 11 月末に EOL に達したばかりです。PHP 8.0 の正式なセキュリティ サポートは、2023 年の大部分まで残り 1 年未満です。現在積極的にサポートされているバージョンである PHP 8.1 は、最後に期限切れになります。最初の安定版がリリースされたばかりの PHP 8.2 では、2025 年 12 月までセキュリティ サポートが提供されます。

これはリリースサイクルが速く、WordPress エコシステムがそれに追いつくのに苦労していることは驚くことではありません. Web の半分以上が WordPress で実行されているため、すぐに向きを変えることのできない大きな船です。 それは、最前線への競争というよりも、バランスをとる行為のようなものです。 ただし、PHP 8 への移行には多くの利点があります。たとえば、実行時の Just-in-Time (JIT) PHP コンパイルなどの大きなパフォーマンス強化機能により、少ないメモリ使用量でより高速に実行できます。

下位互換性と安定性、前向きな考え方とイノベーションの間のトレードオフ

可能な限り多くのユーザーに対応することと、PHP を使用して通貨を維持することのトレードオフは、WordPress の開発者、ホスト、および製品会社にとって常にジレンマを引き起こしてきました。 長期的なクライアントとレガシー サイトを持つエージェンシーやフリーランサーも同じ問題に直面しています。最小要件を更新すると、既存の顧客がサイトに大幅な変更を加えたり、サイトが壊れたりする可能性があります。

一方では、PHP を最新の状態に保つことの利点は、セキュリティとパフォーマンスの向上、および開発者向けの最新のプログラミングの概念と機能です。 一方、最低限必要な PHP を遅らせることの主な利点は、満足している (自己満足ではありますが) 幅広い顧客ベースです。 それは「今支払うか、後で支払うか」という状況です。 ある時点で、絆創膏を剥がさなければなりません。

ユーザー環境に関する適切なデータとテレメトリは、PHP の最小バージョン要件を引き上げるための最も混乱の少ない時間を決定するのに役立ちます。 ほとんどのプラグイン開発者は、WordPress.org プラグイン リポジトリのアクティブなインストール データの一部ではないため、独自のツールを使用してこれらの数を監視しています。 必然的に、多くの人々に影響を与える可能性のある重大な変更は、サポート チケットが殺到する結果になることが保証されています。

下位互換性を優先することには、多くの保守作業も必要です。 非常に大規模で多様なユーザー ベースをサポートすることは、エンド ユーザーにとっては素晴らしいことですが、それは、開発者が多くの異なる環境でコードを動作させ続ける必要があることを意味します。 「新しい機能が追加されたときに古いバージョンの PHP をサポートするのが大好きです」 — 開発者は誰も言いません!

彼らが心配しなければならないのは、レガシー PHP だけではありません。レガシー データベースや、WordPress スタック内の他の多くのバリエーションも対象としています。 時代遅れの要素を含む幅広い WordPress サーバー環境がある場合、エッジケースが発生し、専門家でさえも混乱させます。

PHP の最小要件を上げるのに最適な時期

iThemes Security Pro 7.2 リリースは、WordPress 製品の最小 PHP 要件を引き上げて、既存の顧客にイノベーションと安定性の両方を提供する好例です。

バージョン 7.2 のリリース時点で、iThemes Security Pro には PHP 7.3 以降が必要で、8.1 までサポートされています。 iThemes Security Pro の PHP 要件を更新する決定は、WebAuthn フレームワークを実装するために行われました。 実装には、暗号化と公開鍵を管理するために PHP 7.3+ を必要とするライブラリが必要でした。 iThemes Security Pro 7.2 で導入された 2FA、パスキー、および生体認証ログイン機能は、この決定の直接的な結果です。 明確なパスワードが破られたとき、iThemes セキュリティ チームは、主要なユーザー認証エクスペリエンスとして、初めてパスワードなしのログインを WordPress に導入しました。

古いバージョンの PHP との互換性のために WebAuthn ライブラリを書き直すことで、これらの機能を構築することができたはずです。 もちろん、それははるかに手間がかかり、維持する追加のコードを作成することになります。 より賢明な方法は、PHP 7.3 以降を必要とする依存関係を採用することで、適度なペースで PHP コミュニティについていくことでした。 ユーザーのほとんどはすでにそこにいました。 そのため、iThemes セキュリティ開発チームは、新規ユーザーと既存ユーザーの PHP の最小要件を引き上げることにしました。

GiveWP のように、Gutenberg ブロック エディターに多額の投資を行っている WordPress 製品の場合、変更の管理はさらに困難になる可能性があります。 WordPress コアの安定性と変化の遅さは、バックエンドの PHP 開発者を苛立たせるかもしれませんが、フロントエンドの JavaScript/React 開発者はプラットフォームを前進させることができます。

GiveWP の開発マネージャーである Jason Adams 氏は、サイト エディターが進化するにつれてバージョン間でユーザーを移行できるため、下位互換性を維持する必要はないと述べています。 しかし、「PHP の移行などというものはありません」と彼はコメントしています。 最終的には、PHP 9 アーキテクチャに適応し、PHP 8.2 で新たに廃止された機能から離れなければなりません。

WordPress エコシステム全体のすべての製品が PHP の最小要件を更新する「適切な時期」はありません。 「それは哲学的に解決できる問題ではありません」とアダムズは私に言いました。 それは、変更によって何人のユーザーが悪影響を受けるかに基づいた判断に大きく依存します. 90% 以上が PHP 7.2 または 7.4 を使用している場合、最小要件をそのレベルまで引き上げることは実行可能です。

これらの数値は、製品の特定のユーザー ベースによって大きく異なる可能性があると Adams 氏は言います。 より技術に精通した顧客が使用する製品は、現在サポートされている PHP バージョンに近い傾向があります。 多くの非営利団体が使用している GiveWP のような製品は、下位互換性をより重視する必要があります。 もう 1 つの方法は、レガシ コードとそのユーザーが、サポートされるが新しい機能が追加されない長期リリースに分岐できるようにすることです。 ユーザーがアップグレードの準備ができたら、将来の PHP 互換性のために構築された新しいメジャー リリースに移行できます。

非推奨通知が開発を前進させる

WordPress.com は、ホスティング機能を有効にしたビジネス プランと e コマース プランのオプションとして PHP 8.2 を展開しました。リリース。 WordPress.org のコア コードベースは公式には PHP 8.0 の「ベータ版」サポートのみを提供していますが、通常は最新バージョンの PHP で問題なく動作し、十分にサポートされているプラ​​グインでも同様です。 致命的なエラーや解析エラーをスローしません。 デバッグがオンになっていると、多くの警告が表示されることさえありません。 エラーではない非推奨の関数通知が多数表示される場合がありますが、まだです。

PHP のリリース サイクルが速いことに不満を感じているのは、コードのリファクタリングや PHP の廃止された側面に追いつくための雑草に開発者が行き詰まっていることに大きく関係しています。 この重要な作業により、最新の PHP バージョンがもたらす新しい概念と機能を探求し、革新する時間が少なくなる可能性があります。

この状況を見る別の方法があります。 PHP の廃止された機能を扱うことは、実際には将来を見越したものであり、開発者は進化する言語の次の反復に精通する必要があります。 このある程度強制された演習がなければ、既存の知識は、時代遅れになると悪い習慣になる古い習慣に簡単に定着してしまいます.

非推奨通知は、現在は機能するが、PHP の将来のバージョンでは機能しなくなることを指摘しています。 Brent Roose が説明しているように、これは開発者にとって良いことです。 開発者がこれらの通知に注意を払えば、廃止されたコードを理解するための十分な時間が得られます。 また、マイナー バージョンの更新を妨げるものであってはなりません。

iThemes Security Lead Developer で WordPress Core Committer の Timothy Jacobs 氏は、非推奨の警告があるのは良いことだと述べています。 これらは、開発者が「より正確」で「脆弱性の低い」コードを採用することを後押しします。これらのコードは、ますます安全で、パフォーマンスが高く、間違いを防ぎ、エッジ ケースによりよく対処できるようになります。 このビューでは、E_DEPRECATED 通知がエラー ログをいっぱいにすることは、「物事は将来壊れるが、今は壊れていないことを早期に警告するシステムのようなもの」です。

PHP 8.2 以降の動的プロパティを使用しない場合

PHP 9 で動的プロパティを段階的に廃止するための Nikita Popov の論理的根拠は、より回復力のあるコードとプログラミング規則に向けた PHP の進化の原動力の良い例です。

この変更の動機は 2 つあります。よくあるケースでのミス (タイプミスや名前の変更による) を防ぐことと、意図的な使用を明示することです。 中心的な問題は、存在しないプロパティから読み取ると、問題がすぐに明らかになる診断が発行されるのに対し、存在しないプロパティへの書き込みは完全にサイレントであることです。 PHP は、プログラマーが間違いを犯したことをまったく示しません。

PHP 5.6 から 8.2 への進化に関する Brent Roose の 2 分間のビデオは、PHP が 2014 年から現在までにどれだけ進歩したかを見事かつシンプルに視覚的に示しています。 Roose は、単純なデータ転送オブジェクトの例を使用して、PHP 5.6 コードが、PHP 8.2 に移行する過程で、大幅に縮小され、よりシンプルで無駄がなく、全体的に洗練されたコード ブロックになることを示しています。

Roose が動的プロパティ (PHP 8.2 で非推奨) を扱うためのヒントで述べているように、開発者は、非推奨の警告が致命的なエラーに変わる前に、既存のコードを更新するための十分な手段を持つ必要があります。 ただし、その滑走路は急速に縮小し、WordPress は特殊なケースです。 Tonya Mork は、WordPress コアでの未知の動的プロパティの非推奨を処理するための Trac で承認された提案を持っています。 彼女と Juliette Reinders Folmer は、20 年前のプロジェクトの前方互換性を維持するという特別な課題は言うまでもなく、WordPress 開発者がコードをリファクタリングするのに十分な時間がないことを懸念しています。 Mork、Reinders Folmer、および Sergey Biryukov は、この困難な作業のほとんど知られていないヒーローでした。

Mork と Reinders Folmer は、PHP 8.2 の動的プロパティとマジック メソッドに関する議論の中で、PHP がオブジェクト指向言語として進歩し続ける一方で、PHP 3 と 4 の WordPress のルーツは堅実な手続き型プログラミングの世界にそれを維持していると指摘しています。 Reinders Folmer が述べているように、コア開発者は、下位互換性を損なうことなく、「コードをより良く、より安全にし、PHP 8.2 の動的プロパティの廃止を緩和する」方法を、今日の PHP でレガシー コードの動作を維持する方法を見つけ出す必要があります。 「私たちは実際、[WordPress コアの] [下位互換性] ブレーク ルールがないため、自分たちの生活を非常に困難にしています」と彼女はビデオで述べています。

「それには十分な理由があります」と Mork 氏は答えます。 ユーザーは、そのボタンを押してアップグレードできること、および下位互換性について考え、それを優先したことを確信しています。 これは私たちの礎であり、ユーザーが自信を持ってアップグレードできるようにします。」

すべての開発はメンテナンスです…

WordPress コアの下位互換性を維持するために、PHP の以前の 2 つのメジャー バージョンで動作するように「最新の」PHP をバックポートしようとすることは、独特の課題です。 プラグイン開発者は、PHP 8.2 の読み取り専用クラスや動的プロパティの非推奨など、新しい機能を利用できる方法でコードを更新する作業がはるかに簡単になります。 この作業の多くは、主にメンテナンスの一種でもあります。

アーキテクチャ的には、PHP 8+ での変更は、不変性などのプログラミングの概念に焦点を当てています。 不変データ構造は「本質的にセキュリティの問題を解決するわけではありません」が、Jacobs 氏によると、開発者のコ​​ードがエラーを起こしにくくなり、より正確になるのに役立ちます。

不変のデータ構造が本質的に安全であり、可変のデータ構造が安全でないとは言いません。 むしろ、不変のデータ構造は、セキュリティの問題につながる可能性のあるプログラミングの誤りを排除するのに役立ちます。 コードが存在できるさまざまな状態の数を減らすことで、コードの複雑さを減らし、間違いを犯す可能性を減らすことができます。

積極的にサポートされている PHP バージョンの標準に合わせてコードを維持する一番の理由は、セキュリティ リスクを軽減するためです。 PHP 8.2 は、Adams 氏の見解では便利な機能と「ガード レール」をもたらしますが、プログラマーを興奮させたり、ゲーム チェンジャーと見なされるものはほとんどありません。 #[\SensitiveParameter]属性のようなものは、サードパーティのサービスに送信されることが多いスタック トレースから機密データを除外できるため、実際にはより重要になる可能性があります。 PHP 8 で導入された属性は、以前はできなかった何かを可能にするために Adams が注目した最新のイノベーションとして、Adams が選んだものです。

PHP 8.0 から 8.2 および将来のリリースの新機能を利用することは、開発者の創造性が発揮される場所ですが、単にそれらのバージョンをサポートすることで、プラグインと WordPress コアがそれらで壊れないようにすることは、実用的で重要です。

…そしてすべてのメンテナンスは芸術です

Jeff Atwood の「The Noble Art of Maintenance Programming」というタイトルの古いブログ投稿がありますが、これは Kale Davis の Hacker Newsletter のおかげで最近読みました。 「保守プログラミングは清掃作業と広く見なされています」と Atwood は書いています。 これは、アーティストの Mirele Laderman Ukeles を思い出させました。彼の「Maintenance Art Manifesto」は、プログラミングと Web 開発に非常に関連していると常に印象に残りました。

2 つの基本システム: 開発と保守。 あらゆる革命の魂の玉: 革命後、月曜日の朝に誰がゴミを拾うのですか? […] 開発システムは部分的なフィードバック システムであり、大きな変更の余地があります。 保守システムは、変更の余地がほとんどないダイレクト フィードバック システムです。

レイダーマン ウケレスは若いアーティストであり、1969 年にマニフェストを書き、メンテナンスはアートであると宣言した新しい母親でした。 彼女は、最先端の芸術作品と地位の高い労働者が、子育て、芸術的スキルと伝統の教育、またはアートショーの開催など、それらを可能にする仕事からどのように分割されているかに不満を感じていました. 彼女は博物館の管理人として活動する彼女自身を基にした印象的な展示を行いました。 その後、彼女は（進行中の）キャリアのほとんどをニューヨーク市衛生局のアーティスト イン レジデンスとして過ごしました。 その役割における彼女の最初のプロジェクトは、「ニューヨークを生かしてくれた」8,500 人の衛生作業員全員に個人的に感謝することでした。

アトウッドは、プログラミングに関して同様の見解を持っています。 彼は、保守作業を中傷することはすべて間違っていると言うソフトウェア エンジニアリングの主要人物を何人か引用しています。 Robert L. Glass は、「メンテナンスは重要な知的課題であり、問​​題ではなく解決策である」と感じたので、最も熟練した人々にとって重要なタスクと見なされるべきです。 Joel Spolsky はずっと前に、開発者は怠け者であり、彼らが「常にコードを破棄して最初からやり直したい」理由は、「コードを書くよりも読む方が難しい」ためだと書いています。

Andy Hunt との会話の中で、Dave Thomas は次のように主張しました。 …。 ほとんどの時間をメンテナンス モードで過ごします。 ですから、「初日から維持しています」と言って、弾丸を噛むこともできます。 メンテナンスに適用される規律は、グローバルに適用されるべきです。」 Hunt 氏も同意見です。 それでおしまい。"

Atwood は最終的にこの視点に傾いていますが、Jason Adams と Timothy Jacobs から聞いた一般的な WordPress 開発者の視点を反映しています。 WordPress の開発/保守の特殊技術?

「それはバランスをとる行為です。」

WordPress を安全に保護するための最高の WordPress セキュリティ プラグインが 35% オフになりました!

WordPress は現在、すべての Web サイトの 40% 以上で使用されているため、悪意のあるハッカーにとって格好の標的となっています。 iThemes Security Pro プラグインは、WordPress のセキュリティから当て推量を取り除き、WordPress Web サイトを簡単に保護および保護できるようにします。 これは、WordPress サイトを常に監視して保護するフルタイムのセキュリティ専門家がスタッフにいるようなものです。

今なら 35% オフ！