WordPressの本番環境へのDB移行メモ

(追記:2018.12.23)
下の記事はやや混乱していて,テスト環境から本番環境へのドメイン名の変更の問題と,本番環境での http:// から https:// (いわゆるSSL化)とが混在して書かれています.
結論だけ書いておくと:
テスト環境(http://test.jp/ )から本番環境(https://production.jp/ )への移行でしたら Duplicator で全く問題無し. 本番環境での(いわゆる)SSL化でしたら, Velvet Blue Update URLs が良いのではないかと思います.

それほど派手な環境でなければ,実はviで ,$ s/old_site_url/new_site_url/g みたいなコマンド一発でもダメじゃない場合もなくはないんだけど,この方法はNGだと公式にも書かれているし,Widgetsをバリバリ書いたりしてると実際NG.(NGな理由はPHPのシリアライズ絡みで,説明してくれているブログが5,000くらいはありそうなので略)

そこで,通常はプラグインやCLIを使うんだけど,ちょっとハマった気がするので実際の動作を検証した上で後ほどブログにメモを残しておきたい.

ちなみに比較利用したツールは下記の上3つ.

  1. Duplicator
  2. Search Regex
  3. Velvet Blues Update URLs

実は移行データが大き過ぎて,2が動作しなかった(共用レンタルサーバのせいか,メモリを食い潰してコケた)んで,さて困ったってのが発端. 引き継いだDBでどうも以前に入れていたプラグイン?かなにかのゴミデータがpostmetaあたりに大量にありそうだったので若干嫌な予感はしてた.

Search RegexはWordPressのサーバ移行の件で,よく紹介されてるんだけどこんな落とし穴があろうとは思わなかった.

と,いうことで結論だけ書いておくと3で解決しました. 1はどうもホスト名は書き換えてくれるんだけどプロトコル部分を書き換えてくれたような,くれないような・・・要検証.追記:バッチリ書き換えてくれます!) 他にWP-CLIは共用レンタルサーバ環境だと使えない人も多いと思うんだけど,いけるんじゃないか?と思ってましてこれも要検証.

今回のケースではWidgetsをゴリゴリに書いた関係で,DB一括変換はNGだったんで助かりました.最悪自分でスクリプト書かなくちゃダメかと思った.

困ってPage Builderのオフィシャルサイトを見に行ったらオススメされてました.

いずれ近いうちに検証結果をここに書くことにするつもりです.(状況追記しました)