親テーマから子テーマへ切り替えると、Customizerの色、ロゴ、ヘッダー、追加CSS、メニュー位置などが「消えた」ように見えることがあります。主因は、多くのテーマ設定がtheme_modとしてアクティブテーマごとに保存され、親テーマと子テーマではstylesheet識別子が別になるためです。一方、サイトタイトルやプラグイン設定のような共通option、メニュー項目やウィジェットのデータまで一律に削除されるわけではありません。まず設定の保存単位を分け、バックアップ後に安全な移行方法を選びます。
子テーマは親テーマのコードを拡張する
子テーマは、親テーマを直接編集せずテンプレート、スタイル、functions.php、theme.jsonなどを追加・上書きする仕組みです。親テーマ更新でカスタマイズを失いにくい利点があります。しかし、子テーマを有効化するとWordPressにとってのアクティブstylesheetは子テーマになります。親テーマのPHPやテンプレートを継承しても、親テーマ用に保存されたすべてのCustomizer値を自動で同一視する仕組みではありません。
theme_modとoptionの違い
Customize APIのsettingには主にtheme_modとoptionがあります。theme_modはテーマ固有設定向けで、get_theme_mod()やset_theme_mod()から扱います。optionはサイト全体やプラグイン設定など、テーマを越えて使う値に向きます。テーマは通常、見た目の設定へtheme_modを使うべきだと公式文書で説明されていますが、実際の商用テーマや古いテーマは独自optionを使う場合もあります。画面名だけから保存先を推測しません。
- theme_modになりやすい：custom logoの添付ID、背景色・画像、header image、テーマ独自色・レイアウト、メニュー位置。
- 共通optionになりやすい：サイトタイトル、キャッチフレーズ、管理者メール、表示設定のホームページなど。
- 個別データ＋配置：ナビゲーションメニュー本体は残っても、テーマのmenu location割り当てはtheme_modで変わり得る。
- ウィジェット：ウィジェット設定は残っても、子テーマのsidebar IDやWidget Areaが違えば非アクティブ扱いや別配置になる。
- 追加CSS：テーマのstylesheetに関連付いたcustom_cssとして扱われ、子テーマ側で同じ表示にならない場合がある。
「引き継がれない」は削除ではないことが多い
親テーマへ一時的に戻すと設定が再び見えるなら、データが消えたのではなく、子テーマ用の設定セットが別に選ばれている可能性が高いです。ただし本番でテーマを何度も切り替えると、ウィジェット配置、キャッシュ、フロント表示、計測タグへ影響します。ステージングで確認し、本番ではメンテナンス時間と復旧手順を用意します。テーマを戻す前に現在の子テーマ側設定も記録します。
切り替え前に記録する設定
- Customizer各パネルをデスクトップ・モバイルのプレビューと一緒にスクリーンショットへ残す。
- ロゴ、favicon、背景、ヘッダー画像のメディア添付と元ファイルを確認する。
- 色、フォント、幅、サイドバー、投稿一覧、フッター、追加CSSをテキストでも記録する。
- メニュー本体と各location、Widget Areaと各ウィジェット、トップページ設定を一覧化する。
- テーマ独自インポート／エクスポート機能、ライセンス、親子テーマの対応版を公式文書で確認する。
- データベース、wp-content、アップロード、テーマ・プラグイン版の復元可能なバックアップを作る。
スクリーンショットには管理者メール、APIキー、非公開URLが映ることがあります。保護された変更記録へ保存し、公開チケットへ添付しません。バックアップは作成だけでなく、検証環境で復元できることを確認します。
ステージングで子テーマを有効化する
本番と同じWordPress、PHP、親テーマ、プラグイン、キャッシュ設定を持つステージングへ複製します。URL置換はシリアライズデータへ対応した正式な移行手段を使います。子テーマのstyle.cssに正しいTemplateヘッダーがあり、親テーマ名ではなく親テーマディレクトリ名を指定しているか確認します。functions.phpの構文エラー、二重関数名、親CSSの読み込み順も先にテストします。
最も安全なのは管理画面で再設定する方法
設定項目が少ないサイトでは、子テーマを有効化した後、記録した値をCustomizerから再入力し、ロゴやメニュー位置を選び直す方法が最も分かりやすく監査できます。保存時にテーマのsanitize callbackが適用され、現在版で無効になった古い値も見直せます。親テーマのoptionをデータベースで丸ごと複製する方法より、不要・互換性のない値を持ち込むリスクが小さくなります。
テーマ公式のエクスポート機能
商用テーマやフレームワークが設定エクスポート／インポートを提供する場合は、対象版、親→子の対応、含まれる設定、秘密情報、上書き範囲を公式文書で確認します。デモデータのインポートは既存投稿、メニュー、ウィジェットを追加・重複させることがあるため、設定移行と同じだと考えません。ステージングへ読み込み、件数と差分を確認してから本番で使います。
開発者が移行する場合は許可リストにする
多数サイトを移行する場合、開発者はWordPress APIで親側設定を読み、子側へ必要なキーだけをset_theme_mod()で保存する一回限りの移行処理を作れます。しかし全キーを盲目的にコピーすると、親テーマの内部キャッシュ、旧版フラグ、テンプレートID、シリアライズされた構造を持ち込み、子テーマで壊れる可能性があります。custom_logo、色、menu locationなど各キーの型、sanitize、参照先IDを確認した許可リストにします。
get_theme_mods()は現在のテーマ変更設定を返します。親と子のどちらがアクティブな時点で取得したかを記録し、ログへ値全体を出さないでください。テーマ設定には外部URL、HTML、トラッキングID、個人情報が含まれる場合があります。移行スクリプトは管理者権限、nonce／CLI権限、バックアップ、再実行防止、変更ログ、ロールバックを備え、完了後に削除または無効化します。
データベースのoptionを直接編集しない
データベースにはtheme_mods_...のようなoptionが見える場合がありますが、テーマslugの推測、シリアライズ、オブジェクトキャッシュ、マルチサイト、データ型、参照IDを誤るとサイトを壊します。phpMyAdminで文字列置換やコピーをせず、管理画面、WP-CLIの正式コマンド、WordPress API、テーマ公式移行機能を使います。どうしてもDB作業が必要な障害復旧は、専門担当者がバックアップとトランザクション相当の復旧計画を持って行います。
ロゴが消えた場合
custom logoは添付ファイルIDをtheme_modへ保存するのが一般的です。子テーマ側で未設定なら、メディアライブラリから同じ画像を選び直します。画像ファイルが残っているか、子テーマがcustom-logoサポートを継承・登録し、テンプレートがthe_custom_logo()を呼ぶかも確認します。親テーマのロゴIDをコピーしても、子テーマのheader.phpが出力しなければ表示されません。
メニューが消えた場合
メニュー項目そのものが削除されたとは限りません。外観→メニューまたはSite Editorのナビゲーションで既存メニューを確認し、子テーマが登録するmenu locationへ割り当て直します。親と子でlocationの識別子が同じでも、theme_modが別なら未割り当てに見えます。ヘッダーがブロック化されている場合はNavigationブロックがどのメニューを参照するか確認します。
ウィジェットが消えた場合
親テーマと子テーマでsidebar IDやWidget Areaの登録順が違うと、既存ウィジェットが「使用停止中のウィジェット」へ移る、別エリアに出る、表示されないことがあります。各ウィジェットの設定を記録し、子テーマの目的のAreaへ一件ずつ戻します。フォーム、広告、ショートコード、外部スクリプトを含むウィジェットは、表示だけでなく送信先、同意、キャッシュを再テストします。
追加CSSの移行
Customizerの追加CSSはテーマに関連して保存されるため、子テーマへ切り替えると同じCSSが出ないことがあります。親側の追加CSSを記録し、子テーマのマークアップでまだ必要かレビューします。不要な旧セレクター、重複、!important、古いブレークポイントをそのまま移さず、子テーマのstyle.cssまたは管理された追加CSSへ整理します。コメントに目的と対象版を残し、CSS内の外部URLや個人情報も確認します。
ブロックテーマでは仕組みが異なる
ブロックテーマではCustomizerが通常非表示で、Site EditorのGlobal Styles、theme.json、テンプレート、Template Part、ユーザー変更が中心です。子テーマのtheme.jsonは親より優先され、さらにユーザーがSite Editorで保存した設定が重なることがあります。クラシックテーマのtheme_modコピーだけでは移行できません。外観→エディターのスタイル、テンプレート、パターン、ナビゲーションを別のチェックリストで確認します。
プレビューで確認するページ
- トップページ、投稿、固定ページ、カテゴリ・タグ、検索、404。
- ログイン前後、会員、管理者、コメント、フォーム送信前後。
- ヘッダー、メニュー、ロゴ、パンくず、サイドバー、フッター、ウィジェット。
- スマホ縦横、タブレット、デスクトップ、ダークモード、200%ズーム。
- 日本語・英語など多言語、長いタイトル、画像なし投稿、空のウィジェット。
- キャッシュ初回／再訪、CDN、遅延読み込み、広告・解析・Cookie同意。
切り替え後の機能テスト
見た目だけでなく、フォームメール、検索、ページネーション、購入、ログイン、構造化データ、OGP、サイトマップ、計測、広告、アクセシビリティを確認します。子テーマfunctions.phpは親functions.phpを置き換えるのではなく、両方が読み込まれるため、同名関数やフックの二重登録が起きることがあります。PHPログ、Console、Network、WordPress Site Healthを確認します。
本番反映と戻し方
- 変更時間、担当者、対象版、バックアップ、監視、ロールバック条件を承認する。
- アクセスが少ない時間に子テーマを配布し、ファイルの所有者と権限を確認する。
- 有効化後すぐにトップ・主要導線・管理画面・PHPエラーを確認する。
- 記録済みのCustomizer／Site Editor設定を適用し、メニューとウィジェットを確認する。
- キャッシュを必要範囲だけ更新し、未ログイン表示と複数端末を確認する。
- 異常時は親テーマへ戻すだけで足りるか、DB・キャッシュ復元も必要か手順どおり判断する。
引き継ぎ台帳を作る
最終的に、設定名、保存種別（theme_mod／option／template／plugin）、親の値、子の値、移行方法、検証ページ、戻し方を表にします。次回の親テーマ更新、子テーマ変更、別サイト展開で再利用できます。テーマが独自settingを追加・削除したときは、リリースノートと台帳を更新します。
子テーマへ切り替えたときにCustomizerが初期化されたように見えても、まずtheme_modのテーマ別保存を疑います。手動再設定、テーマ公式エクスポート、許可リスト型のAPI移行の順で検討し、DBの丸ごとコピーは避けます。ブロックテーマはGlobal Stylesとテンプレートを別経路で確認してください。
コメント