三つの構成要素を区別する
| 要素 | 主な役割 | 更新で確認する箇所 |
|---|---|---|
| WordPress本体 | 投稿管理、認証、APIなど | 編集、保存、ログイン |
| テーマ | テンプレート、装飾、表示処理 | 全ページ種別、独自機能 |
| プラグイン | フォーム、SEO、ECなど | 保存データ、連携、送信 |
MUプラグインや独自コードも棚卸しに含めます。管理画面の通常プラグイン一覧だけで全体が把握できるとは限りません。
更新は依存関係の確認から始める
プラグインが要求するWordPress版とPHP版、テーマが依存する機能を照合します。例えば先にPHPを上げる必要がある製品と、PHP更新前に改修が必要な独自コードが共存する場合は、検証環境で段階的な移行が必要です。
変更が失われる場所を見つける
親テーマやプラグイン本体へ加えた直接変更は、更新で上書きされる可能性があります。子テーマ、独自プラグイン、DB内の設定のどこに変更があるか確認し、差分を保存します。子テーマなら何でも保護できるわけではなく、親側の仕様変更にも追従が必要です。
管理台帳に最低限記録するもの
製品名・配布元・版・ライセンス・用途・依存先・変更箇所・管理者を記載します。更新を保留する場合は理由と期限を加え、担当者が変わっても判断できる状態にします。
仕様変更を把握するための読み方
製品の変更履歴では、新機能、バグ修正、セキュリティ修正、必要環境の変更を分けて読みます。見出しだけで分からない場合は提供元の案内を確認します。表示を担当するテーマが独自投稿やフォームの呼出しも含むなら、テーマ変更は見た目以外にも影響します。
依存関係を台帳に記録する例
「テーマAはプラグインBの独自フィールドを表示」「フォームCはメールサービスDへ送信」のように、製品名と利用箇所を結びます。製品を削除する場面でも、どのページを確認すべきかが分かります。
よくある判断の誤り
製品名だけを一覧にして、独自コードやMUプラグインを外すと構成が欠けます。配布物と実ファイルに差がある場合も、更新通知だけでは把握できません。管理画面の情報とファイル・設定・契約資料を照合します。
親テーマを更新しなければ子テーマは安全ですか?
親テーマの修正が止まるため、安全性を保てるとは限りません。子テーマの互換性を検証しながら、親側の更新も継続する方針を考えます。