4 つのステップで PHP 8.x に切り替える – Juliette Reinders Folmer へのインタビュー
公開: 2023-03-04WordPress サイト、プラグイン、またはテーマを新しいバージョンの PHP にアップグレードする作業は、定期的に繰り返されます。 しかし、これをできるだけ効率的に行うにはどうすればよいでしょうか。 何も見逃さないってどうやってわかるの？ そのロードマップはありますか？
この記事では、これらの質問 (およびその他) に取り組み、WordPress サイト、プラグイン、またはテーマを PHP 8.x にスムーズに移行するために何が必要かを、ロードマップを含めて見ていきます。
これは、PHP の専門家である Juliette Reinders Folmer に行ったインタビューに基づいています。 彼女は日常生活のほとんどをプログラミングとその周辺のすべてに費やしており、主に WordPress を含むオープンソース プロジェクトに焦点を当てています。
あなたもスムーズに切り替える準備はできていますか？ ステップバイステップのプランに興味がありますか? それでは早速潜っていきましょう！
PHP 8.x — 変更点
変更の概要については、以下の記事をお勧めします。
- PHP 8.0 および PHP 8.1 のリリースノート
- PHP 8.0 および PHP 8.1 の移行ガイド
- WordPressとPHP 8.0と現状
- PHP 8.0 および PHP 8.1 の新機能
これらの記事を読めば、PHP 8.x で何が変更されたのか、また PHP プロジェクトを問題なく実行するために何をする必要があるのかについて、完全に更新されます。
最適な開始方法がわからない場合でも、問題ありません。 Juliette との会話では、これについて詳しく説明しました。この記事では、PHP 8.x に切り替える方法を可能な限り詳しく説明します。
また、すべての WordPress サイト、アプリケーション、およびデータベース用の独自のコントロール パネルである MyKinsta でさまざまな操作を実行する方法についても、有益なボックスで説明します。
PHP 8.x への切り替え: 開始方法
PHP 8.x への切り替えは簡単に聞こえますが、技術的にはそうです。 多くのホストでは、管理パネルで Web サイトに使用する PHP のバージョンを指定できます。 Kinsta では、MyKinsta ダッシュボードでワンクリックで PHP バージョンを切り替えることができます。
ただし、その前に、確認する必要があることがいくつかあります。 知識と経験のレベルに応じて、次のことをお勧めします。
- PHP についてあまり知識がなくても、標準のテーマとプラグインを使用して独自の WordPress サイトを構築した場合は、開発者または代理店に依頼して、サイトが PHP 8.x での実行に適しているかどうかを調査してください。 これを手伝ってくれるサードパーティをお探しですか? 次に、お客様を支援できる信頼できる企業がいくつかリストされているパートナー ページをご覧ください。
- WordPress サイトが外部の関係者、開発者、または代理店によって構築された場合は、それらに連絡して、サイトが PHP 8.x で実行できるかどうかを尋ねてください。
- 独自のカスタム テーマや独自開発のプラグインなどを使用して WordPress サイトを構築している場合は、以下にロードマップがあります。
あなたのサイトが最初の 2 つのカテゴリのいずれかに該当する場合は、この記事の残りの部分を読むことをお勧めしますが、サイトの PHP 8 互換性を自分でテストすることはお勧めしません。 プロにお任せください。
どちらを選択する場合でも、ライブ サイトを PHP 8 に切り替えて「動作するかどうかを確認する」だけにしないことをお勧めします。 サイトがどのようなものになるか興味があり、PHP 8 で実行されるのが待ちきれませんか? 次に、ステージング環境でテストを開始します。 優れたホストを使用すると、ステージング環境を簡単にセットアップできます。
ステージング環境では、PHP 8.x を有効にして、この更新がサイトでうまく機能するかどうかを確認できます。 サイトのローカル コピーを操作することもできます。 無料の DevKinsta 開発ツールを使用すると、MyKinsta ダッシュボードからサイトを簡単にインポートできます。その後、PHP バージョンを 8.0 または 8.1 に変更できます。
ステージング環境に問題が見られない場合でも、必ずしも実際に問題がないというわけではありません。 以下のロードマップがその理由を示しています。
PHP 8.x 互換性テスト: ロードマップ
テスト: 優れたソフトウェアのキーワード。 WordPress Web サイトとそのコンポーネント (テーマ、プラグイン、WordPress コアなど) でさえ、テストは、発生したくないことが起こらないようにするための手段です。
ソフトウェア開発プロジェクトは、主にテストで構成されています。 この記事では、PHP 8.x への移行をスムーズに進めるために役立つテストを具体的に見ていきます。 DevOps ツールに関する記事には、使用できるツールのコレクションを含むセクションがあります。
このブログ投稿では、次の種類のテストについて説明します。
実行できるさまざまな種類のテストを詳しく見てみましょう。
静的分析 (または静的テスト)
PHP 開発者として実行できる最初のステップは、さまざまなツールを使用してコードの静的分析を実行することです。 静的解析は、コードを実行せずにソフトウェアを解析するプロセスです。 静的分析を使用すると、エラーの検出、PHP 8.x 互換性の問題の検出、コーディング標準 (WordPress コーディング標準など) の適用、さらにはコードの変更とクリーンアップが可能になります。
静的解析ツール
次のようなさまざまなツールを使用して、静的分析を実行できます。
- PHP互換性
- 詩篇
- PHPスタン
執筆時点では、すべての PHP 8.1 チェックが最新の PHPCompatibility リリースでサポートされているわけではありません。 PHP 8.1 チェックは開発リリースに含まれている可能性があるため、PHPCompatibility を使用してプロジェクトを分析し、どのようなエラーや推奨事項があるかを確認する場合は、(今のところ) それらを使用してください。
PHP 8.1 チェックは、まもなく新しいメジャーバージョンでリリースされます。 これに関する最新情報を入手したい場合で、GitHub アカウントを持っている場合は、PHPCompatibility の GitHub リポジトリを開き、 Watch -> Custom -> Releasesに移動して、新しいバージョンがリリースされたときに通知を受け取るように選択できます。
PHP の特定のバージョン (またはバージョンの範囲) の互換性のみをテストする PHPCompatibility は、セットアップが簡単です。 PHPCompatibility 内で testVersion (たとえば、8.0+ (8.0 以降)) を実行すると、最良の結果が得られます。
非推奨または削除された関数、関数パラメーターのデフォルト値の変更、括弧なしで concat を使用するかどうか、関数名として match を使用するかどうか (PHP 8.0 以降予約されているため) などに注意する必要があります。
Psalm と PHPStan は優れた追加機能であり、変数の型に関連する追加のチェックを実行するのに役立ちます。 これらのツールの欠点は、PHP 8.0 および 8.1 でレポートを取得するために多くの構成が必要になることです。 成功したとしても、多くの誤検知が予想されます。 誤検知は、静的分析の制限によって引き起こされる、誤って送信される通知です。
これら 2 つのツールの結果を適切に解釈するには十分な知識が必要ですが、その知識は、PHPCompatibility が見つけられないその他の非互換性を特定するのに役立ちます。 Psalm と PHPStan について詳しく知りたい場合は、それらのドキュメントを参照してください。
まとめ：
- PHPCompatibility、Psalm、PHPStan による静的分析の実行
- すべての正当な問題を解決する
単体テスト
プロセスの次のステップは単体テストです。 単体テストは、コードを個別にテストする方法です。 ユニットテストでは、ユニットごとに特定のターゲットテストが開発されます。 これには、さまざまなシナリオを実行することが含まれます。 好ましくは、テストが互いに独立するように、各シナリオを他とは別にテストする。
もちろん、単体テストだけでは十分ではありません。 それらも実行する必要があります。 単体テストは、Jenkins、GitHub Actions、Travis などの CI (継続的インテグレーション) ツールを使用して自動化するのが最適です。
複数バージョンの PHP のサポート
プラグイン ビルダーとして、複数の PHP バージョンをサポートする場合は、サポートするすべての PHP バージョンに対して CI のテストが実行されていることを確認してください。
もちろん、新しいバージョンのみをサポートすることもできます。選択は完全にあなた次第です。
複数のバージョンの PHP でテストするには、PHP のバージョンに応じて、複数の PHPUnit バージョンを使用する必要があります。 PHPUnit は何年にもわたって、テストの作成方法に影響を与えるいくつかの変更を導入しているため、この部分は扱いにくい場合があります。
これを回避するには、PHPUnit Polyfills (Juliette が作成し、Yoast が後援) を使用できます。 これにより、PHPUnit 9 で公式にサポートされていない (したがって、PHP 8.x で実行できる) テストを作成できます。 Polyfills は、PHPUnit 4.x から 9.x まで、および PHP 5.4 から PHP 8.1 まで (現在) でテストを機能させます。[/notice]
テストを実行したので、次のステップは、テストで見つかった問題が修正されていることを確認することです。
コード カバレッジ
これらのテストを実行することは、バージョン間の非互換性を見つける最も信頼できる方法です。
その際、テストのコード カバレッジに注意してください。
- 関数 A があり、そのテストを記述しており、関数 A が関数 B、C、および D を関数内のロジックの一部として呼び出しているとします。
- 関数 A のテストは、関数 A のロジックをテストするために書かれていますが、テスト中に関数 B、C、および D も呼び出します。 関数 B、C、および D については、通常、「ハッピー パス」 (すべてがうまくいく状況) のみをテストするため、これらの関数もまだ完全にはテストされていませんが、これらの関数のコード (の一部) は機能 A のテスト中に実行されます。
- テストごとに、どのコードが具体的にテストされているかを示します。 これを行うには、各テストに @covers を指定します。この方法では、コード カバレッジの計算で B、C、および D が「カウント」されないため、コードのどの部分がテストでカバーされているかを確認できます。
多くの場合、開発者は "ハッピー パス" のために (時には無意識のうちに) 作成およびテストを行います。 このような場合、予期しないデータが関数に渡されたときに何が起こるかをテストすることも必要です。 期待される値/型だけでテストするだけでは十分ではありません。
上記の引用の 2 番目の部分は、おそらく最初の部分よりも重要であるにもかかわらず、忘れられることがよくあります。 間違った型を渡すとどうなりますか? エラーメッセージが表示されますか? それとも、関数が正常に継続する変数のキャストですか? 関数に予期しない値が渡された場合はどうなりますか?
予期しない変数、型、値を使用して関数をテストしてください。 そうして初めて、テストを信頼して、新しい PHP バージョンが引き起こす可能性のある問題を見つけることができます。
PHPはより厳密になっています
PHP は、動的プロパティなどと同様に、PHP 自身の関数の「型」を処理する方法において、より正確 (厳密) になりつつあります。 これらの変更は、通常、開発者がエラーのないコード (つまり、エラーの少ないコード) を提供できるようにすることを目的としています。 しかし、これは、PHP の「古い」信条に基づいて記述された既存のコードをアップグレードする上で大きな障害となる可能性があります。
PHP でより有用なエラー メッセージが求められているため、既存のコードを新しい PHP バージョンに適合させるには、ますます時間がかかることがわかります。 ほとんどの場合、PHP 5.6 で動作するコードを PHP 7.0 に適したものにするのにかかる時間は、コードをアップグレードして PHP 8.1 に適したものにする場合に比べてほんのわずかです。 これは、PHP 7.0 が「メジャー」リリースであり、PHP 8.1 が「マイナー」リリースであるにもかかわらずです。
多くの場合、テストは、新しいバージョンをサポートするために何を変更する必要があるかを判断する唯一の信頼できる方法です。
単体テストは、次のようなさまざまなツールで可能です。
- PHPユニット
- あざけり
- ベハット、
- ストーリープレイヤー
これらのツールの多くは、PHPUnit に基づいて構築されているか、PHPUnit と組み合わせて構築されています。
最終的には、どのツールを使用するかは問題ではありません。 最も重要なことは、テストを行い、新しい PHP バージョンでテストを実行することです。 このステップは非常に難しい場合がありますが、幸いなことに、前述のように、PHPUnit Polyfills など、このためのツールがあります。
統合テスト
統合テストは、静的分析と単体テストの後に実行する次のステップです。 統合テストは、実際の状況が単なる「コード ユニット」よりも大きなコンテキストでテストされる場所です。 これらには、アクティブな (テスト) データベースを使用したテスト、または外部 API を使用したテストが含まれます。例を 2 つ挙げるだけです。
したがって、WordPress のコンテキストでプラグインまたはテーマのコードをテストし、実際のバージョンを使用する場合、これらは定義上、統合テストです。
WP Test Utils (これも Juliette が作成し、Yoast が後援) は、統合テスト用の優れたツールです。 WP Test Utils は、統合テストと単体テストを作成するためのツールを提供します。このテストでは、Brainmonkey と Mockery を使用して WordPress を「モックアップ」し、WordPress コードではなく独自のコードをテストするために、一般的に使用される WordPress 関数を「偽造」します。
WordPress との統合テストは、WordPress と WordPress のテスト スイートとの統合を伴うため、ややこしい話です。 プラグインまたはテーマがサポートする WordPress のバージョンに応じて、WordPress 自体がサポートする PHPUnit のバージョンを検討して、さまざまな PHP バージョンでテストを実行する必要があります。
たとえば、WordPress 5.6 から 5.8 は PHPUnit 5 から 7 を使用して PHP 5.6 から PHP 8.0 をテストしますが、WordPress 5.9 では、WordPress 自体もより広範なサポートのために PHPUnit ポリフィルを使用します。 WP Test Utils は、これらすべての違いを克服するための架け橋として機能します。
WordPress 5.9 以降を含む複数の異なるバージョンの WordPress に対して統合テストを実行する方法について詳しく知りたいですか? 次に、WordPress の Web サイトでそれについて読んでください。
手動テスト
単体テストと統合テストを完了し、見つかったすべての問題を修正したので、次は手動テストを行います。 あなたのサイトは稼働しており、独自のコードも機能していますが、プラグイン A、B、および C も使用しています。これらのプラグインに互換性があるかどうか知っていますか?
たとえば、プラグインの作成者にこれを確認し、プラグインが PHP 8.x と互換性があることを示しているかどうかを確認してください。 もちろん、問題はプラグインがどのようにテストされたかです。 多くの場合、ここでの答えは次のとおりです。 プラグインの機能は通常、他のアクティブなプラグインなしで、WordPress のみと組み合わせてテストされています。 また、これらのテストで他のプラグインが使用されたとしても、使用されたすべてのプラグインがテストの一部であるとは限らない可能性があるため、そのような互換性に関する記述は慎重に検討してください。
たとえば、3 つのプラグイン (A、B、および C) を持つ WordPress サイト。 たとえば、プラグイン B がフィルタを介して誤った変数タイプを返す可能性があります。プラグイン C は、同じフィルタを使用して、それを操作したいと考えています。 これにより、タイプが予期されたものでなくなるため、致命的なエラーが発生する可能性があります。 プラグイン B が実際の違反者であっても、プラグイン C がエラー メッセージの原因と見なされます。
プラグインの相互運用性 - 非互換性は、単独でテストするときに発見することは不可能です。 アクティブなプラグインが多いほど、問題が発生する可能性が高くなります。 たとえば、ライブ Web サイトからステージング環境 (エラー ログが有効になっている) にページ リクエストを渡して、実際に何が問題なのかを発見することは非常に有益です。
このタイプの問題では、プラグイン C が必ずしも問題の原因であるとは限りませんが、サイト所有者は通常、最後に実行されたコード (この場合はプラグイン C) でエラーが発生したというメッセージのみを表示します。
ほとんどの場合、手作業が多く、これらの問題を検出して修正するには、かなりの労力が必要です。 これは、エンド ツー エンドのテストを使用して自動化できますが、WordPress ではあまり発生していません。
利用されているプラグインの可用性をテストする
開発者および開発チーム向け: テストが利用可能な場合にのみコードを受け入れます。 このようにして、必要な手動テストが少なくなり、時間を大幅に節約できます。
商用プラグインまたはテーマを購入したい場合は、そのテスト戦略に疑問を呈してください. こうすることで、WordPress コミュニティの開発者/開発チームの間で、より高いアジェンダでテストを行うように意識を高め、全員が恩恵を受けることができます.
テストは、実際にはコストを節約できるにもかかわらず、不当にコストと見なされることがよくあります。 テストの作成に必要な追加の投資は、バグ レポートの大幅な削減とバグ修正に費やす時間の削減という形で報われます。 さらに、自動化されたソフトウェア テストを使用すると、テストによって既存の機能が引き続き機能することを迅速に確認できるため、拡張と変更をより迅速に行うことができます。
WordPress ホストと PHP 8.x の役割
平均的なサイト所有者にとって、ホストからのガイダンスは非常に望ましいものです。 次の点を考慮してください。
- WordPress コア、プラグイン、および/またはテーマが (場合によっては) PHP クロスバージョン互換性がないという顧客向けのドキュメントと更新
- テストのオプション (ステージング環境での作業など)
- エラー報告とサポートへの連絡方法
これは、問題が発生したときにサイトの所有者がホストに助けを求めることが多いため、Web ホストにとってもメリットがあります。 PHP 8.0 または 8.1 への切り替えの場合、潜在的な問題の責任はサイトの所有者にあり、所有者が切り替えのために適切に準備できる情報が多ければ多いほど良いでしょう。
PHP 8.0 または 8.1 を Web ホストとして顧客が利用できるようにすることは 1 つのことですが、そうすることで、問題が表面化する可能性があることを認識できるように、顧客の間で意識を高める必要があります。 ライブとは異なるバージョンのステージング環境でサイトをテストすることをお勧めします。 (KinstaではデフォルトでPHPバージョンの選択が可能です。)
WordPress の最小 PHP バージョン
現在、全 Web サイトの 15% 以上が PHP バージョン 7.0 以下を使用しています。 これは、WordPress の公式統計で確認できます。 現在、すべての WordPress サイトの約 83% が PHP バージョン 7.4 以下を使用しています。 バージョン 7.4 以下は、現在 PHP でサポートされていないことに注意してください。 PHP のサポート終了バージョンを使用すると、セキュリティ更新プログラムがリリースされなくなるため、問題が発生する可能性があります。
問題を回避するには、WordPress サイトの所有者が、サイトを安全に実行できる最小の PHP バージョンを認識し、通知することが重要です。 サイト所有者は、PHP バージョンを自分で変更するか (Kinsta ではすべてのパッケージで可能)、ホストにサイトを新しい PHP バージョンに更新するよう依頼できます。 極端な場合は、これらの新しいバージョンをサポートするホストに切り替えることができます。
WordPress は最小バージョン 7.4 しか必要としないため、多くのホストや Web サイト所有者がサイトを更新する動機が不十分です。 これは、PHP 7.4 が 2022 年 11 月にサポート終了になったにもかかわらずです。
WordPress が最小 PHP バージョンを増やした場合、これは、多くのサイトが最新の WordPress バージョンへの更新と互換性がなくなることを意味する可能性があります。 ただし、これらの古いバージョンのセキュリティ更新プログラムは、かなりの期間リリースされ続けます。
まとめ
Web サイトを PHP 8.0 以降に切り替えるには、開発者が実行する必要があるいくつかの手順があります。 重要な手順は次のとおりです。
- 静的分析
- 単体テスト
- 統合テスト
- 手動テスト
PHP 8.x に切り替えるときは、すべてが適切にテストされていることを確認してください。 これは、新しい PHP バージョンでサイトが正しく、迅速かつ安全に動作することを保証する唯一の方法です。
この記事に参加し、言及されたツールに関する彼女のすべての作業に対して、ジュリエットに非常に感謝します!
ジュリエットの写真。Jip Moors が撮影し、許可を得て使用しています。