WordPressでPHP8.1にアップグレードした体験

WordPressで構築しているサイトにおいて、PHPのアップグレードは定期的にすることです。しかし、エラーが発生しPHP8.1にアップグレードできませんでした。この解決法とその模索方法を示します。

写真1. アップグレード(ホームドア)に対応できないものは引退せねばならない(金沢八景で撮影)

補足

記事にコメントのある通り、コード上の問題点は解決されています。したがって、現在当該のサイトさんのコードを適用してもPHP8.1にアップグレードできます(2023年9/16追記、補足ここまで)

PHP8.1にアップグレードした際のつまづきと克服方法

PHP8.1にアップグレードできなかった原因と対策は以下の通りです。

• Contact Form 7でサイトが重くなる？ページ全体で読み込まれるJSとCSSを固定ページのみで読み込ませる方法。で示されたコードが問題の発端であった
• 上記原因を追究するためにローカル環境を構築して検証した

詳細な内容を以下に記します。

PHPのアップグレードの一般的な方法

PHPのアップグレードはそう難しくありません。お使いのレンタルサーバーにアクセスし、PHPの設定を変えるだけです。私が契約しているロリポップちゃんでは以下の通りです。

1) PHP設定を開く

2) PHPのバージョンを選択し、変更をクリック

図1. PHP設定変更の手順(私はサブドメインも同様に変更しました)

通常はこの設定で終了です。なお、PHPの設定は元に戻せることがほとんどです。何かしらエラーが発生したら、元に戻せば良いだけです。

ところが、私はこの設定変更後、サイトが表示されなくなりました。とりあえずPHP7.4に戻しました。ただし、PHP7.4のサポート期限もありましょう。そのため、放置するわけにもいきません。もう一度PHP8.0に設定変更したところ、通常通り表示され、なおかつ速度も上がっていたので、とりあえずこれで良しとしました。

とはいえ、いつまでもアップグレードできないといつかは時代から取り残されるでしょう。そこで、原因を追究することにしました。

原因追及の方法：ローカル環境の構築

写真2. ファンがいつもと異なる風景を検証している様子(2018年の川崎駅工事の際に撮影)

本番の環境で検証するのは手間があまりにも大きいです。そのため、今回はローカル環境で試して仮説を立て、それを本番の環境で確認することにしました。

プラグインの影響も考え、PS Auto Sitemap(長年更新されていない)を削除(プラグインなしでサイトマップを表示させる方法は別記事で紹介しています)しました。これによる改善はありませんでしたが、これを機にプラグインを1つ削除できたことは大きいです。

Step1. ローカル環境の構築

写真3. ローカル環境では接続に問題ない(左上のサイト名が「鉄道ラボローカル」となっていることがわかると思います)

ローカル環境はいわば「PCのなかでサイトを構築する」ということです。外部との接続はなく、テストするには良い環境です。製造業で実際の機械で試作する前に、テスト機で試作と検証すると例えるとわかりやすいかな(かえってわかりにくい)？

今回はMAMPを活用しました。英語によるサイトでわかりにくいですが、参考サイトを見ながら導入しました。このときMAMPのPHP設定をPHP8.1としました。PHP設定を8.1にして、サイトは通常通り開けました(写真3)。

※ローカル環境のサイトをお気に入りに登録し、ログイン画面にアクセスしようとするとログインできないことがあります。このときはMAMPを起動し、「Start Service」をクリックしましょう。そうしないとローカルサーバーに接続できていないことになります。

つまり、WordPress6.1.1とPHP8.1の相性には問題ないことがわかります。

Step2. テーマを導入

この要領で、テーマ・プラグイン・PHPの記述を現実に近づけていきます。導入のたびに表示に問題ないことを確認し、問題が発生した直前に加えた変更点が原因の可能性が高いと推定することにしました。そこでさらに細分化して検証します。大きな変更点から検証するのが良いでしょう。そこで、テーマ→プラグイン→PHPの上書きの順に検証しました。

次にテーマを導入します。私はSimplycity2を導入していますので、同テーマの親テーマと子テーマの最新バージョンをそれぞれ導入しました(このテーマはPCにいったん保存し、そこからアップロードする必要があります)。導入の結果、問題は生じませんでした。

よって、Simplycity2はPHP8.1で問題なく動作することが明らかとなりました。

Step3. プラグインの導入

次に弊サイトで導入しているプラグインをローカル環境に導入しました。弊サイトで導入しているプラグインは以下の通りです。

1. Advanced Editor Tools
2. Akismet Anti-Spam (アンチスパム)
3. Autoptimize
4. Contact Form 7
5. Converter for Media
6. Google XML Sitemaps
7. Kattene
8. List category posts
9. SiteGuard WP Plugin
10. TablePress
11. WP Multibyte Patch

2022年4月時点でプラグインを13に減少させていますが、ここからさらに2つ(Classic EditorとPS Auto Sitemap)削除しています。もう少し減らすように鋭意努力中ですが、現在はこのような陣営です。

これら11のプラグインを導入しても、PHP8.1環境でも適切に動作いたしました。つまり、以下のプラグインは問題ないということです。

Step4. PHPファイルの動作確認

私はサイトの機能向上を目的として、テーマのための関数 (functions.php)に多くの記述を加えています。PHPのバージョンアップは当然PHPファイルに影響を与えます。そのため、CSSファイルではなく、PHPファイルを検証対象としたのです。

本番環境で加えている記述をローカル環境のテーマのための関数 (functions.php)に加えたところ、サイトが表示されませんでした。そのため、ここが問題と判断しました。

しかし、全てが原因ということはなく、テーマのための関数の一部が原因なのでしょう。そこで、(ローカル環境のWordPressサイトではなく、PCの)ローカルサーバーからテーマのための関数 (functions.php)を開き、一部の記述を抜いたりしながら原因を探ったところ、以下の記述が原因でした。

1. //contactform7css&style削除
2. add_action( 'wp', function() {
3. if ( is_page( 'contactus' ) ) return;
4. add_filter( 'wpcf7_load_js', '__return_false' );
5. add_filter( 'wpcf7_load_css', '__return_false' );
6. });
7. add_action( 'wp_enqueue_scripts', 'enable_wpcf7_load' );

なお、一時的にデバックを表示させるようにし、以下のエラーをログに残していました。

PHP Fatal error: Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, function "enable_wpcf7_load" not found or invalid function name in class-wp-hook.php

このエラーを見てもわかりませんでした(WordPress本体のclass-wp-hook.phpを見てもこのような記述はありませんでした)が、その原因はテーマのための関数にあったのでした。

Step5. エラーの原因を修正し、アップグレード

テスト環境のローカル環境でテーマのための関数(function.php)の「//contactform7css&style削除」が原因とわかりました。そこで、弊サイトの本番環境でも同様に当該部分の記述を消去しました。この記述は表示速度向上のために取り入れたものですが、PHP8.1にすればスピードアップできるので表示速度向上のための小細工は不要と判断しました。

テスト環境で検証した通り、当該部分の記述を抜いてPHP8.1にアップグレードできました。よって、//contactform7css&style削除が原因という推定は確信に変わりました。このように段階的な変更で不具合の有無を確認し、不具合箇所を推定することができました。

PHP8.1での効果

写真4. 旧車両がなくなった効果はどうなのだろう(2018年に名鉄西尾線で撮影、名鉄の一般車から写真のような2ドア車は引退済)

では、PHP8.1にして効果はあったのでしょうか。PageSpeed Insightsで確認した結果を公表します(表1、表2)。

表1. モバイルでの確認結果

	PHP7.4	PHP8.1
LCP	2.6秒	2.6秒
FID	21ミリ秒	21ミリ秒
CLS	0.13	0.13
FCP	2.2秒	2.2秒
INP	240ミリ秒	240ミリ秒
TTFP	1.3秒	1.3秒
パフォーマンス	70	73
適切なサイズの画像	2.55s	2.4s
最初のサーバー応答時間	0.72s	表示されず
使用していないCSS	0.45s	0.3s
使用していないJavaScript	0.45s	0.45s
レンタリングを妨げるリソース	0.15s	0.15s

表2. PCでの確認結果

	PHP7.4	PHP8.1
LCP	2.6秒	2.6秒
FID	2ミリ秒	2ミリ秒
CLS	0.14	0.14
FCP	2.3秒	2.3秒
INP	52ミリ秒	52ミリ秒
TTFP	1.2秒	1.2秒
パフォーマンス	94	93
適切なサイズの画像	1.04s	1.04s
最初のサーバー応答時間	0.82s	1.13s
使用していないCSS
使用していないJavaScript		0.24s
レンタリングを妨げるリソース

パフォーマンス以下の項目に着目しました。モバイルのパフォーマンス値は70から73に上昇していました。その要因は「最初のサーバー応答時間を速くしてください」という項目の改善値が0.72秒から表示されなくなったことでしょう。PCについては「最初のサーバー応答時間を速くしてください」という項目の改善値が0.82秒から1.13秒に上がったためか、パフォーマンス値は94から93に低下しました。

(単純な算術平均で議論するのはいかがかという指摘もあると思いますが、)スコアの平均値が82から83に上昇したことと、作業していて表示速度が上昇したことから、(表示速度面において)PHP8.1にした効果は大きいと確信しています。また、これによるデメリットも特にないことから今後とも継続いたします。

PHP8.1に変更してみて

写真5. 急行ができてアップグレードされた路線の例(東武アーバンパークライン)

PHP8.1に変更することによる不具合があったものの、原因を突き止めて修正したうえでアップグレードできました。このときに検証した手順は、まっさらな環境から本番環境に徐々に近づけ、不具合が生じた前後での差異を細かく検証するというものです。そして、これは汎用的な方法であり、(サイト作成に限らず)さまざまな場面で役立つことでしょう。自分自身のスキルアップにも役立ちました。

このような検証方法を体系立てて記している記事はみつからず(私の探しかたが悪い？)、改めて執筆した次第です。