概要
ローカルで整えた WordPress サイトのデータを本番へ反映する作業を行った際、新規サーバへの初回投入では問題なく動作した一方で、既存運用中の本番DBを置き換える形で反映した場合に、いくつかの不具合が発生した。
確認できた主な事象は以下の通り。
- 本番画面が真っ白になる
- 管理画面にログインできなくなる、または想定と異なるユーザー状態になる
- カスタム投稿タイプの詳細ページが 404 または
No posts foundになる - 管理画面の独自設定メニューが消える
- 本番テーマや本番権限が初期化されたように見える
このエントリでは、なぜ新規サーバでは発生せず、既存本番へのDB置換で発生したのかを整理する。
前提
対象サイトは、すでに本番運用されている WordPress サイトだった。
そのため、本番DBには単なる記事データだけではなく、以下のような本番環境固有の状態が含まれていた。
- 本番用の管理者ユーザー
- 本番用テーマ設定
- サイトURL
- プラグイン設定
- カスタム投稿タイプ運用に関する設定
- ユーザー権限
- 管理画面上の各種オプション
一方、ローカルDBにはローカル開発時点の状態が含まれていた。
- ローカル用ユーザー
- ローカルのURL
- ローカルのテーマ設定
- ローカルの権限状態
- ローカル開発中のオプション値
発生した症状
1. DB置換後に本番画面が真っ白になった
既存本番DBをローカル由来のSQLで丸ごと置き換えたあと、本番画面が白くなった。
この時点では、直接のPHPエラーや致命的エラー出力までは採取していなかったため、白画面の単一原因までは断定できない。
ただし、同時に本番の重要な設定テーブルまでローカル状態へ置き換わっていたことは確認できた。
具体的には、少なくとも以下のテーブルがローカル由来の内容になっていた。
wp_optionswp_userswp_usermeta
その後、これらのテーブルを本番の内容へ戻す構成に切り替えたところ、表示・権限・管理メニューまわりの問題は解消した。
このため、本番固有の設定・権限情報までローカル状態で上書きしたことが、有力な原因だったと判断している。
2. 本番テーマ設定がローカル側の値に変わった
ここでいう template / stylesheet は、管理画面の見た目の項目名ではなく、wp_options テーブルに保存される「有効テーマのディレクトリ名」 を指している。
実際の確認では、DB丸ごと置換後のある時点で、これらの値が本番テーマのディレクトリ名ではなく、ローカル側のテーマディレクトリ名になっていた。
一方、復旧後には本番テーマのディレクトリ名へ戻っていた。
つまり、既存本番環境が前提としているテーマ状態と、ローカルDBが持っているテーマ状態が一致していなかった。
この不整合が、表示不具合の要因の一つになった可能性が高い。
3. 本番の管理ユーザー情報が失われた
DB丸ごと置換では、記事データだけでなく wp_users と wp_usermeta も置き換わる。
その結果、本番で使っていた管理者アカウントではログインできなくなったり、ローカル用ユーザー状態になったりすることがあった。
つまり、既存本番で運用していたユーザー・権限情報までローカルで上書きされてしまう。
これは新規サーバでは問題になりにくいが、既存本番では大きな影響が出るポイントだった。
4. 管理画面の独自メニューが消えた
当初は「テーマコードが壊れたのではないか」と考えたが、調査するとテーマ側には独自設定メニューを登録するコード自体は存在していた。
最終的には、ログイン中ユーザーの権限不足 が原因だった。
その独自メニューは manage_options 権限を前提にしていたため、編集者権限では表示されなかった。
この問題も、wp_usermeta の置換によって、本番で期待していた権限状態とずれていたことが影響していた。
5. カスタム投稿タイプの詳細ページが 404 / No posts found になった
カスタム投稿タイプの詳細ページが開かず、404 や No posts found の状態になった。
ここで重要なのは、投稿データ自体はDB内に存在していたことと、テーマ側にも単一表示テンプレートおよびカスタム投稿タイプ登録コードが存在していたことだった。
つまり、「投稿が存在しない」「テーマファイルが無い」という問題ではなかった。
最終的には、rewrite ルールを再生成した後に詳細ページが解消したため、この事象については rewrite ルール未更新の影響が強かったと判断している。
rewrite についての補足
このサイトでは、もともとトップページからの遷移を成立させるために、過去に
AllowOverride- rewrite 設定
.htaccess
などの調整を行っていた。
そのため、今回発生したカスタム投稿タイプ詳細ページの不達は、単純に「DBを入れたら記事が消えた」という話ではなく、既存の rewrite 前提を持つ環境で、DB移行後に rewrite ルールの再生成が必要だったと考える方が正確だった。
実際には、データもテンプレートも存在していたが、rewrite の再生成後にページが正常化した。
なぜ新規サーバでは発生せず、既存本番では発生したのか
新規サーバでは起きにくい理由
新規サーバへの初回投入では、基本的に以下の問題を気にしなくてよい。
- 既存の管理者情報を守る必要がない
- 既存テーマ設定との整合を取る必要がない
- 既存プラグイン設定との競合がない
- 既存の rewrite 状態や運用権限を維持する必要がない
そのため、ローカルDBをそのまま初期データとして入れても、大きな矛盾が起きにくい。
既存本番では起きやすい理由
一方で既存本番には、すでに運用中の状態がある。
- 本番専用の管理ユーザー
- 本番専用のテーマ設定
- 本番URL
- 本番だけの権限状態
- 管理画面独自設定
- 運用中の rewrite 状態
この状態でローカルDBを丸ごと置換すると、本番が前提としていた状態そのものが消える。
その結果、表示、ログイン、管理メニュー、URL解決などが同時に壊れる可能性がある。
技術的に特に注意すべきだったテーブル
今回、特に影響が大きかったのは以下の3つだった。
wp_optionswp_userswp_usermeta
wp_options
以下のような、本番環境の動作に直結する値が入る。
siteurlhometemplatestylesheet- テーマ設定
- プラグイン設定
- 管理画面オプション
wp_users
本番のログインユーザー情報そのものが入る。
wp_usermeta
権限、管理バー表示、管理画面設定などが入る。
これらは単なるコンテンツではなく、WordPress の実行環境そのものに近い情報だった。
最終的に安定した方法
最終的に安定したのは、ローカルの投稿系データだけを反映し、options/users/usermeta は本番のまま維持する方法だった。
本番維持したもの
wp_optionswp_userswp_usermeta
置き換えたもの
wp_postswp_postmetawp_termswp_term_taxonomywp_term_relationshipswp_termmetawp_commentswp_commentmetawp_links
この形にすることで、
- 本番のログイン情報を維持
- 本番テーマ設定を維持
- ローカルの投稿内容を反映
という状態に落ち着いた。
今回の学び
1. 新規サーバ投入と既存本番DB置換は別の作業
同じ「DBを入れる」でも、初回構築と既存本番の置換では難易度もリスクも大きく異なる。
2. WordPress DBは「記事データだけ」ではない
DBの中にはコンテンツだけでなく、環境設定・権限・テーマ状態が混在している。
これを意識せずに丸ごと置換すると、運用中本番は壊れやすい。
3. options/users/usermeta は特に慎重に扱うべき
この3つは、移行対象というより「本番環境の中核」に近い。
投稿データと同じ扱いをしない方がよい。
4. rewrite は移行後の確認項目に入れるべき
データとテンプレートが存在しても、rewrite が古いと詳細ページは開かない。
移行後は rewrite 再生成を確認手順に入れるべきだった。
5. ロールバック用バックアップは必須
途中で復旧できたのは、事前にフルバックアップを残していたからだった。
既存本番DBを触る場合は、ロールバック前提で進めるべきだと痛感した。
まとめ
今回の問題は、WordPress のDBを単純な「コンテンツの入れ物」として扱うと起きやすい典型例だった。
新規サーバへの初回投入では問題なくても、既存本番環境には
- 既存ユーザー
- 既存権限
- 既存テーマ設定
- 既存URL
- 既存rewrite状態
がある。
そのため、既存本番へローカルDBを丸ごと入れる作業は、初回構築とは別物として扱う必要がある。
特に wp_options、wp_users、wp_usermeta は、本番を本番たらしめている情報として慎重に扱うべきだった。