プラグインバージョン間でWordPress PHP互換性をテストする方法

WordPress PHP互換性テストとは、プラグインがサポートする各PHPとWordPressのバージョンの組み合わせで正しく動作するかどうかを確認することです。wp.runのWordPressサンドボックスを使えば、PHP 8.4とWordPress 6.9などのクリーンなテストインストールを起動し、ローカルサーバーや本番リスクなしに同じスモークテストを繰り返せます。

最初のチェックを今すぐ始められます。このページ上部のWordPressを起動を押し、テストしたいPHPとWordPressのバージョンを選択し、本物のwp-adminアクセス付きの使い捨てWordPressサイト内でプラグインを実行します。

WordPress PHP互換性にマトリックスが必要な理由

プラグインはあるスタックでは通過してもう一方では失敗することがあります。PHPの変更は非推奨の構文・より厳格な型付け動作・削除された関数・古いランタイムでは現れなかった警告を露出させる可能性があります。WordPressの変更はエディターの動作・フック・RESTエンドポイント・管理画面・バンドルされたJavaScriptに影響する可能性があります。

そのため「自分の環境では動く」という1回だけのチェックでは不十分です。プラグイン互換性テストは、ユーザーが実際に実行している組み合わせをカバーする必要があります。

WordPress Core公式ハンドブックにはWordPress自体のPHP互換性テーブルが掲載されています。コアに関してはそれをベースラインとして扱います。あなたの仕事はそれらのスタックの上でプラグインをテストすることです。WordPressコアの互換性はすべてのプラグインやテーマが正しく動作することを保証しないからです。

小さなPHP x WordPressバージョンマトリックスを構築する

実際のリリース問題に答える最小のマトリックスから始めます。ほとんどのプラグインチームにとって、それは意味のあるリリースごとに3行を意味します。

1. サポートされる最古のスタック。 これはまだアップグレードしていないユーザーを壊す構文またはAPIの使用法をキャッチします。
2. 推奨される現在のスタック。 これはほとんどの新しいテストとデモが使用することが期待されるスタックです。
3. 最新のスタック。 これはユーザーが報告する前にPHPとWordPressの将来的な変更をキャッチします。

wp.runでは、起動モーダルが明示的なWordPressとPHPバージョンの選択をサポートします。繰り返し可能なテストリンクからWordPressサンドボックスを起動したい場合は起動URLも使用できます。例えば：

https://wp.run/new?php=8.4&wp=6.9

サポートされているプリセットについては、環境を再現可能にするためにプラグインパラメーターを追加します：

https://wp.run/new?plugin=woocommerce&php=8.4&wp=6.9

独自のプラグインビルドについては、wp-admin内からZIPをアップロードし、メモに正確なビルドを記録します。マトリックスの各行にはスタック・プラグインバージョン・実行されたチェック・結果が必要です。

wp.runでプラグインのPHP 8.4互換性をテストする方法

ローカル環境を再構築せずにプラグインのPHP 8.4動作をテストする必要がある場合にこのワークフローを使用します。

1. ターゲットスタックを起動する。 WordPressを起動を押し、PHP 8.4と検証したいWordPressバージョンを選択してサンドボックスを作成します。wp.runは管理者認証情報と*.wprun.siteのURLを持つ一時WordPressインストールをプロビジョニングします。
2. 環境を確認する。 wp-adminを開き、テストを開始する前にPHPとWordPressバージョンを確認するためにツール -> サイトヘルス -> 情報を確認します。
3. プラグインをインストールまたは有効化する。 起動URLパラメーターからサポートされるプリセットをロードするか、wp-adminでプラグインのZIPをアップロードします。テスト記録に正確なプラグインビルドをメモします。
4. 有効化チェックを実行する。 プラグインを有効化し、致命的なエラー・管理通知・依存関係の欠落・リダイレクトループ・セットアップウィザードの失敗を監視します。
5. コア機能を実行する。 プラグインが存在する最小限の実際のワークフローを実行します。フォームの作成・チェックアウトの完了・ブロックの追加・サイトマップの生成・コンテンツのインポート・スケジュールされたタスクのトリガーなど。
6. 管理画面とフロントエンドを確認する。 ブロックエディター・プラグイン設定・公開ページの出力・関連するRESTエンドポイント・ブラウザコンソールを開きます。
7. 次のスタックで繰り返す。 次のPHPまたはWordPressバージョンを起動して同じチェックリストを実行します。失敗を分離する際は一度に1つの次元を変えます。

これにより手動の互換性シグナルが素早く得られます。単体テスト・統合テスト・静的解析の代替ではありませんが、ユーザーがwp-adminとフロントエンドで実際に目にする製品レベルの障害をキャッチします。

静的スキャンを追加するが、そこで止まらない

静的互換性スキャナーはランタイム前にコードパターンをキャッチするため有用です。WordPressのPHP互換性のためのプロダクトテストに関するLearn WordPressのレッスンでは、2つの一般的なアプローチ（ターゲットPHP環境での手動テストとPHP_CodeSnifferによるPHPCompatibilityルールでのスキャン）を取り上げています。

両方のシグナルを組み合わせて使用します。

• まず静的スキャン。 削除された関数・非推奨のシグネチャ・バージョン固有のPHP構文の明らかな使用を見つけます。
• 次にサンドボックステスト。 プラグインが起動し・UIをレンダリングし・期待されるオプションを書き込み・ターゲットスタックで実際のワークフローを完了することを確認します。
• 最後にリグレッションメモ。 失敗したこと・正確なPHP/WP/プラグインバージョン・警告・致命的エラー・UIの破損・データの問題のいずれかを記録します。

静的ツールはコードの1行が非互換かもしれないと教えてくれます。サンドボックスはプラグインがWordPress製品としてまだ動作するかどうかを教えてくれます。

WPバージョンテスト中に確認すること

WPバージョンテストはプラグインが有効化されるかどうかだけではありません。最もコストのかかるバグはしばしば有効化後、ユーザーがコンテンツを編集・設定を変更・古いバージョンからアップグレードするときに現れます。

マトリックスのすべての行でこれらの領域を確認します。

• 有効化と無効化。 プラグインはクリーンに有効化・無効化され、サイトを壊れた状態のままにしないこと。
• アップグレードパス。 まず前のプラグインバージョンをインストールしてサンプルデータを作成し、次に新しいプラグインバージョンにアップデートしてマイグレーションが実行されることを確認する。
• 管理画面とエディター。 プラグインが追加するすべてのメニューを開く。ブロック・ショートコード・埋め込み・カスタム投稿タイプ・メタボックスに触れる場合は、各WordPressバージョンでエディターをテストする。
• フロントエンドの出力。 テンプレート・ショートコード・アセット・リダイレクト・チェックアウトフロー・フォーム・ウィジェットが期待通りにレンダリングされることを確認する。
• REST・AJAX・スケジュールされたタスク。 関連するエンドポイントリクエストを送信し、プラグインがバックグラウンド作業に依存するcron依存の動作を検査する。
• アンインストールの衛生。 クリーンアップ動作が許容可能かどうかを確認するために使い捨てサンドボックスでプラグインを無効化して削除する。

このチェックリストを一貫して保ちます。テスターがwp-adminをそれぞれ独自のルートで進むと、マトリックスの比較が難しくなります。

プラグインリリースの実用的なマトリックス

リリースを準備しているプラグインチームのためのコンパクトなマトリックスです。

マトリックスをドキュメントの後付けではなくリリースゲートとして使用します。行が失敗した場合は、正確な手順をコピーしてデバッグ出力やスクリーンショットを含め、まだ生きている間に一時サンドボックスURLを添付します。

監視すべき一般的な互換性の失敗

ほとんどの互換性の失敗はいくつかのパターンに分類されます。

• 有効化時の致命的なエラー。 通常、削除されたPHP関数・欠落したクラス・依存関係のオートロードの問題・早すぎる実行コードが原因。
• 新しいPHPでノイジーになる警告。 動的プロパティ・nullable引数・厳格な型付けの前提・非推奨のシグネチャはページが表示されているように見えてもログに溢れることがある。
• エディターの破損。 プラグインはフロントエンドでは動作しながら、より新しいWordPressバージョンではブロックエディターの統合が失敗することがある。
• AJAX・REST・アップグレードの失敗。 ノンス処理・ルート登録・保存されたオプション・カスタムテーブルは弱い前提を露出させることがある。
• 依存関係の競合。 2つのプラグインが互換性のないバージョンの共有PHPライブラリまたはJavaScriptパッケージを同梱することがある。

行が失敗した場合は「PHPが非互換」に直接飛ばないでください。前のPHPバージョンで同じWordPressバージョン上の同じプラグインを再実行し、次にPHPを一定に保ちながらWordPressを変えます。1つの次元を分離することが実際の障害ラインを見つける方法です。

サンドボックスの位置づけ

使い捨てWordPressサンドボックスは互換性のスモークテスト・リリース候補のチェック・サポート再現・デモリンク・素早いプラグインQAに最適です。テストが本番に近いデータベース・永続ファイル・カスタムサーバー設定・長期的なデバッグに依存する場合はステージングまたはローカル開発を使用します。

実用的なワークフローは階層化されています。コードをスキャンし・自動テストを実行し・製品レベルのPHPとWordPressバージョンチェックにwp.runサンドボックスを使用し・特定のサイトを確認する必要がある場合にのみステージングに移行します。

FAQ

WordPress PHP互換性とは何ですか？

WordPress PHP互換性とは、WordPressコア・プラグイン・テーマが特定のPHPバージョンで正しく動作する能力です。プラグインについては、プラグインがWordPressフック・管理画面・データベースの動作・その他のアクティブなコードに依存しているため、本物のWordPress環境でテストする必要があります。

PHP 8.4でプラグインをテストするには？

PHP 8.4でwp.runサンドボックスを起動し、サイトヘルスでPHPバージョンを確認し、プラグインをインストールしてから有効化・管理・エディター・フロントエンド・REST/AJAX・アンインストールチェックを実行します。PHP固有の失敗を分離する必要がある場合は前のPHPバージョンで同じチェックリストを繰り返します。

WordPressコアの互換性はプラグインも互換性があることを意味しますか？

いいえ。WordPressコアはPHPバージョンと互換性があってもプラグイン自身のコード・依存関係・管理UI・アップグレードロジックのために失敗する可能性があります。WordPressコアの互換性チャートをベースラインとして使用し、次にプラグインを別途テストします。

PHPとWordPressの組み合わせはいくつテストすべきか？

サポートする最古のスタック・ユーザーが実行することが期待される現在のデフォルトスタック・準備したい最新のスタックをテストします。アップグレードパス・依存関係・顧客が報告した環境について関連する場合は行を追加します。

互換性テストを再現可能にする

最良の互換性プロセスは単調です。1つのマトリックス・1つのチェックリスト・1つの結果ログを、すべてのリリース候補に対して繰り返します。wp.runはそのプロセスの高速な環境レイヤーを提供します。クリーンなWordPress・選択可能なPHPとWordPressバージョン・生成された管理者アクセス・各行が完了したら破棄できる一時サンドボックス。