こんにちはブロガー宮川（@miyakawa2449）です。
今日はうまく話せる自信がないのですが、WordPress のテーマ変更作業中にデータ構造を破壊してしまい、半日無駄にしてしまいました。
そんな私の失敗談聞いていただけますか？
WordPress のテーマファイルを新しく変更するだけなら、データベースをいじる必要はないんです。
今回はテーマファイル変更に合わせて記事のデータなども大きく手を加えたのでいろいろ失敗してしまいました。
後学のために記事にします。
あなたも同じ失敗をしないよう気をつけてください。
WordPress のSEO機能が優秀な Lion Blog テーマファイルに切り替えることにしました
WordPress のテーマファイルは人間で言うところの洋服、家で言うところの外装・内装。
いわゆる見た目のデザインです。
何種類ものテーマファイルを用意しておいて、管理画面で切り替えると、着せ替え人形みたいにデザインをガラッと変更できる便利な機能なんです。
今回、用意したのは Lion Blog という SEO 機能に優れた無料テーマファイルです。
今回、このテーマファイルには何の罪もありません。
全て私の失敗です、、、半日無駄にしてしまいました。
WordPress のテーマファイルを変更すると何かが変わる！
テーマファイルを変更すれば見た目が変わることは先ほどお話した通りです。
しかし、テーマファイルをオリジナルのまま使う人はほとんどいないでしょう。
そうです、カスタマイズが必須なんです。
例えば、スマートフォンを新しく買ったら、保護シートを貼ったり、ケースを買い換えたり、好みのアプリを選んで入れるみたいな感じです。
WordPress の場合、カスタマイズしないテーマファイルは、何もカスタマイズされていないスマートフォンと同じです。
テーマファイルによくあるカスタマイズには例えば、アクセスログのコードを設置したり、OGPの設定をしたり、SNSのシェアボタンを設定したり、広告を入れたりと、いろいろあります。
WordPress本番環境と開発環境を用意しよう
左上が公開用の本番環境。右手前が検証用の開発環境。
カスタマイズをテーマファイルに施すわけですが、本番環境でテーマファイルを1からカスタマイズするわけにはいきませんよね？
テーマファイルを切り替えた瞬間から、アクセスログは取れなくなるし、OGPやSNSシェアボタンも無効になります。
できれば、テーマファイル切り替え前に準備は終えておいて、本番切り替え時には最小の時間コストで作業が終わることが理想です。
そのためには本番と同じ、開発環境を用意しておく必要があります。
本来なら本番の WordPress を構築した時に同時に開発環境も用意しておくべきでしたが、私、今回直前に開発環境を用意しました。
開発環境を用意して本番と同じ環境を完全に再現しておいてほんとうによかったです。
今回のテーマ変更時にデータベースを操作して、本番環境のテーマファイル切り替えおよびカスタマイズ時間を最小にしようと色気を出して失敗してしまいました。
しかし、データベースのバックアップと開発環境を残しておいたことで、完全に復活させることができました。
本当によかったです。
記事データは開発環境で事前調整しよう
さて、テーマファイルの種類によって記事ページや一覧ページのレイアウトや扱うデータが異なります。
今回も新しいテーマファイルの「Lion-Blog」に切り替えるに当たって、現行のブログ記事との運用が大きく異なった点がありました。
次の2つです。
- アイキャッチ画像が記事ページのトップに入る機能がある
- 見出しタグを自動検出して、記事内に自動で目次を作ってくれる機能
アイキャッチは全ての記事に入れていたので、その点は問題はありませんでした。
しかし、記事内にアイキャッチ画像を入れる機能がなかったので、記事のトップに手動で画像をアップしていまいた。
すると、今回の新しいテーマファイルを適用すると記事のページトップに画像が2つ並ぶという「痛い」状況になりました。
そこでアイキャッチ画像の見直しと、記事内のトップ画像を全てを外す作業をおこないました。
もう1つ「目次」機能があるので、それまで手動で入力していた「目次」と整合性を揃える作業もおこないました。
何百件もの記事を見直ししたので、丸1日作業に時間が取られました。
開発環境での完成させたブログを本番環境に適用した手順
開発環境でデザインテーマファイルのカスタマイズを完了させました。
記事の内容も見直し、目次やアイキャッチ画像の再調整、その他過去記事の再調整も全部終えました。
後は開発環境で準備した内容を本番環境に施すだけです。
下記内容が実際に行った流れと、トラブルが発生した顛末です。
1.開発環境のフルバックアップ
【サーバー】wp-content 以下のデータを全てバックアップ
【データベース】MySQL のデータをバックアップ（phpMyAdmin でエクスポート）
2.本番環境のフルバックアップ
【サーバー】wp-content 以下のファイルを全てバックアップ
【データベース】MySQL のデータをバックアップ（phpMyAdmin でエクスポート）
3.本番環境への画像ファイルのアップロード
【サーバー】開発環境で整え直した画像を、「wp-content」以下のしかるべきフォルダーにアップロード。
4.本番環境へのテーマファイルのアップロード（適用前）
【サーバー】開発環境で利用したテーマファイルと同じモノを本番環境にもアップロードします。
しかし、この段階では適用はしていません。
【データベース】計画ではデータベースの「opiton」テーブルのデータを開発環境から本番環境に移植すれば自動でテーマファイルが切り替わる予定でした。
5.本番環境のデータベースに、開発環境のデータベース情報をアップロード
【データベース】いざ、開発環境からダウンロードしておいた、「option」テーブルを本番環境に上書きしました。
ブログのデザインは予定通り「Lion Blog」のテーマファイルに変わっていました。
しかし、このときトラブルが発生しました。
本番環境の管理画面にログインし検証を開始すると、新しい記事が作れなくなってしまったのです。
なんども準備と確認をして、段取りも決めて作業をしたのに失敗したのです。
6.phpMyAdmin で 500エラー ！サルベージ作業ことごとく失敗
【データベース】そこで、データベースをオリジナルのモノで全体上書きして復元することを試みました。
取り敢えず、本番環境を作業前に戻そうとしたんです。
ここから更に大きなトラブルにつながりました。
実は私の WordPress は10年以上の記事がデータベースに入っていて、17MB以上のデータになっているんです。
ZIP 形式で圧縮してバックアップをとっても2MB弱あるんです。
そう、PHP がアップロードできる制限値の 2MB と同等のファイルサイズだったんです。
この点は php.in ファイルを利用して上限を 10MB 以上にしておいたのです。
しかし、phpMyAdmin で 「インポート」すると「500エラー」、いわゆる「Internal Server Error」です。
これにはどうしていいか迷いました。
実はこの予期せぬ、「Internal Server Error」でデータベースのアップロードにしくじり、復元しようと元データから何度も試みましたが、直せなくなりました。
データベースのフルバックアップからのリストアを諦めて、テーブル単位での上書きなども試みましたが、これもことごとく失敗でした。
7.万事休すか！諦めるな、答えはネットにある！
もう、ダメか？ここまで続けてきたブログの過去のデータも復元できなくなったらどうしよう？
13時も過ぎていたので、取り敢えず、ブログが表示できる状態まで復元して、食事をすることに。
しかし、このとき、管理画面にログインができなくなっていました。
新しい記事が書けないのでは意味がない、「万事休す！」と思ったそのときあることが頭をよぎりました。
「諦めるな！答えはネットにある！」
食事を終えた私は Google 先生にこう問いました「phpmyadmin インポート internal server error」と。
先生はこう答えてくれました「汝よ、諦めるなかれ、Big Dump なるツールを使え」と（ちょっと脚色してますが）。
簡単に説明すると、Big Dump は 2MB を超えるデータもMySQL にインポート、この場合は dump して書き込めるというべきでしょうか。
すごく簡単で、bigdump.php にデータベース情報を書き込んで、ウェブサーバーのどこかにインポートしたい SQL ファイルと同階層にアップロードします。
その後にブラウザから bigdump.php にアクセスするとインポートするためのボタンが出てきてサクッとインポートが完了します。
もし、phpMyAdmin のインポート作業中に「Internal Server Error」が発生して苦労したら「Big Dump」を思い出してください（MySQL コマンド使って直接作業できる人は簡単に解決できるんだろうけど）。
私はこれで 10年以上書き溜めた 17MB のファイルを無事、データベースに復元させて WordPress を復活させることができました。
最後に
9月3日から始めたテーマファイル切り替え作業ですが、3日目で無事終わりました。
1日目はバックアップしてました。使っていたソフトの調子が悪くバックアップに1日もかかるとか、なんだったんでしょうね。
2日目は開発環境の構築と、新テーマファルの選定とテーマファイルのカスタマイズ、および開発環境の完成に費やしました。
3日の今日が一番濃いかったです。
開発環境での再テストをして、万全を期して本番環境に適用したのに、こんなトラブルが発生するとは。
まあ、こういったトラブルも記事にできるのでよしとしましょう。
新しいテーマファイルは目次も自動生成ですが、OGPやSNSのシェアコード、Adsens とかも管理画面から入れられるので便利です。
重い腰をあげて設定してよかったです。
次は世界に向けて、多言語化をします。
以上「WordPressメンテで、phpMyAdmin インポート中にInternal Server Errorでブログ崩壊も復活したお話聞いてくれる？」でした。
最後までお読みいただきありがとうございました。
宮川（@miyakawa2449）でした。
それではまた〜♪
コメント