ベクトルパスポートを購入して無料で Evergreen をダウンロードしよう

詳しくはこちら
English

ベクトルパスポートを購入して無料で Evergreen をダウンロードしよう

詳しくはこちら
English

プラグインを使わず行う WordPressマルチサイトのサーバー移行と気を付けるべきポイント

伊藤 晋之

  1. HOME
  2. Staff Blog
  3. WordPress
  4. プラグインを使わず行う WordPressマルチサイトのサーバー移行と気を付けるべきポイント


先に謝ります、何かすいません。。。

さて、話しを本題に移しますが、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 を追加」のチェックが外れていたらチェックを付けておきます。

シングルサイトであれば圧縮をかけずにエクスポートすることもありますが、マルチサイトである程度作り込みをして容量が膨らんでいるため、圧縮をかけてエクスポートします。

phpMyAdmin エクスポート画面の解説
ポイント
移行先の環境によっては、データベースにインポートするファイル形式を推奨しているケース（例：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ファイルをインポートします。

phpMyAdmin インポート画面の解説
ポイント
ファイル容量が大きすぎると、アップロード制限に引っかかり上がらないことがあります。その際、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）://」と最後の「/（スラッシュ）」は省いて入力します。

検索対象 URLと置換対象 URLを入力

4.「databese」欄を確認

「wp-config.php」に記述されたデータベースの情報を読み込んで表示されていますが、念のために確認して下さい。

「wp-confi.php」内の情報を取得して表示されているが、内容を確認しておく

5.「tables」欄を確認

全てを検索対象とするのであればそのままで問題ないですが、検索対象を選ぶ際には Commandキーなどで選択して下さい。

全てを対象にするなら「all tables」、検索対象を選ぶのならば「select tables」にチェックを付ける

6.「actions」で処理を実行

「dry run」「live run」のいずれかで処理を開始しますが、置換の状況が表示される「live run」がおススメです。

「live run」クリック
「live run」実行中、処理が一つずつ表示されていく

7.「delete」でサーバーから「Search-Replace-DB-master」を削除

処理を実行して問題なく置換が出来たら、「delete me」ボタンをクリックしてサーバーから「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リダイレクトをかけたりと、もう少し工程がありました。

あと、今回のサーバー移行は弊社で運用実績（触ったこともない）のないサーバーに対しての移行だったので多少時間はかかりましたが、調べながら何度かやり直したりしてうまく出来ました。

サーバー移行は、シングルサイトでもそうですが経験がないと、ともてハードルの高い作業のように感じがちです。また、うまく表示がされない場合の原因は、設定にあるのか、置換がうまくされていないのか、サーバー側の環境依存によるのかをいかにして見極めるのも大切になってきます。

この記事が、みなさまの参考になればとても幸いですが、くれぐれも自己責任で行って下さいませ。

フルサイト編集に対応したブロックテーマ X-T9

フルサイト編集対応ブロックテーマ

WordPress テーマ X-T9 は、WordPress 5.9 から実装されたフルサイト編集機能に対応した「ブロックテーマ」と呼ばれる新しい形式のテーマです。
ヘッダーやフッターなど、今までのテーマではカスタマイズが難しかったエリアもノーコードで簡単・柔軟にカスタマイズする事ができます。

パターンを使って

よりクオリティの高いサイトに

パターンとは、WordPressのブロックを組み合わせて作ったデザインテンプレートのようなもの。プロのデザイナーが制作したパターンを300以上公開中！コピペしながら高品質なサイトを簡単に作れます。

PAGE TOP

このデモサイトは Vektor,Inc. のテーマとプラグインで構築されています。ご購入や詳細情報は下記のリンクもご参考ください。