すんなり終わるはずだったWordPressのDB移行で2日ほど潰しました。
備忘録も兼ねて解決までの道のりです。
今回、WordPress3.4で稼働しているサイトをリニューアルついでに脆弱性が気になるのでバージョンを上げてほしいとの依頼がありました。
そのため、開発環境で制作を行い、本番サーバーにデータを戻して公開する計画を立てました。
対象の環境
・本番環境
WordPress3.4
MySQL5.5
GMOクラウドサーバー
・開発環境
WordPress3.7
MySQL5.1
SAKURA専有サーバー
トラブル１ SQLダンプ(エクスポート)ができなくなる。
本番環境からデータを移行する際、個人的に超おすすめな個人では手が出ないMac用DBクライアント「Navicat」で新しく開発環境に空のデータベーステーブルを作り、構造の同期、データの同期を行います。
この時は、sqlファイルを実行しただけでデータの移行は可能でしたが、もう一度本番環境へダンプして戻そうとした際に、何度ダンプしても中身がからのsqlしか吐き出せなくなった。
トラブル２ XMLファイルのインポートができない。
sqlファイルのデータ受け渡しができないなら、勝手にパスも書き換えてくれるWordPressデフォルトのXMLファイルでデータを移行しようと考えました。
まずは、ファイルサイズの問題が発生。サーバーの設定によりますが、だいたいデフォルトでは2M以上のファイルはアップロードできません。
そこで、php.iniかhtaccessでアップロードできるファイルサイズを引き上げます。
ぼくの場合は、php.iniはあまり触りたくないので、htaccessに以下の記入をしました。
1 | php_value upload_max_filesize40M |
これで一時的にファイルのアップロード制限を40Mまで引き上げました。
しかし！
なぜかXMLアップロード(インポート)に失敗する・・・。
というか、アップロードすると画面真っ白・・・白銀の世界です。
調べてみると、WordPress Importerを以下のように書き換えるとうまくいきました。
wp-content/plugins/wordpress-importer/parsers.phpの以下の箇所を直します。
1 | if(extension_loaded('simplexml')){ |
↓
1 | if(false&&extension_loaded('simplexml')){ |
解決！
XMLファイルが30M近くあったので、１時間弱かかりました。
これで、移行は完了だぜ～いとチョコレート食べだしたところで次のトラブル。
トラブル３ メディアライブラリとカスタムメニューが空。
投稿は問題なくインポートできたのですが、メディアライブラリとカスタムメニューが空っぽ。ただし、画面上だとメディアライブラリの画像が表示されるというわけのわからない現象が起きる。そして、終電の時間となったので一旦終了。
二日目になり、調べてみましたが、本来ならXMLをすべてにチェックしてエクスポートし、Download and Import file Attachmentにチェックを入れれば、自動的にインポートできるみたいなんですが、なぜか上手くいかない。投稿と固定ページはうまく行ったけど。
なんとなく思い当たる原因は、ディレクトリがしっちゃかめっちゃかになるのを防ぐために、Relocate Uploadというプラグインを使って、クライアントにファイルによってアップロードするファイルを選択してアップロードしてもらってます。これかなーとか思いつつ、解決できず。
メディアライブラリのめんどくさいところは単体で、出力ができないこと。WordPressのエクスポート機能ではすべてを選択する以外、メディアを出力する方法はありません。
メディアライブラリはデータベース上、個別に、しかも、投稿や固定ページと区別なくIDを持つため、本番環境と開発環境の投稿やメディア情報に一つでも違いがあったらアウト。
もう心が折れそう。
ここで、振り出しに戻る。
よくわかんないけどやっぱり、DB直接コピーするしかない！
そこで、sqlにダンプできない原因を調べると、どうやらMysqlのバージョンに関係があるみたい。
5.1→5.5間でデータを動かすと構造が違くてエラーになるんだとか・・・
ばっちり、当てはまってるぜ・・・・・・・・・・。
調べてみると、あるコマンドで解決できることが判明っ！
1 | mysql_upgrade-uroot-p |
念のため、このコマンドを叩く前にバックアップが取れるならバックアップをおすすめします。
ぼくはバックアップが取れなかったのでしませんでしたが・・・。
これで、解決。詳しくは調べてませんが、DB自体のスキームに差異があるようでした。
あとは、sqlを実行してあげるだけだ♪♪♪♪♪♪♪♪
一段落。やったぜー！うっふふ。
って思ったらクライアントから
あるページ(カスタムフィールド)が更新できないとの連絡。
そのページは、カスタムフィールドが全部で100個くらいある固定ページ。
※表示部分の管理に使ってるのでこんな数になってしまった・・・。
「特定の数以上の更新をしても反映されないのですが、上限ってありましたっけ？」と。
いやいやいやいや！ないはず！
と思って調べたら、82個以上カスタムフィールド登録できないという記事を見つけました。
セキュリティ的にあまりに数が多い書き込みはセキュリティ上危ないのでしないでね（ハート）ってことらしい。
たしかに、一度にたくさんのデータを書き込んだり読み込んだりするのは危険ですよねーーーー。どこからかのアタックだったらひとたまりもないですし。
ただし、今回は余計なお世話なので、下記の内容で回避。
htaccessに
1 2 | php_value memory_limit512M php_value max_input_vars3000 |
上記で対処
php_value max_input_varsをむやみに引き上げるのは、まずいらしいので終わったら戻すことをおすすめします。
さらに、wp-pagenaviが動かない。
ページャー自体は表示されるし、ページのカウントも正しいけど、何ページ目をクリックしても、URLは遷移するものの表示されている内容は変わらない。
これはDB移行の問題ではないのですが、今回、固定ページでカテゴリごとの一覧を作っています。
それとは別に新規で、カスタム投稿タイプの一覧を設置することになりました。
その際に固定ページのパーマリンクを
ドメイン/app
として、appカテゴリの一覧ページにしていました。
2ページ目以降がすべて同じものが表示されて動いてない・・・。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | <?php $apart_args=array( 'posts_per_page'=>5, 'post_type'=>'app', 'paged'=>$paged, ); ?> <?php $apart_posts=newWP_Query($apart_args);if($apart_posts->have_posts()): while($apart_posts->have_posts()):$apart_posts->the_post(); ?> <?php//ここにループさせる内容 ?> <?phpendwhile;endif;?> <?php if(function_exists('wp_pagenavi'))wp_pagenavi(array('query'=>$apart_posts)); ?> |
としていました。
調べてみたところ、原因となったのは、固定ページのパーマリンクとpost_typeの命名が同じだとwp-pagenaviは正しく動かないということでした。
そのため、固定ページのパーマリンクをappからapp_listへ変更すると動くようになりました。
以上、最高にハマった数日間でした。
その他にも細々とトラブルがあったのですが、記事を書いている間に忘れてしまったので、思い出したら追記していきたいと思います。
しっかし、こんなにもDBの移行でハマるとはまだまだ勉強不足すぎです。
ちなみに、一応注意点として、なぜこうなって、なぜこれで解決したのか深くは調べていません。
もしかしたら、重大なトラブルを引き起こす可能性もあるので、あくまでも自己責任でお願いします。
環境によって、解決法は変わってくると思いますが、
もし、同じような現象でハマったら試してみてください。
