WordPressのテーマ開発と切ってもきれないのが「開発環境の同期」の問題です。本番と同じデータじゃないと、どうしてもテストが難しい時があります。
「できるだけ簡単に本番と同期して開発＆テストがしたい！」という名目の下、やり方を考えました。
詰まるところが、Wordpressサイトの引っ越しとほぼ同じ考え方ですので、これをマスターすれば、あなたも引っ越しマスターなはずです。
はじめに、「WordMove」というツールがWordpress同士の同期や引越しに、評判がいいようですが、あまり余計なツールと関わらない人のための記事なので、ここではWordMoveは使いません。
繰り返しですが、開発環境（ステージング環境、ローカル環境なども含みます）を、本番のDBと同期させて、同じ状態にすることを主眼にします。
すこし本件と異なりますが、ステージング環境の作り方、すなわち「本番データベースを直接参照する、ワードプレス環境の作り方」については、別の記事にしたので、そちらも見てみてください。
目次
同期する必要があるもの、まとめ
まずは基本を確認です。理論的には、以下の３つを同期すれば、ほぼ同じ環境ができるはずです。（同じバージョンのワードプレスが、それぞれの環境で動いている事は前提とします。）
| 対象 | どこにあるの？ |
| SQL | SQLデータベース |
| テーマ | /wp-content/themes/<該当のテーマ> |
| プラグイン | /wp-content/plugins/配下 |
| アップロード画像 | /wp-content/uploads/配下 |
１点、注意が必要なのが、「テスト環境と本番環境で必ずホスト名（ドメイン、URL）が異なる」という点です。これはどうあがいても一致させる事はできません。（できなくは無いですが、やりたくない・・）
こちらはあとで対応方法を記載します。一つづつ見ていきます。
SQLを同期する
最初にSQLですが、実際はこれが一番厄介です。
WordPressのデータには、何故かホスト名が紛れ込んでいます。ホスト名が紛れ込むのは（特殊なプラグインの事を忘れれば）以下のような値です。
- optionsテーブル：home、siturl
- postテーブル：post_content
- postテーブル：GUID
- その他の値
基本的にはすべて、DBを操作して<ドメインA>文字列を<ドメインB>に置換してやれば大丈夫な気がしてしまますが、そうも行きません。補足していきます。
Wordrpessの知っておくべきSQLのフィールド
optionsテーブル：home、siturl
それぞれ「ワードプレス自体のURL」「ワードプレスディレクトリルートのURLパス」が含まれます。ドメインが指すディレクトリがそのままワードプレスのルートであれば、両方おなじドメインになっているはずです。そうでない方は、後者にディレクトリ名がふくまれていますね。
名前が紛らわしいですが、「homeは関数get_home()で帰ってくる値」と覚えると分かりやすいかもしれません。
この値を修正しないと、Wordpressが動作しないはずです（＃特殊な対応方法あり、後述）ので、正しく環境のホスト名を入力します。
postテーブル：post_content
WordPressのエディタから、メディアを挿入するとバシバシ絶対アドレスが紛れ込んできますね・・。これは置換します。
本番→開発 のデータシンクであれば、結局本番の画像URLが使えてしまうので、あえて置換しなくてもテストはできそうですね。。
postテーブル：GUID
この値は実装で使うことが無いので、馴染みがないですが、投稿のIDとして利用されているものです。ページのソースを開けるとHEADタグ内にcanonical 値として出力されているはずです。（canonicalは、SEO上の重要ですので、知らない人はググって下さい。）
WordPressは、管理者の意図で、記事のパーマリンクが簡単に変えられてしまいますが、このGUIDだけは常に一意なURLを持ち続けるので、同じ記事であることを、検索エンジンやRSSリーダが認識できる、という目的の値です。
DBのシンクに置いては、もしローカルや開発環境で作った投稿を本番側に辛苦しようとしているのであれば、この値についてケアする必要があります。なぜなら、開発環境のドメインメインがふくまれてしまうと、誤ったcanonical URLがインターネット上に公開されてしまうからです。
逆に、本番→開発に対してデータを落とすのであれば、あまりケアしなくてよいでしょう。
その他の値
あとは、メタフィールドです。とくにWordprssの鉄板プラグイン「Advanced Custom Field」などはよく発生しますが、シリアライズされた値を保持する事があります。また、optionsテーブルにシリアライズされた値が入ることもあります。
これらを正しく置換するには、通常のSQLコマンドや、文字列置換だけでは、うまく置換できません。
強い味方、DB移行専用のプラグイン
もうこれに頼るしか無いです。
１）Migrate DB
上述したことを全てケアしてくれるSQLエクスポート用のプラグインです。
上述以外のことも補足：
Exclude transients: トランジェントというキャッシュです。いくつかのプラグインが利用しているかもしれませんが、optionsテーブルにシリアライズした文字列が突っ込まれています。まあ、取り除いた方がよいでしょう。
Exclude post revisions: ここはいまあえて取り除かなくてもいいでしょう。でも別観点ですが、revisionが溜まりすぎると、動作に影響してくるので（とくにmetaフィールドが多い場合）こまめにメンテしてあげてくダサい。
２）Search & Replace
こちらもほぼおなじことができますが、DBの移行よりは、その場でDBを書き換える事に特化しています。SQLの操作に感覚が近いので、エンジニアの方は、「今何をやっているのか」が想像しやすくて好きかもしれません。
番外編: home、siteurlの値を迂回する
ちょっとしたマメ知識ですが、下記をwp-config.phpに書き込んでやれば環境ごとのドメインの違いを無視できます。
wp_optionsテーブル内の、siteurlとhomeの値を、WPロード時に、動的に置き換えて動作してくれるようです。DBの値を書き換えることなく、振る舞いを変えられる、というわけです。
define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] ); define( 'WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] );
もしあなたの環境で、サブディレクトリにワードプレスを展開しているのであれば、WP_SITEURLの値は ’http://’ . $_SERVER[‘HTTP_HOST’] . ‘/directory’ となるはずです。最後のスラッシュは不要です。
この記述によって、テーマなどのWordpressの実行コードないでも、home_url(), get_template_directory_uri()などの返り値が、変わります。あたかもDBの値が書き換わったように振舞う、ということですね。便利です。
筆者は 本番→開発 の同期に置いては、上記だけwp-config.ppに書いておいて、DBの置換を一切行わない事もあります。。
テーマを同期する
こちらは思い思いの方法で、どうぞ。Rsyncの人は、Rsyncで。FTPの方はFTPで。
筆者は、（あまり好ましくはないですが）wp-content/theme/<テーマディレクトリ>配下にgit init して、gitおリモートレポジトリ経由でpull してしまうことが多いです。これもコマンドで実行できるので、FTPよりはよっぽど速くて正確です。
ただし、チームメンバーの非開発者など、本番環境に直接変更を加える人もいるので、git コマンドなら、環境のファイルに意図せず直接変更が加えれれていても、間違って上書きされなくて済みます。
プラグインを同期する
プラグインは開発対象じゃないので、コマンドライン使える人は、rsyncなどのシンクコマンドがおすすめです。FTPよりずっと早くて正確です。nオプションでドライランもできますからね。詳しくはmanで見てして下さい。
//ローカル → 本番 にSSHで同期 rsync -rv -e 'ssh -p 2222' ./wp-content/plugins/* username@server.com:~/www/my-blog/wp-content/plugins
参考リンク：
アップロード画像を同期する
これもrsyncおすすめです、速い。
//ローカル → 本番 にSSHで同期 rsync -rv -e 'ssh -p 2222' ./wp-content/uploads/* username@server.com:~/www/my-blog/wp-content/uploads
同期を自動化する
上記を毎回やるのはしんどいので全部自動化します。
Cronじゃなくていいので、
基本的には「本番 → 開発」のシンクがメインになります。「開発 → 本番」方向のシンクは怖いのでやらないです。意図しないバグが混入したり、GUIDの問題も嫌ですね。
固定ページなど、データをどうしても作り直すのが手間なときもあります。
（この記事は執筆中です）
