PHPを7から8にバージョンアップでWordPressが動かなくなった。解決方法と具体例
- 投稿日/更新日
表題の通りなのですが、サーバーのphpのバージョンを7.4から8.2に変更したところ、WordPressが動かなくなってしまいました。「まあ動くやろ~」と軽くバージョンアップのボタンを押したのでめちゃめちゃ焦りました。この記事では、どこに不具合があるのか発見するための手順や、実際にどこが悪かったのかを掲載しています。
そもそもPHPを変える必要ある?
リリース日 | アクティブサポート終了日 | セキュリティサポート終了日 | |
---|---|---|---|
8.0 | 2020.11.26 | 2022.11.26 | 2023.11.26 |
8.1 | 2021.11.25 | 2023.11.25 | 2024.11.25 |
8.2 | 2022.12.8 | 2024.12.8 | 2025.12.8 |
WordPress(6.2)の必須要件はPHP バージョン7.4以上ですが、すでにこのPHPはサポートが終了しています。8系統のバージョンは上記表の通りサポート終了日も決まっており、現時点(2023年5月)での最新バージョン8.2も約2年半後に終了することになっています。こう見るとPHPは毎年年末にリリースされていて、約3年間のサポート日であることがわかりますね。なので定期的に、早めに変更しておいたほうが何かと良いなと考えました。
このサイトのウェブサーバーはロリポップで、現時点では7.4~8.2までがあります。WordPressが速くなるLiteSpeed版はベーシックプランからになり、他のプランではモジュール版やCGI版になりますが、いずれもPHPのバージョン変更はボタンをポチッと押すだけです。ちなみに元にもすぐ戻せるので、とりあえずバージョンアップしてみるのも一つの手かも。仕事のサイトでは絶対しませんが。
PHPのバージョンアップでWordPressがどうなったか
「このサイトで重大なエラーが発生しました。対応手順については、サイト管理者のメール受信ボックスを確認してください。」とエラーが表示されました。サイトの表側だけでなく、管理画面でもログイン後にこの表示となるため、ブラウザでは何も直せないという事態になってしまいました。トラブルシューティングのリンク先にはいくつかの解決法が記載されていますが、この重大なエラーに関する解決策はありません。あとメールも来てません。かなり重度なエラーなのではと焦りつつ、コーヒーを飲むことにしました。
まずテーマを疑い、テーマを初期化する
PHPのバージョンアップに関わるところでいえば、テーマかプラグインではないかと予測できます。そこでテーマを無効化しました。やり方は簡単で、FTPでWordPressが入っているフォルダ/wp-content/themes/
の中を見て、使用しているテーマのフォルダをリネームするだけです。上図ではアンダーバーを入れましたが別名になればなんでも良いです。データベースの数値の変更などでもテーマを無理やり変更する方法もあるようですが、こっちのほうが手軽で早いですね。ちなみにこのサイトのテーマはすべて自作です。
この処置で管理画面に入れるようになりました。「使用中のテーマが~」と出てますが気にしなくてOKです。これで原因がテーマであることがわかりました。プラグインが悪い場合もフォルダ名を変更するなどして特定していくことが可能です。
ログファイルで分かることもあるかも
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );
define( 'WP_DEBUG_LOG', true );
ini_set( 'log_errors', 1 );
ini_set( 'error_log', WP_CONTENT_DIR.'/log_errors.log');
WordPressのwp-config.phpを修正して、さまざまなエラーをログファイルや画面に出力する設定が上記コードです。ロリポップの場合、ログ出力のフォルダをサーバーパスから指定しないと出力が確認できません。サーバーのフルパス(例:/home/users/1/*****/web/)や、WP_CONTENT_DIRなどを利用します。上記例ではwp-contentフォルダにlog_errors.logファイルが出力されます。ちゃんとフォルダの権限を755とかにしておきましょう。
しかし、今回のケースではログファイルなどには原因となる箇所は出力されませんでした。そういうケースも有るってことで。
どこが悪かった?
再度テーマを適用して、エラーがでることを確認します。今度はThemeフォルダの中のファイルをFTPでリネームしながら、どのファイルが悪いのかを特定していきます。そうすると、functions.php をリネームすると管理画面が表示されることを確認し、これが原因であることがわかりました。あとはfunctions.phpのソースをこまめに消してFTPでアップ、エラーがでなくなる箇所を突き詰めていく作業になります。もっと簡単にできればいいんだが。
今回の原因①
✕ add_filter( 'wp_sitemaps_enabled', 'false' ); ○ apply_filters( 'wp_sitemaps_enabled', 'false' );
従来、wp_sitemaps_enabledクラスはadd_filter関数で書いていたのですが、これがエラーになっていました。WordPressのリファレンスを見ると、apply_filters関数を使っていることがわかったので、これに置き換え。するとエラーが解消されました。PHPのバージョンアップとどう関係があるのかはわかりませんが。
今回の原因②
原因①を直したことで、管理画面が見られるようになりました。引き続きfunciton.phpでもエラーが出ていることが確認できます。行数まで出てくれるので原因の特定も早くて助かりました。この135行目を見て何がおかしいかわかるでしょうか。
✕return esc_url(get_theme_mod(set_img_url));
○return esc_url(get_theme_mod('set_img_url'));
関数の引数に使用する名前キーにシングルクォーテーションで囲むことが必要でした。逆に今までなぜ付けずに動いてたんだって感じもしますが。
✕ add_filter('posts_search_orderby', custom_posts_search_orderby); function custom_posts_search_orderby() { return 'post_date desc'; } ○ add_filter('posts_search_orderby', 'custom_posts_search_orderby'); function custom_posts_search_orderby() { return 'post_date desc'; }
こういった例もありました。custom_posts_search_orderby はfunciton関数名ですが、これもシングルクォーテーションで括ります。私の理解とコードの書き方がもともとおかしいのかもしれない。
さいごに
原因事態は単純でしたが、それを特定するまでが厄介でした。テーマやプラグインが怪しそうな場合は、FTPでリネームして原因特定といった力技が通じるのは発見でした。
備忘録として残しておきます。