WordPress 4.9.5はPHP 7.2との互換性が改善されてもPHP変更と同時に進めない

WordPress 4.9.5へ更新するときは、WordPress本体のsecurity updateと、serverで動かすPHPのversion変更を同じ作業にしません。4.9.5にはPHP 7.2 compatibilityの改善が含まれます。しかし、その記載はWordPress本体に入った修正を示すもので、theme、plugin、独自に加えたcode、server設定までPHP 7.2で動くと約束するものではありません。

WordPress.orgは4月3日、WordPress 4.9.5をsecurity and maintenance releaseとして公開しました。WordPress 4.9.4以前に影響する三つのsecurity issueと、PHP 7.2 compatibilityを含むmaintenance fixを案内しています。security updateを先延ばしにしないことと、変更を一度に増やさないことは両立します。まず本体の更新を確認し、PHPを替える必要があるなら、別の変更として準備します。 WordPress.orgの案内

4.9.5の修正とsite全体の互換性は別である

公式発表でいうPHP 7.2 compatibilityは、4.9.5に含まれる修正の一つです。これは、WordPress本体を更新する判断に関係します。いま使っているsiteのserver PHPを変更してよいかは、別に調べます。WordPress本体だけでsiteが動いているわけではないからです。

公開画面を作るtheme、追加機能を動かすplugin、問い合わせや予約を受けるform、外部serviceとの連携、独自のPHP fileは、それぞれserverのPHPで実行されます。WordPress本体がPHP 7.2への対応を改善したからといって、これらの組み合わせまで一度に確認済みになるわけではありません。更新画面に4.9.5と表示されることと、PHPの切り替え後に必要な業務が動くことも、同じ結果ではありません。

たとえば、更新通知を見てWordPressを4.9.5へ上げ、その流れでhostingのPHPも変更するとします。そのあとに問い合わせmailが届かなくなっても、WordPress本体の更新、PHPの変更、既存pluginの処理のどこを調べるべきか分かりません。急ぐべきsecurity updateの確認まで遅らせないためにも、変更の原因を増やさない順序を選びます。

更新の対象を三つに分けて記録する

作業前に、次の三つを別の行へ記録します。名称を一つにまとめると、更新した人と確認する人の会話が曖昧になります。

この表は、すべてを自分で更新するためのものではありません。serverの設定をhosting会社が管理し、WordPressの更新を保守担当者が行う場合でも、siteを所有する側は、どの変更が誰の範囲かを読めるようにします。作業を外部へ任せることと、変更履歴を受け取らないことは別です。

「PHPを上げる必要がある」と言われた場合は、現在のversion、変更する理由、対象のsite、themeとpluginの確認方法、戻す方法を聞きます。返事が「WordPressが対応したから」で終わるなら、WordPress本体の話とserverの話が混ざっています。どのPHP versionへ変えるのか、何がそのversionで動くかは、siteごとに確かめる必要があります。

security updateは先に適用し、確認範囲を狭める

WordPress 4.9.5は、WordPress 3.7以降のversionへ向けたsecurity and maintenance releaseです。自動background updateを使えるsiteでは、更新が始まっている場合があります。自動で更新できる仕組みがあることは、今回のsiteがすでに4.9.5へ変わり、公開画面も正常だという証拠ではありません。

まず、管理画面または管理記録で動いているWordPressのversionを確かめます。4.9.5へ更新する前には、戻すために必要な保存先と担当者を確認します。更新後には、サイトの最初のpage、問い合わせ先、投稿または固定pageの表示、管理画面で日常的に行う一つの操作を見ます。すべての画面を一度に試す必要はありません。売上、問い合わせ、予約、情報更新に関わる入口から優先して確かめます。

ここでPHPを替えない理由は、確認結果を読むためです。4.9.5への更新だけであれば、問題が出たときの調査対象はWordPress本体の更新と既存環境の組み合わせに絞れます。PHPも同時に替えると、serverの実行環境まで加わります。更新後の不具合を見つけたときに、元の状態へ戻す判断も難しくなります。

PHPを変更する判断は別の検証で行う

PHPのversionを変更する理由は、WordPress本体の更新と同じではありません。serverの提供終了予定、使うpluginの条件、hostingの方針などを確認し、変更が必要かを判断します。理由がある場合も、WordPressを4.9.5へ更新した記録と、PHPを変更する記録を分けます。

検証するときは、本番と同じ投稿や画像を増やす必要はありません。公開側では、主なpage、画像、menu、検索、問い合わせform、mailの受信を確認します。管理側では、login、投稿の保存、画像の追加、必要なpluginの設定画面を確認します。これは説明用の確認範囲です。通販、会員登録、予約、外部の業務systemを使うsiteでは、その事業で止められない操作を加えます。

確認する人も分けます。技術担当者はerrorや設定を見ます。siteの内容を決める人は、営業時間、料金、受付条件、古い案内が残っていないかを公開画面で見ます。PHPの切り替えで文字化けや画面のerrorがなくても、休業中の受付を表示していれば、事業として正しい公開状態とはいえません。技術上の動作と、読者へ出す内容は別の確認です。

更新完了はversionと公開画面を対応させて決める

更新を終えたら、「4.9.5へ更新した」という記録だけを残しません。更新日時、確認したWordPress version、確認したURL、試した操作、問題があった場合の対応を同じ記録へ残します。これがあれば、次にPHPを変更するとき、どこまでが4.9.5へ更新した状態だったかを区別できます。

反対に、更新後の画面だけを見て、versionの確認をしないのも不十分です。表示がたまたま開いていても、security updateが適用されていないかもしれません。versionの記録と公開画面の確認を一組にして、はじめて今回の更新結果を読めます。

最初の一手は、現在のWordPress version、serverのPHP version、使っているthemeとpluginの一覧を別々に書くことです。そのうえで4.9.5の更新だけを先に終え、更新後の確認記録を残します。PHPを替える検討は、その記録を基に別の作業として始めます。