先に謝ります、何かすいません。。。
さて、話しを本題に移しますが、Webサイトをリニューアルする際、運用中のサイトはそのままで、開発環境を別で用意して構築を進めるというやり方は、比較的よく行う施策だったりします。
開発環境を分けるメリットとして、構築中の未完成の Webサイトをエンドユーザーに見られなくて済むため、大胆なリニューアルを行うことが出来ます。（開発環境は非公開領域として認証をかけます）
ただ、開発環境と運用環境の組み合わせは無数にあり、中には聞いたことも触ったこともないようなサーバーにて構築・移行しなければならないこともあり、調べながらトライ & エラーを繰り返すつまずきどころでもあります。
今回、マルチサイトの移行を行い、やっぱり色々つまづきました。そこで、マルチサイトを移行する際の手順や気を付ける点など、経験を元にご紹介致します。
WordPressマルチサイトとは
1つのサーバーで Webサイトの数だけ WordPressをインストールして運用することは一般的です。
しかし、WordPressの機能として、1つの WordPressを使って複数の Webサイトを運用することが出来ます。これがマルチサイトです。
マルチサイトはそのままでは機能せず wp-config.phpファイル内、「/* 編集が必要なのはここまでです…」と書かれた箇所より上に、以下内容を追記します。
- wp-config.phpに追記する内容
-
// マルチサイト機能の有効化 define('WP_ALLOW_MULTISITE', true);
機能が有効化されると管理画面から設定が出来るようになりますが、詳しい内容は後日改めてご紹介させていただきます。
マルチサイトを、例として「vektor-inc.co.jp」で運用する場合、
- サブディレクトリ型
- vektor-inc.co.jp/hogehoge/
- サブドメイン型
- hogehoge.vektor-inc.co.jp/
- 複数ドメイン型
- hogehoge.com/
のうち、いずれか一つの方法を選択して運用を行います。
マルチサイト移行の前提条件
今回のマルチサイト移行は、「さくらサーバー」から「GMO iCLUSTA」へ以下条件のもと行いました。
- 本部 + 運用施設（複数）という構成のため、マルチサイト（サブディレクトリ型）にて構築
- 実積のあるサーバーを提案したが、既存の環境を継続することになった
- 開発初期、移行先で稼働していたサーバーは「GMO InfinitoPLUS」だが、サービス終了に伴って GMO側にて新サービス「GMO iCLUSTA」に移行することが決まっていたため、開発環境は弊社で運用中の「さくらサーバー」環境とした
- 「GMO iCLUSTA」に切り替わった段階で開発環境を移行し、ディレクトリを切って本公開まで引き続き構築する
- 本公開の際には、URLの調整を行い 301リダイレクトも行う
- 「GMO iCLUSTA」は phpMyAdminを標準搭載していないため、DBManagerという機能を使って sqlファイルをインポートする
- phpMyAdminを使いたい場合は、稼働中の MySQLが 5.1系のため、4.0.10系を落として使う
- SSH接続はサポートしていないため、コマンドは使えない
マルチサイトの移行
それでは、順を追ってマルチサイトの移行について触れて参ります。
WordPress 構築データのダウンロード
WordPressの移行には、必要最小限のファイル（画像やテーマ、プラグインなど）のみを FTPクライアントやコマンドで落として、移行先に用意してある WordPress環境にアップロードするやり方や、必要なファイルを含む「wp-content」ディレクトリ一式をドコーンっと落として、移行先にドコーンっとアップするやり方などございます。
落とすファイルが少なければその分、ダウンロードにかかる時間も少なく済むので効率的ですが、今回はマルチサイトの移行ということで、何かしら影響が出ても怖いなと、WordPerss丸ごと一式をドッコーンっと落として対応することにしました。
ただ、コマンドが使えないので FTPクライアントでじっくり時間をかけて落とすハメとなり途中、クライアントがタイムアウトを起こしてファイルが落ちてこず、何度かに分けて差分を落とすという何ともな感じでとても非効率でした。
- ポイント
-
FTPクライアントでタイムアウトを起こしてファイルが落ちなくなったら、改めて落とす必要がありますが、全部落とすのではなく差分のみを落とす設定にしておくことが重要です。
FFFTPをお使いの場合、転送キューもクリアしておくと、進行状況が分かりやすくなり残りの目処が立ちます。メニューバーにある「編集」→「個人情報をクリア」→「転送キューをクリア」にチェックを付けて OK。確認ダイアログも OKでクリア完了。
データベース（MySQL）のエクスポート
phpMyAdminを使って MySQLをエクスポートします。
さくらサーバーだと、サーバーコントロールパネルから「データベースの設定」→「管理ツール ログイン」で、ログイン画面にアクセス出来ますので、ユーザ名 / パスワードを入力してログインして下さい。
該当するテーブルを選択してエクスポートしますが、その際、下図「DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT を追加」のチェックが外れていたらチェックを付けておきます。
シングルサイトであれば圧縮をかけずにエクスポートすることもありますが、マルチサイトである程度作り込みをして容量が膨らんでいるため、圧縮をかけてエクスポートします。
- ポイント
- 移行先の環境によっては、データベースにインポートするファイル形式を推奨しているケース（例：gzip形式など）もございます。念のために確認をしておきましょう。
WordPress 構築データのアップロード
時間をかけて落とした WordPress一式をアップロードします。稼働中の環境にアップロードするため、ディレクトリを切ってその中に展開します。
- ポイント
- 上記タイミングが本公開に向けての移行であれば、直接ルートにアップロードした方が、URLの調整など余計な手間がかからずスマートです。
.htaccessを修正
移行先の環境に合わせて「RewriteBase」及び「RewirteRule」の最後の行を修正します。例として、移行元はルート直下、移行先は「wp」ディレクトリ内とします。
- 移行元環境
-
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] # add a trailing slash to /wp-admin RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L] RewriteCond %{REQUEST_FILENAME} -f [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^ - [L] RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L] RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L] RewriteRule . index.php [L] </IfModule>
- 移行先環境
-
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase /wp/ RewriteRule ^index\.php$ - [L] # add a trailing slash to /wp-admin RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L] RewriteCond %{REQUEST_FILENAME} -f [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^ - [L] RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L] RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L] RewriteRule . /wp/index.php [L] </IfModule>
- ポイント
- 3行目と 14行目の記述の変化に注目して下さい。
wp-config.phpを修正
移行先の環境に合わせて、マルチサイトに関する記述を修正します。例として、移行元はルート直下、移行先は「wp」ディレクトリ内とします。
- 移行元環境
-
define('WP_DEBUG', false); define('WP_ALLOW_MULTISITE', true); define('MULTISITE', true); define('SUBDOMAIN_INSTALL', false); define('DOMAIN_CURRENT_SITE', 'old-site.com'); define('PATH_CURRENT_SITE', '/'); define('SITE_ID_CURRENT_SITE', 1); define('BLOG_ID_CURRENT_SITE', 1);
- 移行先環境
-
define('WP_DEBUG', false); define('WP_ALLOW_MULTISITE', true); define('MULTISITE', true); define('SUBDOMAIN_INSTALL', false); define('DOMAIN_CURRENT_SITE', 'new-site.com'); define('PATH_CURRENT_SITE', '/wp/'); define('SITE_ID_CURRENT_SITE', 1); define('BLOG_ID_CURRENT_SITE', 1);
- ポイント
- 7行目と 8行目の記述の変化に注目して下さい。
データベースの作成
移行元で既にデータベースを運用している場合、そちらを流用することも出来ますが、稼働中だと万が一エクスポートしたファイルが壊れてしまった際、影響が出る可能性があるため、別途用意することをおススメします。
- ポイント
- どうしても稼働中のデータベースを使って移行を行う場合、稼働中のテーブル接頭辞（例：wp_ など）が被らないか確認し、万が一被ってしまうようであればどちらかを SQL文で一括置換しておく必要があります。
データベースのインポート
先の手順で作成したデータベースに、サーバー側で用意されているインポート機能や phpMyAdmin、コマンドを使って移行元からエクスポートした sqlファイルをインポートします。
- ポイント
-
ファイル容量が大きすぎると、アップロード制限に引っかかり上がらないことがあります。その際、iniファイルを使って容量制限を引き上げたり、サーバーのコントロールパネルから引き上げたりすることも出来ますが、サーバー会社によっては iniファイルを触れない仕様になっているケースもございます。
詳しくはお使いのサーバー各社のマニュアルなどをご確認下さい。
データベース内の古い URLを一括置換
データベース内に残っている、古い URLを新しい URLに一括置換して正しく表示されるよう調整する必要がございます。「Search-Replace-DB-master」というスクリプトを使います。
1.「Search-Replace-DB-master」をインストール
下記より、zipファイルをダウンロードして下さい。
- zipファイルダウンロード
- Search-Replace-DB-master
zipファイルを解凍したら、「Search-Replace-DB-master」を「wp-config.php」ファイルがある階層にアップロードします。
2. ブラウザからアクセス
現在、WordPressがインストールされている環境が例えば「/wp/」ディレクトリ内だとしたら、「ドメイン名/wp/Search-Replace-DB-master」と、ブラウザのアドレスバーに入力してアクセス。
3.「search / replace」欄に必要事項を入力
「replace」と書かれた欄には「検索対象のURL ＝ 移行元の URL」、「with」と書かれた欄には「置換対象の URL = 移行先の URL」を入力します。「http（s）://」と最後の「/（スラッシュ）」は省いて入力します。
4.「databese」欄を確認
「wp-config.php」に記述されたデータベースの情報を読み込んで表示されていますが、念のために確認して下さい。
5.「tables」欄を確認
全てを検索対象とするのであればそのままで問題ないですが、検索対象を選ぶ際には Commandキーなどで選択して下さい。
6.「actions」で処理を実行
「dry run」「live run」のいずれかで処理を開始しますが、置換の状況が表示される「live run」がおススメです。
7.「delete」でサーバーから「Search-Replace-DB-master」を削除
処理を実行して問題なく置換が出来たら、「delete me」ボタンをクリックしてサーバーから「Search-Replace-DB-master」を削除します。
書き換えが出来るスクリプトがサーバーに乗っかったままではセキュリティ的にとても危険です。
- さらに詳しい機能について
- こちらの記事「WordPressでドメインやディレクトリ変更」も参照させていただきました。詳しい機能の解説については合わせてご確認ください。
データベース内「wp_site」「wp_blogs」テーブルを確認、ドメインとパスを編集
シングルサイト及びマルチサイトで階層構造が一緒のサーバー移行であれば、この段階で Webサイトが正しく表示されると思いますが、マルチサイトでまだ表示がされない場合はもう少し設定を行う必要があります。
データベース内「wp_site」「wp_blogs」（「wp_」箇所は、設定した接頭辞が表示される箇所なので変動します）テーブルを確認して、ドメインとパスを調整します。
データベースの URL一括置換で、ドメインにディレクトリ名も含まれてしまっている場合は、ディレクトリ名をドメインからパスに手動で移す必要があります。
- ポイント
- データベースを直接触る場合には、特に注意して行う必要があります。
挙動確認
この段階で移行は概ね完了です。ブラウザから Webサイトにアクセスして、ログインが出来るか、表示崩れがないかを改めて確認して下さい。
まとめ
弊社で行った移行作業では、上記に加えて旧バージョンの phpMyAdminを別途用意して sqlファイルをインポートしたり、本公開時に URLからディレクトリ名を省く処理をして 301リダイレクトをかけたりと、もう少し工程がありました。
あと、今回のサーバー移行は弊社で運用実績（触ったこともない）のないサーバーに対しての移行だったので多少時間はかかりましたが、調べながら何度かやり直したりしてうまく出来ました。
サーバー移行は、シングルサイトでもそうですが経験がないと、ともてハードルの高い作業のように感じがちです。また、うまく表示がされない場合の原因は、設定にあるのか、置換がうまくされていないのか、サーバー側の環境依存によるのかをいかにして見極めるのも大切になってきます。
この記事が、みなさまの参考になればとても幸いですが、くれぐれも自己責任で行って下さいませ。
この記事を書いた人
- ディレクター
- 2015年の「WordFes Nagoya」では、実行委員長を務めさせていただきました。
フルサイト編集対応ブロックテーマ
WordPress テーマ X-T9 は、WordPress 5.9 から実装されたフルサイト編集機能に対応した「ブロックテーマ」と呼ばれる新しい形式のテーマです。
ヘッダーやフッターなど、今までのテーマではカスタマイズが難しかったエリアもノーコードで簡単・柔軟にカスタマイズする事ができます。
パターンを使って
よりクオリティの高いサイトに
パターンとは、WordPressのブロックを組み合わせて作ったデザインテンプレートのようなもの。プロのデザイナーが制作したパターンを300以上公開中！コピペしながら高品質なサイトを簡単に作れます。
ブロックエディターで
ABテストを
自由に作成できる VK AB Testing
VK AB Testing は、ABテストを実施するための WordPress 用プラグインです。ブロックエディターでテストパターンを自由に作成でき、ランダム表示とクリック計測が可能です。Webサイトや広告などの施策の改善にぜひご活用ください。