親テーマ更新でカスタマイズが消えてしまうときの防止策
- 親テーマを更新したらカスタマイズが消えて「元に戻せない…」と焦っている
- functions.php やテンプレートを直接編集しており、今後の上書きを確実に防ぎたい
- 子テーマ運用やスニペット管理、ステージング確認の正しい手順を知りたい
WordPressレベル別 対応難易度
赤:外注推奨 オレンジ:条件付き自力可 緑:自力対応可
親テーマ更新でカスタマイズが消えるときの全体像と対応方針
カスタマイズ消失の大半は「親テーマの直接編集」が原因です。更新で上書きされ、テンプレートや functions.php の追記が失われます。
基本は「子テーマ・追加CSS・スニペット化」で“更新に強い構成”へ移行。
あわせてステージングでの事前チェックと差分バックアップを習慣化し、安心してアップデートできる体制を作りましょう。
親テーマ更新で追加分を消さない ~WordPressレベルごとのおすすめ対応
「直接編集をやめる」設計に切り替えよう
いちばん多いのが、親テーマのファイルをそのまま書き換えているパターンです。これだと更新のたびに上書きされ、カスタマイズが消えてしまいます。
やること: テーマ編集は親に触れず、子テーマにまとめる方針へしましょう。見た目の微調整は「外観 → カスタマイズ → 追加CSS」で管理すると安全です。軽いPHPの調整は「スニペット系プラグイン」に入れておくと、テーマ更新の影響を受けません。
運用の型: 更新前に必ずバックアップ(ファイル/DB)を取得してください。作業は深追いせず、迷ったら相談へ切り替える方が結果的に安く早いことが多いです。過去の修正が消えて困っている場合も、むやみに再編集せず、復旧の順番をプロと決めて進めるのが安全です。
よくあるNG: 親テーマの style.css/テンプレート(header.php、single.php など)/functions.php に直接追記すること。必ず「子テーマ」か「スニペット」で置き換えましょう。
子テーマ・スニペット・差分管理をセットで回す
オレンジレベルの方は「修正の置き場所」を整理できるとグッと安全になります。CSS は追加CSSまたは子テーマの style.css、軽いPHPはスニペット、テンプレートの構造変更は子テーマで処理しましょう。
子テーマの使い分け: 親のテンプレートをコピーして、編集は子側に限定します。親テーマの更新で修正が消えることを防ぎます。テンプレート内の細部は、可能な限り「フック(アクション/フィルター)」で差し込むと、将来の更新に強くなります。
ステージング必須: 本番でいきなり更新せず、ステージング(テスト環境)で親テーマのアップデートを事前適用し、デザイン崩れやフックの変更有無を確認します。OKなら本番へ反映します。
差分の見える化: 変更履歴はスプレッドシートなどでもOKですが、慣れてきたら Git で管理すると「いつ・どこを・なぜ」変えたか追跡しやすいです。週次のバックアップと合わせ、ロールバックの時間とコストを圧縮できます。
補助の工夫: Code Snippets などのスニペット管理プラグインを使うと、functions.php を触らずにフック調整が可能です。テーマを変えても引き継ぎやすく、再発防止に効きます。
フック中心設計・オーバーライド最小化・検証を自動化
緑レベルの方は「更新耐性」をKPIに設計します。テンプレートの直接改変を減らし、get_template_part() の分解やアクション/フィルターフックでの差し込みを優先。子テーマでのオーバーライドは最小限に抑えます。
運用フロー例: ① ステージングで親テーマ更新 → ② E2E or ビジュアルリグレッションで差分検出 → ③ 子テーマ/スニペットの互換確認 → ④ 本番反映。
可能なら CI で自動化し、更新サイクルを短縮します。
設計の原則: テーマ依存のロジックは極力プラグイン側へ退避し、“テーマ=見た目、機能=プラグイン”の責務分離を徹底。テーマ切替やメジャーアップデートが来ても影響を局所化できます。
リスク管理: 主要アップデートはリリースノートを精読し、テンプレート階層・フックの非推奨化・クラス名変更を事前に洗い出し。必要なら「一時ピン留め(更新見送り)」でウィンドウを管理しつつ、保守コストと機会損失のバランスを取ります。
カスタマイズの復旧や対策を外注する場合のポイント
「すでに消えてしまった」「再発させない運用へ移行したい」なら、外注が近道です。費用感と流れ、準備物を押さえておきましょう。
項目 | ポイント |
---|---|
費用の目安 |
・軽微な復旧(CSS再適用・スニペット化)… 10,000~30,000円 ・子テーマ再設計/テンプレート整理… 30,000~80,000円 ・ステージング導入+運用設計(Git/自動バックアップ)… 80,000円~ ・緊急対応(当日リカバリ)は割増になることがあります |
依頼の流れ |
1. 現状整理(テーマ名/バージョン/修正点の概要/消失時の操作) 2. 復旧優先度の合意(表示崩れ・機能停止など) 3. 事前バックアップ → ステージングで復旧案を検証 4. 本番反映 → 再発防止の運用設計(子テーマ化・スニペット・更新手順書) |
準備しておくと便利 |
・利用テーマ(親/子)とバージョン、購入元や配布元のURL ・消えたカスタマイズのリスト(覚えている範囲でOK) ・更新直前/直後のスクリーンショット、変更履歴(あればGitやメモ) ・サーバー情報(バックアップ手段・ステージング可否) |
親テーマの更新でカスタマイズが消える問題は、「親を直接触らない」だけで大半を予防できます。
赤は設計の切り替え(子テーマ・追加CSS・スニペット)を外注で一気に整備、オレンジはステージング+差分管理を習慣化、緑はフック中心設計と自動化で更新耐性を高めるのが近道です。
一度「消えた」経験があるサイトは、再発しやすいまま運用されがちです。更新前の手順と置き場所のルールを作り、安心してアップデートできる体制にしておきましょう。