WordPressの子テーマで変更を残すには｜保存場所・親テーマ更新・検収の整理

WordPressで子テーマを使っていても、サイトの変更がすべて子テーマのファイルに入っているとは限りません。親テーマ、子テーマ、管理画面に保存した設定、追加機能、独自の実装を分けて確認すると、更新後に何を保持し、何を再確認するかを説明できます。

この記事は、制作会社のWordPress実装担当と、既存サイトを引き継ぐ保守担当に向けたガイドです。子テーマの作成コードを一律に配るのではなく、変更箇所の一覧、親テーマ更新時の試験、復元と納品の範囲を整理します。特定サイトでの更新成功や互換性を保証するものではありません。

1．最初に、何の変更を保持したいか書き出す

見出しの色、詳細ページの構成、一覧の条件、入力項目、外部連携では、変更の保存場所と役割が異なります。「子テーマで作った」という説明だけで、すべての機能を移せると考えず、公開画面と更新の仕事から必要な変更を挙げます。

見える差分と、保存した場所を対応付ける

これは調査のための候補表です。使用中のサイトでどの場所が正本なのかは実物を確認します。表示が同じでも、保存方法が同じとは限りません。ソースの受領と、設定・データの受領も分けて記録してください。

2．子テーマが保持する仕組みと、その限界を理解する

子テーマは親テーマを利用しながら、子側に独自の変更を置く仕組みです。親のファイルを直接変更する方式では、親の更新で変更が失われる場合があります。子側に置くことで親のファイルへの直接編集を避けられますが、親の更新と子側の実装が互換である保証にはなりません。（WordPressの子テーマガイド）

子テーマの定義で参照する親ディレクトリ、上書きするファイル、読み込むスタイルを現在の構成で確認します。親テーマによってCSSの読み込み方が異なるため、別のテーマの設定例をそのまま貼り付ける方法は避けます。親への依存が大きい改修なら、その関係自体を記録します。

親の機能を大幅に作り替える必要がある場合は、子テーマが最適かを再検討できます。ただし、方式の検討と本番のテーマ切替は別の作業です。URL、入力や一覧、既存データ、保守負担を比較してから提案してください。

3．管理画面に保存した編集は、ファイルと別に扱う

ブロックテーマでは、サイトエディターなどで保存した編集が、テーマに含まれるファイルより優先される場合があります。子テーマのファイルを変更したのに画面が変わらないときは、保存済みのテンプレートやスタイルも確認します。すぐにファイルの変更が無効だと判断しないでください。

WordPressは、設定・スタイルの複数の層を扱います。テーマの定義とユーザーの編集を分けて調べることが必要です。（グローバル設定とスタイルの解説）使用中のテーマとWordPressでの保存状態を確認してから判断します。

画面編集をファイルへ移すか、保存した状態を維持するか決める

納品する変更がファイルだけで再現できるのか、DBの保存内容を組み合わせて再現するのかを決めます。既存の編集をリセットすればファイルが出るという理由で、未確認の本番編集を消す操作はしません。原本と差分、維持する編集、移す場合の試験・承認を揃えます。

同じ画面を複数の場所で変更し続けると、次の担当がどちらを編集するか迷う場合があります。見た目を再現できた段階で終えず、次回の修正場所と、保存した設定の受け渡し方法まで説明します。

4．functions.phpを、親の置き換えだと思わない

子テーマのfunctions.phpは、親の同名ファイルをそのまま置き換える仕組みではありません。親と子の両方が読み込まれるため、親の関数を丸ごとコピーすると同名定義などの問題を起こす可能性があります。（テーマのfunctions.phpの解説）

テンプレートの上書きと、関数や処理の追加を同じ方法で考えないようにします。関数名、フック、読み込み条件、必要な親機能、使用するデータを実装担当が確認します。既存の独自処理は「たぶん使っていない」と削除せず、利用箇所と依存を調べます。

表示の変更と、サイトの業務機能を分けて設計する

製品登録や入力項目、外部接続など、テーマを変えても残したい機能は、保存データと実装の置き場所を別に検討します。WordPressの更新画面を設計する方法と合わせると、表示のファイルと登録・保存の仕事を整理できます。

子テーマに追加できるという理由だけで、すべての機能をそこへ集める必要はありません。担当、配布・更新方法、ライセンス、障害時の切り分けも含めて、案件の範囲として決めます。

5．親テーマを更新する前に、試験条件を決める

更新する親の版、子の版、WordPress・PHP、主要な追加機能、現在の変更箇所を記録します。親の更新情報から、子が依存するテンプレートや処理への影響を調べます。更新情報に問題が書かれていないことだけで、対象サイトの互換性を断定しません。

試験環境では、本番の個人情報や通知を不用意に持ち込まないよう、複製前のデータ・メール・接続の整理を行います。更新前の画面と機能、原本、復元手順を保存して、合意した差分だけを試します。

6．本番反映後は、次の更新者が使う画面も確認する

試験結果が揃ったら、反映範囲、差分、復元点、作業中の更新、担当と承認を決めます。テーマファイルの反映と、保存した編集や設定の反映を混同しないようにします。サイト全体のDBを上書きすると別の更新へ影響する可能性があるため、戻す範囲も具体化します。

公開後は、ログインしていない画面で代表URLを確認し、PCとスマホ、境界の幅で長文・画像・表・メニューを見ます。編集側も、日常の権限で対象を保存・訂正できるかを確認します。制作側の管理者が操作できたことだけで、顧客が運用できるとは判断しません。

不具合は、対象URL、版、操作、期待した表示、実際の表示を記録します。新しい仕様の希望とは分け、復元か追加修正かを合意した手順で判断します。支障がない対象まで一括で作り直す必要はありません。

7．納品には変更一覧と、更新時の注意を添える

納品物には親と子の名称・版、変更ファイルと理由、設定や保存した編集、独自機能、必要なデータ、試験結果、未確認、更新担当と復元手順を含めます。公開画面を眺めるだけでは分からない依存を、次の担当が確認できる資料にします。

変更ごとに、次に触る場所を一つずつ示す

「色を変えるならこの設定」「一覧条件を変えるならこの処理」という形で、修正目的と場所を結び付けます。ファイル、DB、追加機能を別々に管理する場合は、どの版を組み合わせたかも残します。子テーマのZIPだけを渡して完全な復元資料としないでください。

親更新のたびに全部の画面を無条件に再制作するより、依存する変更と必要な試験を整理すると、工数の見積もりと未確認を説明しやすくなります。資料を自動生成できた件数ではなく、次の担当が正しく修正・確認できるかを評価します。

8．Acquaへは、変更の保存範囲と検収を相談する

制作会社の方は、デザイン、対象URL、親/子テーマ、既存変更、入力・業務機能、支給資料、納品形式をまとめてWordPress実装・保守の案内から相談できます。子テーマの作成だけなのか、既存の保存場所の調査や更新試験まで必要なのかを分けます。

企業の方が更新後の表示や編集に困っている場合は、Web制作・運用の案内から、対象画面と直前の変更を伝えてください。現在の構成と権限を確認して、必要な調査、修正、試験、保守の範囲と費用を合意します。

支援後は、必要な表示と機能が維持され、変更の正本と次の修正場所、親更新の確認対象、戻せる範囲が分かる状態を目指します。実装や引き継ぎを依頼したい場合はお問い合わせへ対象と困りごとをお知らせください。