PHP 8.6 RC4でWordPress 7.1.4を動かして検証｜調べた18か所で本体は警告なし、注意するのはプラグインの非推奨とセッションの既定値

2026年11月8日

PHP 8.6は11月19日に正式公開の予定で、いまは最後のRCであるRC5を試せる

PHPの開発チームは2026年10月21日にPHP 8.6.0 RC4を、11月5日に最後のRCとなるRC5を公開しました。RCは正式版の直前に出す試験版です。RC5の告知では次の公開が正式版（GA）の8.6.0で、予定日はPHP 8.6の日程表どおり2026年11月19日のままです。RC5の変更は不具合の修正が中心です。変更点の一覧（UPGRADING）のRC4からの差分はSodium拡張の新しいクラス名の追記だけで、この記事で扱う非推奨とセッションの既定値の記述はRC4とRC5で同じです。RC4には、同じ日に公表された、認証なしでの遠隔コード実行につながる2件の脆弱性の修正も入っています。PHPの告知はRCを本番では使わないよう求めており、8.5以前を使っているサイトは、同じ日に出た8.5.12などの修正版へ更新しておくと安心です。

PHPはWordPressを動かしているプログラム言語です。レンタルサーバーでは、新しい版が出ると管理画面から選べるようになり、しばらくすると既定の版も上がっていくことが多いです。8.6の変更点の一覧（UPGRADING）には、新しい書き方のほか、セッションの既定値の変更や、古い関数の非推奨化が並んでいます。

この記事では、Docker上でWordPress 7.1.4をPHP 8.5.12と8.6.0 RC4の2台で動かし、管理画面と公開ページで警告が出るかを確かめました。あわせて、古いプラグインで見かける書き方が8.6でどう扱われるか、セッションの既定値と新しい書き方がどう変わったかも、両方の版で比べています。自分のサイトを8.6へ切り替える前に、何を確かめればよいかが分かります。

3分で把握

調べた18か所では本体に警告は出ず、注意が要るのはプラグインと設定、タグ付きの動画・音声

2026年11月3日、DockerのPHP公式イメージ（8.5.12と8.6.0RC4）とWordPress 7.1.4で確認しました。

WordPress 7.1.4本体

18か所で警告0件

管理画面、公開ページ、REST API、WP-Cronは8.5と同じくdebug.logが空のまま。タグ付きのMP4・M4Aを読むと、本体の1か所から1ファイルにつき1件出た。

古い書き方のプラグイン

7種類の非推奨が出た

spl_object_hash()やis_integer()などで、8.6だけDeprecatedが記録された。ページの表示は続いた。

セッションの既定値

安全側に変わった

strict mode、HttpOnly、SameSite=Laxが既定に。ただし8.5のphp.iniを持ち越すと元の値のまま。

確かめた18か所では、WordPress 7.1.4本体はPHP 8.6 RC4でも警告を出さなかった

検証には、DockerのPHP公式イメージphp:8.5-apache（8.5.12）とphp:8.6-rc-apache（8.6.0RC4）に、WordPress 7.1.4のファイルを入れた2台を用意しました。どちらもWP_DEBUGを有効にして、警告や非推奨のメッセージをdebug.logへ記録する設定にしています。インストール後、管理者でログインして、次の18か所を両方の版で開きました。

18か所すべてHTTP 200、debug.logは8.5・8.6とも0行

公開ページ（4か所）

トップ、投稿、検索結果、RSSフィード

管理画面（12か所）

ダッシュボード、投稿一覧、新規投稿、メディア、テーマ、プラグイン、一般設定、サイトヘルス、更新、ユーザー、ツール、パーマリンク設定

裏側の処理（2か所）

REST APIの投稿一覧、WP-Cron（予約投稿などを動かす仕組み）

テーマは標準のTwenty Twenty-Five。標準で入っているプラグイン（AkismetとHello Dolly）は無効のままです。8.6で非推奨になった関数をWordPress 7.1.4のwp-includesとwp-adminで検索すると、同梱の音声・動画ライブラリにあるis_integer()の1か所だけが見つかりました（MP4・M4A・MOVのファイルにタイトルなどのタグが入っているときに通る部分）。次の段落で、この部分を実際に通した結果を紹介します。

本体のis_integer()が通る場面も試しました。ffmpegでタイトルとアーティスト名のタグを入れたMP4とM4Aを作り、メディアのアップロード時にも使われる本体の関数（wp_read_video_metadata()とwp_read_audio_metadata()）で読みました。8.5.12では何も記録されず、8.6.0RC4では1ファイルにつき1件、wp-includes/ID3/module.audio-video.quicktime.phpのis_integer()についてのDeprecatedが記録されました。メタデータは両方の版で同じように読めています。タグ付きの動画や音声を多くアップロードするサイトでは、WP_DEBUGを有効にしているとこの記録が増えていきます。

この1か所を除けば、調べた範囲では、8.6へ切り替えても本体の画面の表示や管理画面の操作は8.5と同じように動きました。実際のサイトで差が出やすいのは、テーマやプラグインの書き方と、サーバーの設定です。次の節から、その2つを順に見ていきます。

古い書き方のプラグインは、8.6で非推奨の記録が出る

8.6では、別名として残っていた関数や、オブジェクトを配列のように渡す書き方などが非推奨（Deprecated）になりました。非推奨は「いまは動くが、将来の版で削除される予定」という知らせで、処理はそのまま続きます。古いプラグインで見かける書き方を入れた試験用のプラグインを作り、両方の版でトップページを1回表示しました。

$id   = spl_object_hash( $obj );
$num  = is_integer( 42 ) && is_long( 7 );
$dbl  = doubleval( '1.5' );
$q    = http_build_query( (object) array( 'a' => 1 ) );
array_walk( $walk, function ( &$v ) { $v++; } );  // $walk は ArrayObject
define( 'LEGACY_TEST_CONST', 1, false );

8.5.12ではdebug.logに何も記録されませんでした。8.6.0RC4では、7件のPHP Deprecatedが記録されました（2行目のis_integer()とis_long()はそれぞれ1件）。ページの表示は両方の版で最後まで続いています。

8.6.0RC4のdebug.logに出た非推奨と、メッセージが示す書き換え先

spl_object_hash()

→ spl_object_id()（文字列の代わりに整数を返すので、文字列として保存・比較・連結している箇所も直す）

is_integer()、is_long()

→ is_int()

doubleval()

→ floatval()

http_build_query()、array_walk()にオブジェクト

→ ふつうのオブジェクトはget_object_vars()で配列にする。ArrayObjectはforeachで回して書き戻す（getArrayCopy()はコピーを返すので、中身を変える処理には使えない）

define()の第3引数

→ 第3引数を消す（すでに無視されている）

書き換え先は、PHPが出したメッセージに書かれていたものを基本にしています。ArrayObjectをget_object_vars()に渡すと、8.6.0RC4では空の配列になりました。またArrayObjectをarray_walk()に渡すと、8.5.12でも8.6.0RC4でも要素は1つも処理されませんでした。中身を処理するつもりのコードなら、8.6への対応と合わせて直します。UPGRADINGには、このほかstrcoll()、metaphone()、SORT_LOCALE_STRING、mbstringの正規表現関数（mbregex）なども非推奨として載っています。

WordPressはWP_DEBUGが無効のとき、記録の対象からE_DEPRECATEDを外します。そのため非推奨のメッセージが記録されるのは主にWP_DEBUGを有効にしているサイトで、その場合はページが表示されるたびに記録されます。アクセスの多いページで呼ばれていると、ログが短時間で大きくなることがあります。8.6へ切り替える前に、テスト用の環境でWP_DEBUG_LOGを有効にしてサイトを一通り操作し、debug.logに出たファイル名からプラグインやテーマを特定しておくと、作者への報告や更新の確認がしやすくなります。

セッションの既定値が安全側に変わり、古いphp.iniでは元のまま残る

サーバー側の設定で大きいのは、PHPのセッション機能の既定値です。WordPress本体はログインの管理にPHPのセッションを使っていませんが、会員制サイトやカート、フォームのプラグインには$_SESSIONを使うものがあります。php.iniを読み込まない状態で、両方の版の既定値を表示しました。

PHP 8.5.12

session.use_strict_mode: 0
session.cookie_httponly: 0（無効）
session.cookie_samesite: 空（指定なし）

PHP 8.6.0RC4

session.use_strict_mode: 1
session.cookie_httponly: 1
session.cookie_samesite: Lax

3つとも、セッションを乗っ取られにくくする方向の変更です。use_strict_modeは、サーバーが発行していないセッションIDを受け付けない設定です。cookie_httponlyは、セッションのCookieをJavaScriptから読めなくします。cookie_samesite=Laxは、ほかのサイトから届くリクエストのうち、リンクをたどるようなGETでのページ移動を除いて、セッションのCookieを付けない設定です。UPGRADINGは、JavaScriptでセッションのCookieを読む処理ではsession.cookie_httponly=0に、別のサイトからのPOSTでセッションが必要な処理ではsession.cookie_samesite="None"とsession.cookie_secure=1にするよう案内しています。外部の決済サービスからPOSTで戻ってくるカートなどが当たる可能性があります。

ここで注意したいのが、php.iniの扱いです。8.5に付いてくる本番用の設定ファイルphp.ini-productionには、この3つが「0」や空の値で明示されています。8.6.0RC4に8.5のphp.ini-productionを読み込ませると、3つとも8.5と同じ値になりました。

$ php -c php85-ini-production.ini -r '...'   # PHP 8.6.0RC4
session.use_strict_mode  '0'
session.cookie_httponly  ''
session.cookie_samesite  ''

8.6に付いてくるphp.ini-productionでは、3つとも新しい既定値（1、1、"Lax"）に書き換えられています。サーバーの版を上げるときに古いphp.iniをそのまま使い続けると、新しい既定値は効きません。自分で管理しているサーバーでは、8.6のphp.ini-productionと見比べてから設定を移し、レンタルサーバーでは、管理画面のphp.ini設定やphpinfo()の表の「Local Value」で実際の値を確かめます。phpinfo()を表示するファイルを置いた場合は、サーバーの設定が誰でも見られる状態になるので、確かめたらすぐに消します。

8.6で使えるようになる新しい書き方

テーマやプラグインを自分で書いている人に関係する新しい書き方もあります。8.6で追加された3つを含むファイルを両方の版で実行すると、8.5.12では部分適用の行で構文エラーになってファイル全体が動かず、8.6.0RC4では動きました。

final class Settings {
    public readonly int $perPage = 10;   // readonly プロパティに既定値
}
function tax(float $rate, int $price): int { return (int) round($price * (1 + $rate)); }
$withTax = tax(0.1, ?);                  // 部分適用: 第1引数だけ決めた関数を作る
echo $withTax(1000), ' ', clamp(-5, 0, 100);   // 1100 0

# PHP 8.5.12
Parse error: syntax error, unexpected token "?", expecting ")"
# PHP 8.6.0RC4
perPage=10 withTax(1000)=1100 clamp=0

部分適用は、関数の引数の一部だけを先に決めて、残りを後から渡せる新しい関数を作る書き方です。clamp()は、値を指定した範囲に収める関数です。readonlyのプロパティには、8.6から既定値を書けるようになりました。このほか、文字列の前後の空白を消すtrim()は、8.6から改ページ文字（\f）も消すようになり、手元でも"\fabc\f"が"abc"になりました。

これらの書き方を使ったコードは、8.5以前では構文エラーや致命的エラーになり、サイト全体が表示されなくなることがあります。配布するプラグインで使うときは、プラグインのヘッダーとreadme.txtのRequires PHPを8.6にします。テーマではstyle.cssのヘッダーで指定します。WordPressはこの値を見て、PHPが古いサイトでの有効化や更新（管理画面からの更新と自動更新）を止めますが、FTPなどでファイルを直接差し替えた場合は止まりません。

8.6へ切り替える前に、テスト環境で確かめる3つのこと

ここまでの結果をもとに、WordPressのサイトを8.6へ切り替える前に確かめることを順に並べます。プラグインやテーマの作者は、最後のRCであるRC5で先に確かめておくと、正式版までに修正を出せます。サイトの運営者は、11月19日の正式版が出てから、テスト用の環境やステージング環境で試すと安心です。

1. WP_DEBUG_LOGを有効にして、サイトを一通り操作する

テスト環境を8.6にして、公開ページ、管理画面、フォームの送信、予約投稿、動画や音声のアップロードなどを動かし、debug.logに出たDeprecatedのファイル名から、該当するプラグインやテーマを特定する。

2. セッションの3つの設定の実際の値を見る

サーバーの管理画面のphp.ini設定やphpinfo()の表の「Local Value」で、session.use_strict_mode、session.cookie_httponly、session.cookie_samesiteの値を確かめる。会員制やカートのプラグインがあれば、ログインと購入の流れも試す。phpinfo()のファイルは確かめたらすぐに消す。

3. プラグインとテーマを最新にしてから切り替える

非推奨が出たプラグインは、更新で直っていないかを先に確かめる。更新がなければ作者へ報告し、切り替えは修正を待ってからにする。

まとめ：本体は調べた範囲で8.6でも動き、プラグインと設定を先に点検する

PHP 8.6.0 RC4の上でも、WordPress 7.1.4の本体は、管理画面、公開ページ、REST API、WP-Cronの18か所で警告を出しませんでした。本体で記録が出たのは、タグ付きのMP4・M4Aを読んだときの1か所だけで、1ファイルにつき1件記録されます。8.6で大きな差が出たのは、古い書き方のプラグインで出る非推奨の記録と、セッションの既定値の2つです。セッションの新しい既定値は、8.5のphp.iniを持ち越すと効かないことも確かめられました。

正式版は11月19日に公開される予定です。テスト環境でdebug.logとセッションの設定を確かめておけば、レンタルサーバーで8.6が選べるようになったときに、落ち着いて切り替えられます。

参考資料

PHP 8.6.0 RC4 available for testing（PHP、2026年10月21日）。RC5の予定日、脆弱性の修正
PHP 8.6.0 RC5 available for testing（PHP、2026年11月5日）。正式版の予定日、RC5のNEWSとUPGRADINGへのリンク
php-8.6.0RC4...php-8.6.0RC5（php-src）。RC4からRC5までのNEWSとUPGRADINGの差分
PHP 8.6 の日程表（todo/php86）（PHP Wiki）。正式版の予定日（2026年11月19日）
UPGRADING（PHP-8.6）（php-src）。互換性を壊す変更、新機能、非推奨の一覧
php（Docker公式イメージ）。検証に使った8.5.12と8.6.0RC4

WordPressWordPress,プログラミング

Posted by Negichou Lab 編集部