WordPressの更新は何から進める？本体・テーマ・プラグインの対象と確認順

今回の更新対象と、影響する仕事を書き出す

管理画面の通知は、更新候補があることを知らせています。その通知だけでは、会社のサイトでどの機能へ影響するかや、更新後に何を試すべきかまでは決まりません。対象の名前を、使っているページと操作へ結び付けるところから始めます。

1. 対象を確かめる。WordPressの「ダッシュボード → 更新」や、テーマ・プラグインの各管理画面で、通知が出ている対象名を確認します。この段階では、まとめて更新を実行しません。
2. いまの版と候補の版を記録する。同じ対象名でも、出発する版が違えば確認すべき変更も変わります。取得できなければ未確認のまま、管理する制作担当へ照会します。
3. 利用者の仕事へ対応させる。フォーム関連なら問い合わせの入力と受付、テーマなら案内の表示やメニュー、といった具合に、実際に使うページと操作を挙げます。通知名から影響範囲を断定せず、制作担当が実装との関係を確認します。

会社側は「問い合わせ欄がある」だけでなく、必須項目の案内、入力の修正、必要な受付を区別して伝えます。制作担当は、それを支える構成を調べます。これにより、ソフトウェアの更新処理が終わったことと、会社の仕事に必要な機能を確認したことを分けられます。

WordPress公式のテーマ・プラグインの更新の説明では、更新画面のほか、各テーマ・プラグインの画面で更新を扱うことが案内されています。個別サイトの実施可否を判定する説明ではありません。

本体・テーマ・プラグインの版と依存を調べる

何を支える部品かを分け、候補の組合せで使えるかを調べます。本体は記事やページの管理などを支える土台、テーマは表示や配置に関わる仕組み、プラグインは必要な機能を追加するものです。同じ「更新」でも、文章の書き換えとは別の作業です。

候補版の条件を、現在の構成と照合する

制作担当は、提供元の更新内容と動作条件を読み、現在のWordPress本体、テーマ、関係するプラグイン、PHPの環境と照合します。PHPはWordPressを動かす側で使う言語・実行環境です。PHPの版を変える必要があるかは別途調べ、WordPressの通知が出たことだけを理由に、サーバー側まで一括変更する計画にはしません。

例えば、候補のプラグインが、現在とは異なる本体の版を条件にしていると分かった場合は、その条件を満たす道筋から検討します。逆に、現在の本体で使える候補だと確認できた場合でも、他のプラグインとの組合せや、会社独自の機能が動くことまで証明されたわけではありません。提供元の条件の照合と、自社構成での試験を分けます。

独自に変えた部分を把握する

制作会社へ、表示や機能を独自に変更した場所と、更新で置き換わる範囲を確認します。テーマ名を知っているだけでは、今回の案内ページがどこまで標準で、どこから独自実装かは分かりません。本体やテーマのファイル自体を変更している場合も、その扱いを更新前に制作担当が確認します。

WordPress公式の本体更新の案内には、更新対象のファイルへ加えた変更が失われる場合の注意があります。ここでは確認する対象の根拠として使い、手動削除・権限変更・認証情報の入力などを、一般的な実施手順へ転用していません。

問い合わせ欄と案内ページでは、確かめる操作が違う

次の二つは、説明用の別々の更新計画です。一つ目を直した結果が二つ目、という関係ではありません。どちらも、更新前の状態はまだ記録しておらず、更新作業も始めていません。

問い合わせ欄の計画には、フォーム関連プラグインの架空の通知があります。制作担当が入力条件と受付までの関係を調べ、会社サイト担当が必要な試験範囲を判断する想定です。互換性・戻す担当・試験先が未確認の間は本番を保留し、それぞれの確認先を指定します。

案内・メニューの計画には、テーマと本体の架空の通知があります。スマホで案内へ進み、本文とメニューを読めることが確認対象です。独自変更、本体との依存、作業後に見る箇所を確かめてから順を決めます。この記録には、具体的な順や更新後の成功はまだありません。

今回の対象は、どのページと操作につながる？

図では、二つの計画の「通知の対象」「影響する仕事」「確かめる操作」を同じ位置で見比べます。線は、対象と確認する仕事の対応を示します。更新が実行された順番や、原因から修復へ進んだ経過を示すものではありません。

説明図の原画を開く

問い合わせ欄では入力と受付、案内・メニューでは見た目と移動、と見るところが変わります。両方に同じ担当役を置いた架空例ですが、版・互換性・戻す備え・試験先は未確認です。図の対応を作っただけで実施可能にはせず、未確認の条件を確認してから作業順へ進めます。

保存一組・戻す担当・試験先をそろえる

更新を始める条件には、変更する対象だけでなく、問題が出たときにどう戻し、どこで試すかも含めます。会社側と制作担当で、次の三点を具体的に確認してください。

• 保存一組を特定できるか。対象サイトと保存時点が分かり、必要なファイルとDBの控えが対応しているかを確認します。DBは投稿や設定などを保存する場所です。「バックアップあり」という言葉だけで、その回の対象と保存結果まで確認済みにしません。
• 戻す担当と範囲が決まっているか。誰が保存物を取り出し、何をどこへ戻すか、判断する人へ連絡できるかを確認します。保存後に増える問い合わせや編集をどう守るかも、戻す判断の条件です。保存物の存在だけでは復元試験の結果を補えません。
• 公開先と分けて試せるか。試験先で今回の構成を確認できるか、会社側が確認するページと操作を利用できるかを調べます。実顧客へ通知が送られる状態のまま試さず、試験の宛先・データ・操作範囲を先に決めます。

保存する方法が未整理なら、ファイルとDBを一組で残す方法で対象を確認できます。保存した一組で動くかをまだ試していない場合は、本番と分けた復元テストの進め方へ進みます。本稿では、その手順を繰り返すのではなく、今回の更新を開始できる備えがあるかを計画へ結び付けます。

WordPress公式は更新前のバックアップを案内し、自動更新の前にも以前の版へ戻す備えを考慮しています。個社の保存物で復元できることを保証するものではありません。

そのサイトの更新順と、止める条件を決める

調べた依存関係から、作業と確認の区切りを決めます。制作担当は、現在の組合せから候補の組合せへ移る際の条件と、提供元・契約先で定められた手順を照合します。会社サイト担当は、影響する仕事と実施できる時間、判断に参加する人を確認します。

1. 先に満たす条件を示す。候補が必要とする本体や環境、独自変更の扱いを確認し、未確認のまま更新順を確定しません。複数の対象を一緒に扱う必要がある場合は、その理由と試験する組合せを残します。
2. 確認できる単位に分ける。どの変更の後に、どのページと操作を試すかを決めます。無関係な対象まで一度に変えず、結果を追える区切りにします。ただし、依存する変更を機械的に一個ずつ切り離せば安全、という意味ではありません。
3. 試験先で候補の構成を確認する。計画した条件で作業し、必要な表示と操作を確認します。結果が出てから、その版・構成を本番へ反映する範囲を判断します。試験したことと、公開先で結果を確かめたことは別です。
4. 実施時間と中断時の連絡先を決める。利用者への影響、作業・確認する人がそろう時間、受け付ける仕事の扱いを相談します。夜間やアクセスの少ない時間であることだけを、実施可能の根拠にはしません。

自動更新が有効な対象も、担当と確認を決める

自動更新の対象になっているかを確認し、実行された場合に誰が通知と結果を見るか、不具合時に誰へ連絡するかを決めます。有効にするかどうかや設定を変更する作業は、そのサイトの運用方針に沿って別途判断します。自動更新の設定があることを、問い合わせやメニューの確認まで済んだ証拠にはしません。

WordPress公式にはテーマごと・プラグインごとの自動更新の説明があります。本稿は設定変更を実行しておらず、自動更新で個別の機能や復旧が保証されるとも扱いません。

同じページと操作で、更新後と公開先を確認する

実施前に、見るページ、使う端末・ブラウザー、操作、期待する結果を決めて記録します。例えば、案内ページでメニューを開いて目的の案内へ移動する、問い合わせ欄で入力条件の案内を確かめる、といった利用者の仕事に合わせます。今回の二つの架空計画では、この更新前の記録はまだありません。

更新処理が終わったら、決めた条件で同じページと操作を試します。表示、移動、入力、必要な受付を分けて確認し、処理の完了表示一つでサイト全体が正常とは判断しません。試験用の送信は合意した宛先と範囲だけで行い、画面の完了案内と会社側の受付も区別します。

予想と違う表示や動作があれば、その状態のまま次の変更へ進めず、直前の変更対象、試した操作、期待した結果、実際に出た結果を制作担当へ伝えます。更新直後に起きたことだけで、そのプラグインやテーマが原因と確定するわけではありません。復元や設定変更の必要性と範囲は、担当が記録を基に判断します。

本番へ反映した後も、公開されているページで必要な結果を確かめます。試験先と公開先の構成や外部連携が違うなら、その違いも確認します。問題を直した場合は、問題が出た操作と、変更が影響する範囲を同じ条件で確かめ直します。

実際の比較条件やメニュー・問い合わせの確認方法は、サイト更新後の表示・操作・受付の確認手順で詳しく扱っています。今回は、その確認を誰が行い、何が分かれば今回の作業を終えられるかを、更新前の計画に含めます。

終了時には、実施した対象と版、確認できた結果、まだ試していない操作、問題が残る箇所を分けます。未実施の対象は失敗とせず、次に条件を確かめる担当へ残してください。次回の予定を決めたことも、今回の更新や公開確認の完了とは別です。