WordPress 4.1.2: 不具合対応まとめ

技術的にどのようい互換性を維持するのか? とかそういう話は置いておいて根本的に今の作りを見直さない限り先が無いと思ったのでそのまとめ。

先ず、そもそもの原因は何だったのか? ですが、結局はこの文章に尽きます。

当時 Ryan がこの問題を理解して適切な修正が本体で行われるまで丸1年かかりました。そしてその時にデータベースを UTF-8 に正常に変換できずにそのまま運用してきた方達、あるいは、同様の変則的な設定でたまたま動かせていた方達が今回のデータベース周りの改変に引っかかってしまった、ということですね。

要は本来UTF-8に全て変換されていなければならなかったMySQLのDBが部分的にShift JISのまま使い続けられてしまった事が原因という事ですね。一応自分でも WordPress 4.2.1-ja を新規でセットアップしてみて確認したのですが、生成されるDBの照合順序が全く別物。このサイトはWordpress 2.3の頃から延々と使い続けていたのですが、DBの照合順序は ujis_japanese_ci 。部分的に utf8_general_ci にテーブルの照合順序が書き換えられているもののエントリが格納される wp_posts は ujis_japanese_ci のままでした。

一方で新規でセットアップしたDBは utf8_general_ci で設定されており個別のテーブルは全て utf8mb4_general_ci で設定されています。なるほどこれなら wp_posts に書き込む時の文字コードが変換されてしまう事にも納得が行きます。従って根本的な解決策はただ一つ。DBを再作成して新環境を構築する事です。まあDBを2つ作って移行ツールを作るようなところで頑張っても良いのですが、バグ出し大変そうだし新規DBにExport/Import でデータ移行ですよ。その辺りの手順を簡単にまとめておきます。

新環境構築前のデータ移行の前準備

そもそも移行前の環境は準備をしないと全て消滅するので事前の作業が必要です。

  1. WordPressの管理画面上からコンテンツデータのバックアップをします。ツールからエクスポートを選んで実行。”すべてのコンテンツ” を.xmlで “文字情報は” 全て出力してくれます。
  2. WordPressの管理画面上から導入しているプラグインをリスト化します(手動)。要不要は後で検討すれば良いですが、そもそも何が入っていたか判らなくなると困るかもしれません。
  3. WordPressの管理画面上から導入しているテーマをリスト化します(手動)。自分でカスタマイズテーマを作っている場合には元テーマを必ず押えておきましょう。
  4. OS上で元のWPディレクトリをバックアップします。一旦はリネームで良いと思います。

ここまで実行すると既に元のWPにはアクセスできない状態。まあリネームしたディレクトリを戻せば良いだけなんだけれど。

新DBの作成とセットアップ

さくらのレンタルサーバでは利用できるMySQLのバージョンがいつの間にやら5.5になっていました。ISAMよりInnoDBの方が扱いやすそうなので5.5で新しいDBを作ります。WPは wordpress-4.2.1-ja.tar.gz をダウンロード済。

  1. 新規DBはUTF-8で。作成する時の “データベース文字コード” を UTF-8 にしておけばOKです。データベース名とアカウント/パスワードは、後ほどWPのセットアップで使うので控えておきます。
  2. その後 OS でWPのパッケージを展開します。
  3. WordPress(ワードプレス)をインストールする方法【初心者向け】 | TechAcademyマガジン とかを参照しながらインストールして動作確認。

データの移行

データの移行は大きく3系統です。

  • WPでExportしたXMLファイルのインポートする。
  • WPで必要なテーマやプラグインをダウンロードして有効化する。
  • OS上でカスタムテーマや画像ファイルのディレクトリなどを移行する。

この中で厄介なのは、実はインポートだと思います。その他2つは気合と根性で何とかなるのですが、投稿数やコメント数が多ければ多いほどインポートは大変です。特にPHPで動いているアプリケーションの場合には php.ini でアップロード可能ファイルサイズや処理対象サイズなどを制限・拡張するので知識として必要です。

upload_max_filesize = 20M
post_max_size = 20M

取りあえずインポートファイルが20Mより小さかったら上記の様な設定で如何でしょうか? くらいなものですが必要な作業が完了したら元に戻しておきましょう。因みにテーマはこの場所に格納されています。

WP/wp-content/themes

必要なものをコピーしましょう。

移行のタイミングとか時間とか後処理とか

兎に角ボリューム次第です。私の場合は細かい作業とか見直し作業とかしていたので結局のべ4時間くらいを費やしていると思います。もっと綺麗な造りをされているのであれば2時間程度で終わる方もいるかも知れません。

全ての作業が終わっても元データ(ディレクトリとDB)は一か月程度残して置いた方が良いと思います。後から無いものに気が付いてもどうしようも無くなりますから。その辺りは個人の裁量という事ですね。

結果的に全移行工程を経て元の不具合は一切なくなりました。序にInnoDBに変わった事が関係しているのか並行処理が速くなった気がします。結果オーライではありますが、データ移行をもっとスムーズに行うための手立てを考えておく必要があると感じました。