WordPressのデータ移行について色々と調査したときの記録です。
意外と無いね。移行ツール
をやっているときに、WordPressサイト単位の同期コピーをやりたいと思いました。
WordPressならきっと簡単操作の同期プラグインがあるに違いない、と。
甘く見てました。
無いんですね～(TдT)
具体的にはこんな仕様です。
- ブログAとブログBの双方に同期用プラグインをインストールしておく
- 双方に秘密の合言葉を入れておき、所有者の一致を確保する
- 「同期」ボタンを押すと双方の更新日時を勘案して最新状態に同期
（まあ、一方的なコピーでも良い） - 有料オプションでスケジュール同期出来るようになる
誰かァ！ビジネスチャンスだよ！作ってくれ！www
いやホント不思議だよ。
こんだけプラグインが充実してるWordPressにこの種類ものが無いなんて。
どなたか良い同期用プラグインご存知なら教えてください。
俺的WordPress移行最短手順２選
色々とやり方はあると思いますが、今回の案件では２つのやり方に行き着きました。
“All-in-One WP Migration”プラグイン
画面操作で完結させるならこのプラグインを使うのが一番簡単・確実です。
- 正サイト・副サイトそれぞれにプラグインをインストール
- 正サイトをファイルにエクスポート（クリック一発）
- 副サイトでファイルをインポート（クリック一発）
- 副サイトにテーマをインストール
コレだけで良いです。実に分かりやすいです。
単にサーバを引っ越すだけならこのプラグインが最強と思っています。
ただ、スケジュール実行ができないので今回の目的（正サイトダウン時の代替）には使えませんでした。
wordmoveスクリプト
wordmoveはWordPressの本番機と開発機の同期を取るrubyスクリプトです。
シェル・git・rubyが必要。
wordmove pull --all
とやると本番機→開発機、
wordmove push --all
とやると開発機→本番機の向きでWordPress一式が被さります。
スクリプトなのでcronでスケジュール実行できるので、「普段から内容を同期させる」という今回の要件にマッチするのでコレで行くことにしました。
正直、黒い画面は極力見たくないのですが…。
実例
参考までに、KUSANAGIにwordmoveをインストールしたときの手順です。
今回の場合、
- ConoHa側に
wordmoveをインストール（制限が無いので） - ConoHa側を「開発機」
- エックスサーバー側WordPressを「本番機」とみなして
- エックスサーバーからConoHaにpull
することで同期を実現しました。
こちらはUbuntuにインストールしたときの手順です。
余談
記事単位の同期はプラグイン有り
ちなみに実用はしていませんが、記事単位の手動で良ければ
があります。
「確認してから本番公開」みたいな運用ならピシャリとハマりますね。
バックアップの原理
WordPressは
- プログラム・デザイン・画像等の『ファイル』
- 記事本体を記録したデータベース
で構成されておりますので、
- は
rsync等のコピーツール - はストアド・プロシージャやトリガの仕掛け
があれば原理的にはリアルタイム同期できます。