WordPress pluginの最小PHP versionは表示だけで判断せずserverとthemeの確認を分ける

WordPress pluginの配布ページに最小PHP versionが表示されても、それだけで自分のsiteへ安全に入れられるとは決まりません。まずserverで動いているPHPを確かめ、次に使っているthemeと既存pluginがその環境で動くかを試します。配布ページの表示は、導入を判断する入口です。本番の設定を変える合図ではありません。

WordPressのplugin directoryでは、pluginの作者が必要な最小PHP versionを指定できるようになりました。表示されたversionに満たない環境でも、現時点ではinstallを止める仕組みではありません。したがって、install buttonを押せたことと、公開中のsiteで問題なく使えることを同じに扱わない方がよいです。

配布ページの表示とserverで動くPHPは別に確かめる

配布ページの最小PHP versionは、pluginの作者が示した条件です。これは、siteが今どのPHPで動いているかを調べた結果ではありません。hosting serviceの管理画面、serverの設定、保守を担当する人の記録などで、実際に使っているPHPを確認します。FTPの接続先やWordPressの管理画面だけを見て、PHPのversionまで分かったつもりにならないようにします。

たとえば、配布ページに表示された最小PHP versionを満たしていないなら、pluginを先にinstallして様子を見る判断は避けます。PHPを替える必要があるなら、pluginの導入とは別の変更として扱います。PHPの切り替えは、WordPress本体だけでなくtheme、既存plugin、独自に加えたcode、mail送信やformの処理にも影響する可能性があります。一つのpluginを使いたいという目的と、serverの実行環境を替える作業を混ぜません。

反対に、表示された条件を満たしていても、動作が約束されたわけではありません。themeや別のpluginが古い書き方に依存しているか、独自codeがあるか、管理画面だけでなく公開画面にも処理があるかで、確認する範囲が変わります。最小PHP versionは不足を見つけるための条件であって、更新後の確認を省く印ではありません。

PHPを替える作業とpluginを入れる作業を分ける

PHPのversionを替える理由が出たときは、先に何を替えるのかを書き分けます。pluginを新しく入れる作業、PHPを切り替える作業、WordPress本体やthemeを更新する作業は、それぞれ戻し方も確認項目も異なります。同じ日にまとめて行うと、表示が崩れたときにどの変更が原因かを追いにくくなります。

説明用の仮例として、予約を受けるpluginを追加したいsiteを考えます。配布ページの最小PHP versionを見て、serverのPHPが条件に届かないと分かりました。このときは、予約画面を早く出すために本番のPHPを直ちに切り替えるのではなく、まず現在のsite構成を記録します。使用中のWordPress本体、theme、plugin、独自に置いたfile、予約を受ける既存の方法、mailの送信先を確認します。そのうえで、PHPだけを替えた検証環境を作るのか、先に別のpluginを選ぶのかを決めます。

確認する人も分けます。制作会社がthemeやpluginを扱い、hosting serviceの契約者がserver設定を持つことがあります。この場合、制作会社へ「PHPを上げてください」とだけ頼んでも、誰が変更を承認し、誰が契約画面へ入り、異常時に戻すかが決まりません。作業を委託することと、server accountを所有し変更を許可することは別です。契約者、作業者、公開確認をする人、問い合わせを受ける人を先に決めます。

本番へ入れる前に見る順序を決める

確認は、配布ページの表示から始め、いきなり本番の変更へ進まないようにします。最初に現在のPHPとWordPress、theme、pluginの一覧を残します。次に、追加したいpluginの配布ページに示された最小PHP versionを確認します。条件が合わない場合は、PHPの変更が必要なのか、別の方法を選ぶのかを判断します。

PHPを替えると決めた場合は、公開中のsiteと分けた場所で試します。管理画面へloginできるか、主要なpageが表示されるか、formが送れるか、mailが届くかを、siteの役割に合わせて確かめます。予約を受けるsiteなら予約の入口と完了画面を見ます。通販なら商品表示、注文の入口、支払いへ渡す前の画面を見ます。単にtop pageが開くかだけで終わらせません。

検証で問題がなくても、本番で行う時間と戻す手順を決めます。変更前の状態をどう残すか、表示やmailに不具合が出たとき誰がどの状態へ戻すか、作業中の問い合わせをどこで受けるかを決めます。本番のserver設定を変えたあとに、原因を探しながら連絡先を決めると、復旧までの時間が延びます。

pluginをinstallするのは、PHPの確認と切り替えが済んだあとです。install後は、有効化した直後の管理画面だけでなく、pluginが加える公開画面、設定画面、送信処理を確認します。使わないpluginを試しに残す理由はありません。採用しないと決めたものは、検証の記録を残して整理します。

最初の一手は、配布ページの最小PHP versionと、現在serverで動くPHPを書き並べることです。二つが違うなら、pluginの話を進める前に、PHPの変更を誰が承認し、どこで試し、何を確認して戻すかを決めます。表示を読むことより、siteを動かす責任の範囲をはっきりさせる方が先です。