PHP 8.2の警告がWordPressツールを破損させた理由（とその修正方法）

歯がゆいシナリオを想像してみてください。マルチサイトWordPressメンテナンスツールが、すべて順調であると報告します—すべての診断が合格し、WP-CLI接続が機能し、バージョンチェックがグリーンを返します—しかし、実際の操作を実行すると、全体が失敗します。「テストはすべて合格したのに、本番環境で破損する」という現象に直面しているのです。2026年7月4日、DEV Communityの投稿でまさにこの問題がドキュメント化されました。そしてこれは、ソフトウェアがどのように失敗するかについての重要な事実を明らかにしています。時として、合格する診断と失敗する操作との間の溝には、微細な構造的問題が隠されているのです。

問題：警告がJSONを汚染する

古いWP-CLI 2.xをPHP 8.2以降で実行すると、予期しないことが起こります。PHP 8.2では新しい非推奨警告が追加されました。クラスが以下の属性で明示的に許可していない限り、そのクラスの動的プロパティに代入することはできません： #[\AllowDynamicProperties] 属性。内部で今なお動的プロパティを使用している古いWP-CLIは、これらの警告を絶えず発生させます。これ自体は破滅的なことではありません。警告は単なる警告です。コードは引き続き実行されます。

本当のトラブルはサーバーの以下に起因します： php.ini 設定。以下の設定によって、 display_errors 設定に応じて、これらの警告がstdoutに直接出力されてしまいます。stdoutはJSONデータが出力されるのと同じ出力ストリームです。

そのため、次のようなコマンドを実行した際： wp plugin list --format=json クリーンなJSONを期待して実行しても、代わりに次のようなものが返ってきます：

PHP Deprecated: Creation of dynamic property WP_CLI\Dispatcher\CompositeCommand::$longdesc is deprecated... [ {"name":"akismet","status":"active","update":"none"...}, ... ]

JSON配列の前にあるその警告行が以下を破損させます： json_decode()。ツールがそれをパースしようとして失敗し、クラッシュします。

なぜ診断は嘘をつくのか

ここで狡猾なのは、診断と実際の操作ではテストしている内容が異なるため、実際の操作が失敗しているにもかかわらず診断が合格する可能性があるという点です。

SSH接続テスト（例えば以下のようなもの）を実行する場合： echo ok—テストは出力のどこかに「ok」が表示されているかを確認するだけです。余分な行があっても問題ありません。以下を実行する場合： wp --version、テストはバージョン番号を探すだけです。見つかりましたか？ 合格です。

しかし、以下を実行する場合： wp plugin list --format=json、実際の操作は 出力を JSONとしてパースします。プレーンテキストのテストが無視する警告が、突然重要になります。JSONをJSONとして実際にパースしない診断では、発生しようとしている問題に気づくことができません。

これこそが、ユーザーが「すべてのテストがグリーンなのに、実際の呼び出しが失敗する」という事態を目にする理由です—診断がチェックするものと、実際の操作が必要とするものとの間の歯がゆい非対称性です。

3層の防御

警告をグローバルにすべて抑制しようとすることもできますが、すべてのホスティングプロバイダーのPHP設定を予測することはできません。代わりに、この解決策では3つの独立した防御層を使用します。1つの層がノイズを捕捉し損ねても、次の層が捉えます。

レイヤー1：発生源で警告をサイレント化する

WP-CLIは、以下の環境変数を受け入れます： WP_CLI_PHP_ARGS これは基盤となるPHP呼び出しに渡されます。これを使用して以下を調整できます： error_reporting レベルを調整し、PHPにDeprecatedおよびUser Deprecatedの警告を無視するよう伝えます：

php WP_CLI_PHP_ARGS="-d error_reporting='E_ALL ~E_DEPRECATED ~E_USER_DEPRECATED'"

以下の構文： ~E_DEPRECATED は「Deprecated警告を除外する」ことを意味します。Parse ErrorやFatal Error（これらは実際の失敗です）は引き続き表示されますが、ノイズは静まり返ります。

このレイヤーはほとんどのホスティング環境で機能します。ホストが追加の実行時オーバーライドを加えていなければ、警告がstdoutに出力されることはありません。

レイヤー2：パース前にノイズ行を削除する

しかし、アグレッシブなホストもあります。彼らは以下を実行します： ini_set() を自らのPHPスクリプト内で実行し、以下をオーバーライドします： error_reporting を経由して設定した後に、実行時にオーバーライドしてしまいます： WP_CLI_PHP_ARGS。その結果、警告はすり抜けてしまいます。

多層防御のために、JSONをパースしようとする前に、正規表現マッチングを用いて出力から認識可能なノイズ行を削除することができます：

python PHP_NOISE_LINE_RE = re.compile( r'^\sPHP\s+(Deprecated|Warning|Notice|Strict Standards):.$', re.MULTILINE | re.IGNORECASE )

def strip_php_noise(text): return PHP_NOISE_LINE_RE.sub('', text)

この正規表現がマッチ しない ものに注意してください：「Parse error」と「Fatal error」です。これらはノイズではなく実際の失敗です。意図的に除外していることが重要です。煩わしいノイズを取り除きつつ、実際の破損は通過させたいのです。

レイヤー3：終了コードを信頼する前にJSONパースを試みる

一部のホストは、有効なJSONがstdoutに存在しているにもかかわらず、単に警告が出力されたという理由だけで終了コード1（失敗）を返します。確認せずにゼロ以外の終了コードで中断してしまうと、実際にそこに存在するデータを見落としてしまいます。

代わりに、まずstdoutからのJSONパースを試み、 その後に 終了コードをチェックします：

python stdout_clean = strip_php_noise(res.stdout or '').strip() plugins = None

if stdout_clean: try: plugins = json.loads(stdout_clean) except json.JSONDecodeError: plugins = None

if plugins is None: # Only here do we give up if not res.ok: return error_response(res.stderr or res.stdout)

JSONがパースできれば、終了コードが失敗を示していても、呼び出しは成功したとみなします。重要なのは構造化されたデータです。

これをコードに適用する方法

ステップ1：静かなPHP引数でWP-CLI呼び出しをラップする

環境変数を先頭に付加するヘルパーを作成します：

python def wp_with_quiet_php(wp_cli_path): quiet_args = "-d error_reporting='E_ALL ~E_DEPRECATED ~E_USER_DEPRECATED'" return f"WP_CLI_PHP_ARGS='{quiet_args}' {wp_cli_path}"

ステップ2：JSONパース前にstdoutをクリーンアップする

試みる前に常にノイズ行を削除します： json.loads():

python output = run_command(wp_with_quiet_php(wp_path) + ' plugin list --format=json') clean_output = strip_php_noise(output.stdout).strip() if clean_output: plugins = json.loads(clean_output)

ステップ3：終了コードの前にJSONをチェックする

最初にパースを試みます。パースが失敗した場合のみ終了コードを信頼します：

python if plugins is None and not result.ok: raise Exception(result.stderr or result.stdout)

ステップ4：すべての呼び出し箇所を修正する

WP-CLIの出力に対して以下を呼び出しているすべての箇所をコードベース内で検索します： json.loads() 。同じ3層の防御をあらゆる場所に適用します。1箇所でも未修正の呼び出し箇所があると、異なるコードパス上に脆弱性が残ることになります。

ステップ5：テストを記述する

以下を確認する回帰テストを追加します：

• ノイズ行の削除が正しく機能すること
• Parse errorおよびFatal errorが 削除され ないこと
• 環境変数のクォート指定が安全であること
• 3つのAPIエンドポイントすべてが修正を使用していること

将来、開発者が以下を呼び出す4番目のAPIを追加した場合： json.loads() 生の出力に対して直接呼び出すと、テストは即座に失敗する必要があります。

2026年においてこれが重要である理由

私たちは過渡期にいます。現在、PHP 8.2および8.3は多くのホスティングプロバイダーで標準となっていますが、多くの古いWordPressプラグインやツールはまだ更新されていません。WP-CLI 2.xは広く導入されています。「コードは今なお動作する」ことと「出力がパースできるほどクリーンである」ことの間のギャップは実在し、単純な診断では目に見えません。より多くのチームが構造化出力（JSON API、ログパイプライン、自動化）を採用するにつれ、ライブラリが近代化されるまで、警告がデータストリームを汚染するというこの種のバグが表面化し続けるでしょう。

結論

本当の教訓はWordPressやPHP 8.2に限ったものではありません。独立した防御層を重ね、適切な抽象化レベルでテストすることについてです。診断が「部分文字列が存在するか」しかチェックしない場合、パース段階でしか現れない失敗を見落とします。警告をグローバルに抑止すると、実際のエラーを隠してしまうリスクがあります。データよりも終了コードを信頼すると、依然として重要な有効な出力を見落としてしまいます。

3層の修正（発生源で抑制、パース前にフィルタリング、終了コードより構造化データを優先）が機能するのは、各レイヤーが異なる失敗モードを捕らえるからです。1つのレイヤーが失敗しても、次のレイヤーが捕らえます。

メリット

• 目に見えない失敗を捕らえる。 診断で症状だけでなく、問題の本体を検出できるようになる。
• 多層防御。 単一のホスティング環境の癖でツールが破壊されることがなくなり、複数のレイヤーが異なる漏洩パスを捕らえる。
• 実際のエラーを保持する。 Parse errorやFatal errorは引き続き表面化し、ノイズのみがフィルタリングされる。
• 既存のWP-CLIで機能する。 古いツールを更新したり置換したりする必要はなく、修正層がその周囲を囲む。
• テスト可能。 各レイヤーを独立してテストでき、回帰を早期に捕らえることができる。

デメリット

• 複雑さが増す。 1つではなく3つのレイヤーを使用するということは、保守し理解すべきコードが増えることを意味する。
• 正規表現の脆さ。 ノイズフィルタリングの正規表現が、将来のPHPバージョンで導入される新しい警告フォーマットを取りこぼす可能性がある。
• 根本原因を解決しない。 これらは回避策であり、モダンなWP-CLIへのアップグレードやPHP互換性の向上ではない。
• 偽陰性の可能性。 将来のPHPバージョンでエラーメッセージのフォーマットが変更された場合、正規表現がマッチしなくなる。

注意

この記事は教育的な目的で書かれています。コード例を適用する際は、プレースホルダー値（以下のようなもの）を wp_cli_path やコマンドパスなど）を実際の環境の値に置き換えてください。まずは本番以外の環境で十分にテストしてください。本番環境で依拠する前に、DEV Community上の元の情報源に対してすべての主張と例を検証してください。特定の error_reporting フラグおよび正規表現パターンは、独自のPHPおよびWP-CLIバージョンに対してテストし、互換性を確保する必要があります。

よくある質問

• PHP 8.2における動的プロパティの非推奨化とは何ですか？
• ホストで以下が有効になっているかを確認するにはどうすればよいですか： display_errors ？
• これらの回避策を使用する代わりにWP-CLIをアップグレードできますか？
• なぜ単純な終了コードチェックではこの問題を防げないのですか？
• 自分のJSONパースがノイズに強いことをどのようにテストすればよいですか？
• 他にどのようなコマンド出力が同じ警告汚染問題を抱えている可能性がありますか？
• グローバルにすべてのPHP警告を無効にするべきですか？
• 警告をフィルタリングして除外しても安全かどうかをどのように判断すればよいですか？

タグ

#php #wordpress #wpcli #json #devops #errors #automation #hosting