まだWordPressを触り始めたばかりの頃、ローカル環境で構築したサイトを、本番サーバーに手動で引っ越したときの話です。
「そんなことも知らなかったのか」と今なら思う内容なんですが、当時は本気で悩んだ末に、自力で1つずつ解決していった思い出深い出来事です。
ファイルをアップロードしただけでは動かない
WordPressの本体ファイルとデータベースをそのまま本番サーバーにアップロードすれば、それで引っ越し完了だと思っていました。
実際にアクセスしてみると、案の定エラーが出て表示されません。
エラー画面。
何が悪いのか見当もつかず、しばらく画面の前で固まってしまいました。
ここで初めて、「データベースへの接続情報も書き換える必要がある」ということ自体を知らなかったことに気づきました。
移行系のプラグインを使えば自動化できることも、この時はまだ知りませんでした。
今思えば、そもそも「サイトを引っ越す」という作業に何が必要なのか、全体像を把握しないまま見切り発車で始めてしまったのが根本の原因だったと思います。
💡 Tips: wp-config.phpとは
WordPressがデータベースに接続するための設定(データベース名・ユーザー名・パスワード・サーバーのホスト名など)が書かれているファイルです。ローカル環境と本番サーバーでは、この接続情報が異なるのが普通なので、引っ越しの際は必ず書き換える必要があります。
色々調べて、DB情報を書き換えた
「WordPress 引っ越し 表示されない」といった検索ワードで調べていくうちに、`wp-config.php`というファイルにデータベースの接続情報が書かれていることが分かりました。
FTPソフトでサーバーに接続し、該当のファイルをテキストエディタで開いてみると、ローカル環境用のデータベース名・ユーザー名・パスワードのままだったので、これを本番サーバーの情報に書き換えました。
接続情報を間違えると別のエラーが出るだけなので、1文字ずつ見比べながら慎重に作業を進めました。
本番サーバーの管理画面でデータベース名・ユーザー名・パスワードを1つずつ確認しながら、間違えないよう慎重に打ち込んだのを覚えています。
保存してアクセスし直すと、ようやくサイトが表示されるようになりました。
今度は画像とリンクがおかしい
サイト自体は表示されるようになったものの、今度は画像が表示されなかったり、内部リンクをクリックすると存在しないページに飛んだりする不具合が出てきました。
また不具合。
1つ直したはずなのに、まだ何かがおかしい。
調べてみると、WordPressはデータベースの中にサイトのURL(`siteurl`・`home`)を保存していて、投稿本文中の画像パスやリンクにもそのURLがそのまま埋め込まれていることが分かりました。
ローカル環境で構築していたので、データベースの中身は`http://localhost/…`のようなローカル用のURLだらけになっていたんです。
管理画面の「設定」からsiteurlとhomeだけは直せたものの、投稿本文の中に個別に埋め込まれたURLまでは、その画面からは直しようがありませんでした。
管理画面から1個ずつURLを直していったの?
それだと投稿の数だけ手間がかかっちゃうから、phpMyAdminのSQLタブから直接置換したよ。`wp_options`のsiteurlとhomeを書き換えて、`wp_posts`の`post_content`は`REPLACE()`関数でlocalhostのURLを本番URLに一括置換した感じ。
なるほど、1つずつ直すより早そう。
ただ「GUIDだけは触っちゃダメ」って調べてる途中で知って、そこは除外して慎重にやった記憶がある。当時は「SQLで一括置換」というやり方自体を知らなかったから、そこに辿り着くまでにも結構調べたんだよね。
初心者が引っ越しで踏みやすい2段階の罠
今振り返ると、今回の話は「DB接続情報の書き換え」と「サイトURLの一括置換」という、性質の違う2つの罠がセットになっていました。
前者を知らないとサイトそのものが表示されず、後者を知らないと表示はされても中身がボロボロになる。
どちらも手動での環境移行では避けて通れない工程で、初心者のうちはこの2段階があること自体を知らないまま最初の壁にぶつかりやすいんだと思います。
厄介なのは、1段階目を突破した安心感で、2段階目の存在に気づきにくくなることです。
「サイトが表示された、これで完了」と思い込んでしまうと、画像やリンクの不具合を見落としたまま公開してしまうこともあり得ます。
1つ目のゴールを、最終ゴールだと勘違いしないこと。
これは環境移行に限らず、色々な作業に通じる注意点だと思います。
まとめ
2段階の罠。
今では移行系のプラグインを使えば自動化できる作業ですが、当時は仕組みを知らないまま手動でやっていたので、遠回りしながら1つずつ理解していく形になりました。
結果的には、WordPressがどこにどんな情報を持っているかを理解する良い機会になったとも思います。
知らないなりに、1つずつ調べて解決できた。
その経験があったからこそ、今では新しい環境を構築するたびに「接続情報」「URL」「ファイルパス」あたりは環境ごとに変わるものだと意識するようになりました。
手動での引っ越し自体は今もう滅多にしませんが、移行系プラグインが裏側で何をしているかを、以前より具体的にイメージできるようになった気がします。
初心者のうちに一度こういう手動移行でつまずいておくと、後々仕組みへの理解が深まって役に立つ気がしています。
ちなみに今なら、もっと安全な選択肢があります。
All-in-One WP Migrationのような引っ越し専用プラグインを使えば、DB接続情報の書き換えもURLの一括置換も含めて、ほぼ自動でやってくれます。
どうしても手動でSQLを扱う必要がある場合も、生のSQL文で`REPLACE()`するのではなく、WP-CLIの`wp search-replace`コマンドを使うのが安全です。
WordPressのデータはシリアライズ(PHPの配列などを文字列に変換する形式)されて保存されている部分があり、生のSQLで雑に置換すると、この形式が壊れてテーマ設定やウィジェットの表示がおかしくなることがあります。
`wp search-replace`はこのシリアライズ形式を保ったまま安全に置換してくれるコマンドなので、今から同じ状況に直面する人には、まずこちらを検討することをおすすめします。
この記事が参考になったら、応援クリックをお願いします
