だれかのなにかに役立てるウェブ制作者YoTaの趣味ブログ

マルチサイトで作成したwordpressのDB(データベース)を移動させる方法

wordpress

本ブログサイトにおいて、マルチサイトwordpressのデータベース移動をやってみたので、そのやり方について、備忘録的にメモします。

マルチサイトwordpressのデータベース移動の概要

今回、データベース引っ越しでやった作業は下記の通りです。

<マルチサイト>
親:siteURL.com/
子:siteURL.com/blog/

↓ 子のデータを親に移動。親のデータはまるごと削除

<作業後のサイト>
親:siteURL.com/

要点としては、wordpressのサブディレクトリ環境にあったものを親に戻したという具合です。

siteURL.com/blog/をブログサイト、siteURL.com/をweb製作請負サイトにしようと思っていたのですが、下記の理由で、やはりマルチサイトのサブディレクトリ構造を辞めることにしました。

・SEO的な問題
・しばらくウェブ製作請負の看板を掲げることもなさそう
(仮に掲げても、ブログがくだけすぎているため邪魔になる懸念。)

それでは、さっそく具体的な方法を下記に示していきます。

マルチサイトwordpressのデータベースの移動方法

まずはバックアップデータを取得しておく

本ブログで利用しているエックスサーバーではphpMyAdminが使えます。今回、改修することになるwordpressに該当するデータベースを選択して、エクスポートしておきます。ダウンロード時はzip形式をおススメします。(データ量が大きいと、ブラウザ負担になるため。)

dbmove1

それから、FTPソフトを用いて、wordpressのディレクトリ階層化にあるデータを丸ごと保存しておきましょう。BackWPupなどのプラグインにより、普段から自動バックアップを取得している人は、そのデータを利用しても問題ありません。

データベースの中身をローカル環境のphpMyAdminで検証してみる

出力したデータベースのファイルを、検証してみます。xamppなどのローカル上phpMyAdminを使用して、「testkiyo」と命名したテストのデータベースを作成し、インポートしてみましょう。文字コードはwordpressなので、utf8です。

dbmove2

インポートが成功すると、正常に終了したアナウンス画面が表示されます。

dbmove3

基本的に、空っぽのDBを用意しておけば、インポートはスムーズに成功します。もしインポートがうまくいかない場合は、いったん、そのデータベースの中身を削除してから実施するとスムーズです。(その際はバックアップはきちんと取得しておくこと。)

マルチサイトになったデータベースを確認する

dbmove4

インポートしたデータを見た時、wp接頭語に「_2」がついているものが、マルチサイトの子側(サブディレクトリ側)になっている部分のデータベースに該当します。つまり、「siteURL.com/blog/」にあったデータは「_2」のほうに存在します。これは、テキストエディタでsqlデータを直接見てみれば、すぐに分かります。「●●●_2_post」で検索してみると、ブログ記事が入っていることが分かります。

データベースは、簡単な操作であればphpMyAdminを使うのも良いかと思います。ただ、テキストエディタで見た方が、どのような構造になっているのか確認できますので、ちょっとした修正作業をする時は後者がおススメです。この後に実施する置換作業もテキストエディタでやったほうが遥かにスムーズです。

wordpressを使う方は、一度は確認しておいたほうが良いかと思います。データベースは「ある決まった文法ルールにのっとって、データが保存してある」というものですので、見ていれば、なんとなく構造を感じることができます。

DB移動作業1:マルチサイトの親側の不要データを削除する

今回、親のデータは削除しますので、wp接頭語「_2」がついていない方のデータは不要となります。左側のチェックボックスをクリックして、削除してしまいましょう。この時、分かる人は、テキストエディタで削除しても問題はないです。

ただし、この時に注意点があります。親側に存在する「●●●_usermeta」と「●●●_users」のテーブルは必ず残しておきましょう。これらはユーザー情報、ログインなどに関する内容になりますので、これらがないと、管理画面にたどりつけません。どうもマルチサイト側にはusersの情報を残さない仕様のようです。

ちなみに、user_login_logはプラグインcrazyboneで使用しているデータベースなので、存在しなくても問題はないです。もし「_2」側の方を活かしたいなら、そっちを利用すればOKです。

DB移動作業2:マルチサイトの「options」の「siteurl」と「home」のデータを書き換える

マルチサイト側のデータのため、「●●●_2_options」に保存されている「siteurl」と「home」の中身が「https://siteURL.com/blog/」に合わせたものとなっています。これを移動先に合わせたものへ修正します。

・siteurl = wordpressアドレス
・home = サイトアドレス

今回は、homeを「https://siteURL.com/」に修正します。もしローカル環境で確認作業をしたい場合は、ここの文字列を「http://localhost/******」などと設定してください。(******部分に、wordpressアドレスおよびサイトアドレスを設定する。)

これは、マルチサイトに関わらず、データベースの引っ越しをする際に、必ず実施する作業内容になりますので、覚えておくと便利です。

DB移動作業3:マルチサイトのwp接頭語を親側に戻すように修正する

本修正は、文字列の置換作業になりますので、テキストエディタで作業することをおススメします。

現状、データベースの各テーブルの名称のwp接頭語が、マルチサイト化した「●●●_2」になっているので、これを「●●●」に戻します。つまり、「_2」の部分を削除するということです。一括置換でも良いですが、勉強の意味も含めると、一個一個置換していくのもアリだと思います。

DB移動作業4:画像データの修正作業

マルチサイト化したwordpressの子側でメディア保存して作成した画像データは、通常の設定にしておくと、下記のディレクトリに保存されます。

「~/wordpressディレクトリ/wp-content/uploads/sites/2/日付(年号)/日付(月)/画像」

そのため、データベース上の文字列「sites/2/」を一括して削除します。そして、設定したディレクトリに合わせて、画像データも移動させましょう。この作業により、データベース移動後に、各記事などに使われる画像データがちゃんと表示されるようになります。

ここをそのままにしておくと、uploads階層化の画像データのディレクトリがぐちゃぐちゃして、ちょっと嫌な感じになってしまいます。また、制作方法によっては、一部の画像データが表示されなくなってしまうかもしれないので気をつけましょう。

DB移動作業5:FTPソフトにより、wp-config.phpを修正し、本番サーバー側のマルチサイト機能をオフにする

マルチサイト化をしているサイトでは、必ずwp-config.phpに下記の設定をしていたはずですので、マルチサイト関連のコードを忘れずに削除しておきます。

define('WP_ALLOW_MULTISITE', true);

こちらを削除せずに、データベースを反映させると、ログイン画面に入れず、エラーを起こします。

DB移動作業6:本番サーバーのデータベースに移行・反映させる

本番サーバーのデータベースに、修正したデータベースファイルをインポート(アップロード)して反映させます。この時、いったん、すべて削除してからインポートさせるとスムーズに移動できます。もし失敗しても、最初にバックアップしていたデータベースをインポートすれば元に戻ります。

反映がうまくいかない場合は、レッツ・トライアンドエラー。何度でも試してみてください。

DB移動作業7:テーマをあらためて設定する

テーマが外れているので、テーマをあらためて設定しましょう。その際、テーマ側にもディレクトリ変更による修正点があれば、一括置換して修正してから反映させましょう。

DB移動作業8:プラグインの再設定

プラグインが外れているので、有効化しておきましょう。

DB移動作業9:各種SEO関連の再設定

もしマルチサイト側のウェブサイトのURLで、アナリティクス・ウェブマスターツール・サイトマップなどに登録していたら、それらも修正しておくことを忘れずに。

まとめ

そもそも最初からマルチサイトなんてやっておかなければ良かった・・・。などと、後悔しつつも、結果的にはデータベースの勉強になったので、とても良かったです。

企業のウェブサイトなどでも、データベースなどがぐちゃぐちゃしている所は多いので、今回のマルチサイト解除のデータベース移動の記事が、なにかしらの参考になりましたら幸いです。

ページ上部に戻る