Google CloudのWordPressをPHP 8.1から8.4へ移行した作業記録

Google CloudのCompute Engineで運用しているWordPressを、PHP 8.1.31から8.4.27へ移行しました。 2026年10月22日に行った作業の記録です。

作業は、PHP 8.4を追加し、Apacheが接続するPHP-FPMを切り替え、WordPressの動作を確認してから、旧PHPを無効化する順で進めました。 途中では、コマンドラインのPHPが8.4になっていても、WordPressはまだ8.1で動いている状態も確認しています。

この記事では、実際に変更した内容と、各段階で何をもって確認したかをまとめます。 掲載するコマンドは当時の操作ブロックの部分抜粋であり、そのまま順に貼り付けて実行するための手順ではありません。 実際のブロックには、設定の退避、事前チェック、上書き防止、エラー時の復旧処理も含めていました。

更新のきっかけと今回の環境

きっかけは、PHP公式から2026年10月21日に公開されたセキュリティ告知でした。 記事作成時の2026年10月22日に改めて確認すると、告知には重大な脆弱性2件への修正版として、PHP 8.2.35、8.3.36、8.4.27、8.5.12が記載されています。 今回導入したのは、このうち8.4.27です。 出典はPHP公式の告知です。

作業前に確認した環境は次のとおりです。

項目	作業前の状態
基盤	Google Cloud Compute Engine
OS	Debian GNU/Linux 11（bullseye）
Webサーバー	Apache
PHP	8.1.31
WordPress側のPHP SAPI	fpm-fcgi
WordPress	7.1.3
テーマ	GeneratePress

このVMでは、ほかのサイトやPHP処理を運用していませんでした。 また、PHPパッケージはSuryのリポジトリから取得する構成でした。

以降に出てくるパッケージ名、Apacheの設定名、ソケットのパスは、この環境で確認したものです。 すべてのWordPress環境で同じ操作が必要になるわけではありません。

PHP 8.4を追加インストールする

先にAPTと退避先を確認した

最初のAPT索引更新では、bullseye-backportsの参照先で404が発生し、SuryとMySQLのリポジトリでは署名鍵のエラーも出ました。 このため、PHPのインストールに進む前に、参照設定と署名鍵を修復し、索引更新が通ることと、修正版のパッケージ候補を確認しました。

これは今回のVMにあった前段の問題です。 鍵の修復やリポジトリの変更を、PHP更新のたびに必ず行う操作としては扱いません。

日次のディスクスナップショットが作成されていることと、ディスクの空き容量も確認しました。 さらに、追加インストール前にApacheとPHPの設定を退避しています。 スナップショットからの復元試験は、この作業では行っていません。

削除されるパッケージがないことを確認して追加した

PHP 8.1を残した状態で、8.4のFPM、CLI、必要な拡張を追加しました。 対象にしたのは次の10パッケージです。

sudo apt-get --no-remove install \
  php8.4-fpm php8.4-cli php8.4-common \
  php8.4-curl php8.4-gd php8.4-mbstring php8.4-mysql \
  php8.4-opcache php8.4-readline php8.4-xml

実行前には、同じパッケージ一覧を指定して、--simulate --no-removeで依存関係を確認しています。 結果は追加10件、更新0件、削除0件でした。 実際のインストール結果も同じ件数でした。

0 upgraded, 10 newly installed, 0 to remove and 26 not upgraded.

インストール後は、php8.4 -vで8.4.27であることを確認しました。 加えて、php-fpm8.4 -tによるFPMの構文確認と、apache2ctl configtestによるApacheの構文確認が通っています。

CLIが8.4でも、WordPressはまだ8.1だった

追加インストールのログでは、update-alternativesによって/usr/bin/phpの既定が8.4へ変わったことが分かりました。 一方、Apache用の8.4-FPM設定を既定では有効化しない旨の通知も出ています。

この段階で、CLIとWordPressをそれぞれ確認すると、次の状態でした。

確認箇所	結果
SSHでのphp -v	PHP 8.4.27
WordPressのサイトヘルス	PHP 8.1.31／fpm-fcgi
Apache、8.1-FPM、8.4-FPM	すべてactive

トップページと管理画面も表示できましたが、WordPressはまだ旧PHPで動いていました。 CLIのバージョン確認と、Webリクエストを処理するPHPの確認を分ける必要があることが、この段階ではっきりしました。

上限値を移して、Apacheの接続先を切り替える

PHP 8.4側の初期設定をそのまま使わなかった

切り替え前に、8.1と8.4のFPM設定を比較しました。 8.4側には、次のように既存環境と異なる上限がありました。

設定	既存のWordPressで確認した値	追加直後の8.4-FPMのphp.ini
memory_limit	512M	128M
post_max_size	512M	8M
upload_max_filesize	512M	2M

今回は、既存の上限を引き継ぐため、8.4-FPM用に/etc/php/8.4/fpm/conf.d/99-wordpress-limits.iniを新規作成しました。 内容は次の3項目です。

memory_limit = 512M
post_max_size = 512M
upload_max_filesize = 512M

旧php.iniのメモリ上限には512MBと書かれていましたが、新しい設定は512M表記にしています。 ここでの512Mは、今回の既存設定を引き継いだ値です。 WordPressの一般的な推奨値として設定したものではありません。

FPMの構文確認に加え、php-fpm8.4 -iでも実効値を確認しました。

memory_limit => 512M => 512M
post_max_size => 512M => 512M
upload_max_filesize => 512M => 512M

その後に8.4-FPMを再起動し、サービスがactiveであることと、/run/php/php8.4-fpm.sockがソケットとして存在することを確認しています。

8.1-FPMの設定を無効にし、8.4-FPMを有効にした

Apacheの切り替え部分は次の操作です。 実際には、途中でエラーになった場合に8.1-FPMの接続設定へ戻す分岐を含むブロックで実行しました。

sudo a2disconf php8.1-fpm
sudo a2enconf php8.4-fpm
sudo apache2ctl configtest
sudo systemctl reload apache2

出力では、8.1-FPM設定の無効化、8.4-FPM設定の有効化、Syntax OKを確認できました。 reload後もApacheと8.4-FPMはactiveでした。

有効になった設定の接続先は、次の8.4用ソケットです。

SetHandler "proxy:unix:/run/php/php8.4-fpm.sock|fcgi://localhost"

記事作成時に確認したApache公式のmod_proxy_fcgiの例にも、UnixソケットをSetHandlerで指定する構成が載っています。 今回の設定では、このソケットが8.4-FPMへの接続先になっています。

ただし、設定ファイルの変更だけで切り替え完了とはせず、WordPress側からもPHPの版を確認しました。 切り替え後のサイトヘルスでは、PHP 8.4.27、SAPIはfpm-fcgi、メモリ・POST・アップロード上限はすべて512Mと表示されました。

WordPressで画面表示と画像処理を確認する

接続先の切り替え後は、次の項目を確認しました。

• トップページと記事ページが表示できる。
• 管理画面へログインできる。
• サイトヘルスがPHP 8.4.27／fpm-fcgiを表示する。
• メモリ・POST・アップロード上限が512Mである。
• 既存記事のコード表示とMermaid表示が動作する。

サイトヘルスのサーバー欄は、Web側の確認に使いました。 記事作成時に読み直したWordPress公式のサイトヘルス説明でも、この欄でサーバー構成やPHP関連の値を確認できることが説明されています。

さらに、新しいJPEG画像をアップロードして、サムネイル生成も確認しました。 入力に使った画像は640×480で、生成されたサムネイルは150×150です。 投稿編集画面で解像度を「サムネイル」にし、下書きのプレビューでも画像が表示されることを確認しました。

既存画像の表示に加えて、新規アップロードから縮小画像の生成までを確認できました。 この確認は小さなJPEG1点で行ったもので、大きな画像やすべての画像形式を試したものではありません。

Web側の切り替え後に、旧PHPを無効化する

Apacheに旧モジュールが残っていた

WordPressが8.4で動いていることを確認した後も、旧PHPの状態を調べました。 この時点では、8.1-FPMはまだactiveで、Apacheのモジュール一覧にはphp_moduleがありました。

有効なモジュール設定を読むと、PHP 8.1のlibphp8.1.soを読み込む指定が残っていました。 つまり、このVMにはFPMの接続先設定に加えて、ApacheへPHPを読み込むモジュール設定も残っていました。

サイトヘルスの8.4／fpm-fcgiという結果と、旧モジュールの有効設定が残っていることは、別々の確認事項です。 この記録だけから、旧モジュールがどのリクエストで使われていたかまでは断定していません。

旧FPMの参照と、ほかの用途がないことを確認した

停止前には、8.1-FPMのプール設定と、指定したcron・systemd設定の範囲で8.1への参照を検索しました。 プールはwwwと8.1用ソケットが見つかり、cron・systemd側の検索では8.1-FPMの自動起動設定が表示されました。

この検索結果に加え、このVMではほかのサイトやPHP処理を運用していないことも確認しています。 grepの検索だけで、サーバー上のあらゆる利用経路が存在しないと証明したわけではありません。

モジュールを無効化し、Apacheを再起動した

8.4-FPMの構文、稼働状態、ソケット、Apache側の有効設定を確認してから、旧モジュールを無効化しました。 主な操作は次のとおりです。

sudo a2dismod php8.1
sudo apache2ctl configtest
sudo systemctl restart apache2

実際のブロックには、構文確認やApache再起動が失敗した場合に、旧モジュールを戻す処理も含めていました。 今回は構文確認が通り、Apache再起動後もactiveであることを確認できたため、その後に8.1-FPMを停止し、自動起動も無効にしました。

sudo systemctl disable --now php8.1-fpm

実行後の状態は次のとおりです。

サービス	ActiveState	SubState	UnitFileState
Apache	active	running	enabled
PHP 8.4-FPM	active	running	enabled
PHP 8.1-FPM	inactive	dead	disabled

Apacheのモジュール一覧からはphp_moduleがなくなり、proxy_fcgi_moduleは残っていました。 さらに、稼働中のApacheプロセスを列挙し、それぞれの/proc/<PID>/mapsを調べています。

確認したApacheプロセス数: 7 / libphp8.1.soなし

この出力で確認したのは、そのとき列挙された7つのApacheプロセスに旧PHPライブラリーが読み込まれていないことです。 旧PHPのパッケージ自体は削除せず、無効化した状態で残しています。

最後に再確認したことと、今回の対象外

Apache再起動後に、トップページ、記事ページ、管理画面が表示されることを再確認しました。 サイトヘルスもPHP 8.4.27／fpm-fcgiで、メモリ・POST・アップロード上限は512Mのままでした。

画像アップロード・サムネイル生成・Mermaidの確認は、旧モジュール無効化とApache再起動より前に実施したものです。 再起動後の確認記録は、主要画面とPHPバージョン・SAPI・上限値の再確認までです。

また、今回の作業には次の検証は含めていません。

• スナップショットからの復元試験。
• VMそのものの再起動試験。
• エラー時の切り戻し分岐の動作試験。
• すべてのプラグイン機能の網羅テスト。
• 残っていたサイトヘルスの指摘の原因調査と解消。

今回の完了範囲は、PHP 8.4への移行、確認したWordPress機能の動作、旧PHPモジュールとFPMの無効化です。 サービスの自動起動設定がenabledであることは確認しましたが、VM再起動後の起動確認とは区別しています。