WordPressのデータを本番へデプロイする方法、ツールは色々ありますが、わたしはサイト構築も経験が浅いので、とりあえずできるところからやっています。個人的には、IDEに依存せず、コマンドラインからの実施が可能な方法があると嬉しいので、何か良いものがないかな〜と探したところ、 wordmove というruby製のツールを発見。
きっかけになったのは、ユニキャストラボ様の、下記のエントリです。
- wordmove – WordPressサイトを一発デプロイ
基本は上記のエントリを参考にいただければ分かるかと思いますが、オプションについての情報を、こちらで補足してみます。
20161014: ドメイン移行に関しての追記
- ドメインが異なる環境への復元後、URLを置換する方法について追記しました！（末尾）
こんなことができます！
- Movefileという設定ファイルをベースに、サイトへのpush や pullを実施する。
- オプション指定で、プラグインだけ同期とか、データベースのデータだけ同期、といったことができる。
- Movefileに従い、ダンプしたデータの中にあるデータ（パスやURL)を、環境に合った内容に書き換えてリストアしてくれる。
- ruby製のツールだが、コマンドを実行するローカルマシンにだけrubyとwordmoveがあればいいので、サーバ側にruby, コマンドのインストールの必要が無い。（基本はsshを使い、rsyncでデータ同期、mysqldumpでダンプリストアを処理します）
オプションで細かく同期の設定ができます！
ユニキャスト様のエントリでは、wordmove push --all で、一気にサイト全体をサーバにpushする例が乗っています。
でも、いきなりこれは心配ですよね…。
(pull ならまだ大丈夫そうですが、push で環境壊してしまうと心配）
ソースをよく見ると、--all で一気に同期だけではなく、細かいオプションがありますので、記載しておきます。（ちなみに、今のところ wordmove help だけでは細かい指定が表示されません）
オプションは、ソースのこの箇所を見れば、多分分かります。
shared_options = {
:wordpress => { :aliases => "-w", :type => :boolean },
:uploads => { :aliases => "-u", :type => :boolean },
:themes => { :aliases => "-t", :type => :boolean },
:plugins => { :aliases => "-p", :type => :boolean },
:languages => { :aliases => "-l", :type => :boolean },
:db => { :aliases => "-d", :type => :boolean },
:verbose => { :aliases => "-v", :type => :boolean },
:simulate => { :aliases => "-s", :type => :boolean },
:environment => { :aliases => "-e" },
:config => { :aliases => "-c" },
:no_adapt => { :type => :boolean },
:all => { :type => :boolean }
}
ということで、ソースと動きを確認しながら、オプションについて簡単にご説明します。
- :wordpress | -w
- Movefileのexclude部分で指定した以外のソースの同期をします。
- :uploads | -u
- uploads フォルダを同期します。
- :theme | -t
- wp-content/theme フォルダを同期します。
- :plugins | -p
- wp-content/plugins フォルダを同期します。
- :language | -l
- p-content/languages の*.mo, *.po だけ同期します。
- :db | -d
- DBのデータを mysqlsump でダンプ -> mysqlコマンドでリストアします。
- :verbose | -v
- メッセージの詳細表示。
- :simulate | -s
- いわゆる dry runモード。リモートのサーバの接続チェックなどに利用します。
- :environment | -e
- 環境を指定できます。雛形のMovefileは local & staging なので、productionなどで、本番サイトの追加／切り替えができます。
- :config | -c
- wp-congig.php も同期させます。
-d オプションでデータのダンプ／リストアを行いますが、--no_adapt true とすると、sqlファイルを転送するのみで、DBを更新はしません。
やってみた際の制限ですが、rubyで実装とは言え、コマンドはsshを利用、rsyncとかmysqldumpを利用しますので、push / pull のサーバともに、Unix系OSというのが条件です。
ただし、rubyとwordmove コマンドは、Movefileを保持しているマシンにだけインストールされていれば良く、『本番は古くてrubyを追加したり、構成変更できないよ』と言う場合でも ssh / rsync / mysqlのコマンドが動けば大丈夫です。
実行サンプル
stagingサーバのWordPressのupload ディレクトリを、ローカルにpull するサンプルです。-s コマンドがあるので、実際には転送せず、転送対象のデータのみ表示します。（ローカルはMacBookでMAMPを使っています）
$ bundle exec wordmove pull -u -v -s -e staging
▬▬ ✓ Using Movefile: ./Movefile ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬ ✓ Pulling Uploads ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
remote | get_directory: /var/htdocs/wordpress/swp-content/uploads /Applications/MAMP/htdocs/wordpress/wp-content/uploads .git/ .gitignore .sass-cache/ bin/ tmp/* Gemfile* Movefile wp-config.php wp-content/*.sql
wordmoveではできないこと / 制限
DBの書き換え
WordPressのサイトをお引っ越しする場合、面倒なのが記事の中に、リモートサイトのURLが絶対パスで書かれていたりするケースです。wordmove では、ダンプ／リストアの際に、pull先に合ったデータに置換してくれるというオプションまではありませんので、ご注意を。
wp-config.php でURLをコントロールできる範囲での制御は可能ですが、実際は引っ越しする場合には *.sql 内の文字列を書き換えてから処理、なんてことも必要です。
ソースにURLやディレクトリがハードコードされている場合の書き換え
こちらも、基本はrsyncだけなので、プラグインやテーマによっては、サイトのURLをハードコードしていたりすると注意が必要です。
DBのデータの置換についての対応
DBデータがすんなりポーティングできない場合、こんな感じで書き換えています。
特に、ステージングではhttpで、本番がhttps だったとか、データを保持しているディレクトリ構成が違っていたりする場合は変換が必要です。
私の場合は、本番とステージング（検証用サーバ）は、wordmoveではなくshellを使ってJenkinsで同期のジョブを作っていたりします。下記はDBの変換をしている一例です。
perl -pe "s/http:\/\/ステージング環境\/プレフィクス\//https:\/\/本番環境\/プレフィクス\//g; " < wp_変換前.sql > wp_変換後.sql
installについて
gemなので、gem install wordmove でインストールできます。もちろん、特定のディレクトリにGemfileを使ってインストールもできます。
vi Gemfile
source 'https://rubygems.org'
gem "wordmove"
この場合の実行は、
$ bundle exec wordmove help
ちなみに、結構いろんなのが依存で入ります。(net-ssh, net-scp など)
20161014追記: ドメインが異なるサイト / 開発環境での稼働用の書き換え
「wordmoveでできないこと」に記載した通り、DBのデータをそのままリストアしてしまうと、データのなかの随所に本番用（もしくはコピー元）のURLが書き込まれているため、リストアした際に元のサイトに飛んでしまうことがあります。
うっかり本番側に飛んで設定や記事をいじってしまった...ということがあると大変なので、書き換えが必要になります。
公式サイトでのドメイン移行のガイド / 移行ツールについて
こちらに、ドメイン移行の流れが記載してあります。
わたしの場合はshellやperlでの置換を行いましたが、Windowsで作業している場合などは、スクリプトを動かすにも環境が無いとやりにくいので、可能でしたらこちらをおすすめします。（上記の公式サイトにもおすすめされています）
- [search-and-replace-for-wordpress-databases] (https://interconnectit.com/products/search-and-replace-for-wordpress-databases/)
- https://www.infoscoop.org/blogjp/2014/08/14/use-search-and-replace-for-wordpress-when-moving/ (日本語)
phpMyAdminのプラグイン的なもので、こちらを使ってDBに入った段階での元ドメインの文字列を置換することができます。
dry-run (お試し) モードもあるので、WordPress以外に手元でphpMyAdminを動かせたりできる場合は、ぜひこちらをご利用ください！
DB書き換え以外でもコピー元に飛んでしまう場合
この場合は、*.php であったり、WordPressのキャッシュ用コンテンツとして書き出されたファイルの中に元のURLが書き込まれているパターンが該当します。方法としては、
- grep のようなパターンマッチで元のURLがハードコードされていないか探し出す
- Cache用コンテンツは再生成できると思ってバッサリ消す
というあたりになります。