WordPress functions.php

WordPress の版は「7.1.3」のように数字が 3 つ並びます。最初の 2 つ（7.1）が変わるのが大きな版上げ（メジャーアップデート）、最後の数字だけが変わるのが小さな版上げ（マイナーアップデート）です。

この記事は、前に 6.4.3 から 6.5 に上げたときの手順をもとに、今の版でも使える形にまとめ直したものです。

バージョン番号の付け方 | WordPress.org

いつの間にかページがエラーになっていた。最新版に更新したらページが表示できなくなったというご相談を何度も頂いておりますのでバージョンアップの際にはご注意下さい。

すでに更新が終わっているかもしれません。サイトを開いて、表示や動きに問題がないかを確かめます。

または、問題が出ているところのカスタマイズを直すか、バックアップから戻します。

大きな版上げのときは、本番を写した作業環境で先に版上げを試します。本番でいきなり試さないようにします。

作業環境で一通り版上げして、次のところを確かめます。

動きがおかしいところは直し方を試し、難しそうなら版を戻す、と決めます。作業環境で方針を決めてから、本番でも同じ順番で版上げします。

バージョンアップ自体を行えないように制限を加えている場合もあるため、更新が行えるようにするための手順ともとに戻せるかの検証も行っておきます

作業環境でうまくいっても、本番で同じようにうまくいくとは限りません。本番の版上げの前には、必ずファイルとデータベースのバックアップを取ります。

自コンテンツであればカスタマイズ内容を把握できているので問題ないと思いますが、お客様環境のアップデートを行う場合はコアファイルにカスタマイズを加えていたりプラグインをカスタマイズしていたりすることがあるためアップデートで動作がおかしくなることもあります

上記の場合はWordPress、プラグインのダウングレードでは復旧ができないためバックアップがないと復旧ができません

本体とプラグインを同時に更新すると、不具合が出たときに、どれが原因かを探すのに時間がかかります。

1. WordPress 本体を更新して、表示と動きを確かめる
2. 問題がなければ、プラグインを更新して、もう一度確かめる

すぐに直せそうなら、そのまま直すこともあります。基本は、いったんバックアップから戻すか、版を戻して、作業環境でもう一度直し方を試します。

検証環境にて復元の手順を確認しておくことで本番で不具合が発生した際にもスムーズに対応が行えます。

確かめが終わっても、しばらくは様子を見ます。あとから「これが動いていなかった」と気づくことがよくあります。

様子を見るあいだは、エラーを debug.log に記録しておくと、不具合に気づきやすくなります。

// 版上げのあと、しばらくエラーを記録する（画面には出さない）
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // wp-content/debug.log に書く
define( 'WP_DEBUG_DISPLAY', false ); // 見に来た人の画面には出さない

様子見が終わったら、WP_DEBUG を false に戻して、debug.log も消しておきます（debug.log は外から見られる場所にできるため）。

何も問題が起きなければ、管理画面から更新ボタンを押すだけで終わる作業です。それでも、万が一のために、次の順番で進めています。

記事作成の最後の方で誤って別のボタンをしてしまい記事が消えたかと思ってゾッとしました。

この記事を書く前にリビジョンの設定変更を行っておりその時に無効にせずに保存件数を2件で設定していたのでなんとか再開ができました。

標準設定であれば今回の件は関係ない話なのですが高速化のためのリビジョンは無効化はおすすめしません。保存件数を2件など少なめに調整することを推奨します。