玄関を開けたら蜘蛛の巣と綿埃でがんじがらめのカマキリが扉に張り付いて。こんな老眼のぶきっちょに助けを求められても無理な相談なのよ。
こんにちは。imoimoです。
てきとーな製作をやっております。
暴れん坊のカマキリも、蜘蛛の巣が絡まるとこんなにも身動き取れないなんて何だか可哀想です。
確か一昨日あたりに窓に張り付いていたヤツと同じだと思うのよ。他人の気がしないけれど暴れるから取ってあげることもできないし、家に入れたら猫達の格好の餌食だから結局何もしてあげられず終い。何から何まで頼る相手を間違えているヤツね。
さてさて。製作の方はともかくも、WordPressを動かしていたサーバーを引越ししたら動かなくなりまして。
そもそもが舐めてかかっていたのが運の尽き。結局腰を据えて修復しなくてはならなくなりました。
サーバーの
引越しは気を付けてやりましょう、て言うのはもう言い尽くされた話です。でも一方で「WordPressの引越しはカンタン」と言う話もよく聞きます。
それはね。ツールが世の中沢山あるからなのよ。
ツールも使えず勝手も分からずにただファイルをコピペしただけではやはりダメでした。
ようやく目鼻が付いたので、一応分かってきたことを整理しておきます。
基本的な手順は
手順１
元のサーバーの管理画面から、WordPress用のデータベースを丸ごとエクスポートして手元にバックアップする。
この時に、詳細なオプションを取り敢えず全部入れておく。
クエリの上限は1000にする。でもこれは結局理由分からず。50000とかじゃダメなの？
手順２
WordPressと言うか、ホームページ関連のファイルをまるごと手元にバックアップする。
ホームページ関連のファイルは大抵HT-DOCSみたいな、それっぽい名前のフォルダにある。
バックアップするにはFTPソフトを使う。FFFTPとか(→ダウンロード)。
手順３
新しい方のサーバーの管理画面から、空のデータベースを新規に２つ作る。
本来は１つで良さそうだけど、今回全然うまく行かなかったから２つを推奨します。
手順４
片方のデータベースに、バックアップした旧データベースをインポートして復元する。
今回の作戦は、新しく入れたWordPressにテーブル毎にデータを移すもの。コピー用のデータベースを作る目的です。
手順５
最新版のWordPressをダウンロード。解凍してから全部ホームページ用のフォルダにアップロードする。
普通は例えば/WPみたいなフォルダを作ってからアップロードするみたい。
wp-config.phpファイルをsampleファイルから修正して作成する。
修正するのはphpMyAdmin関連のIDとパスワード、サーバーの在り処などの項目。これはちょっと検索すればどこででも説明されてるから割愛なのよ。
参照するデータベースは空っぽの方。
あ。修正はメモ帳でやるのは良くないみたい。UTF-8の文字コードが扱える例えばTeraPad（→ダウンロード）とかで修正するんだってっ。
手順６
ブラウザから【URL】/wp/wp-install.phpみたいに打ち込んで、インストーラを動かす。
登録画面が立ち上がってユーザー名とかサイト名の設定を聞かれるけれど、仮なのでそれなりに。
後でこの情報も元のデータベースからコピーしちゃうので気合は不要です。
手順７
空のWordPressが呼べるかURLをブラウザから打って動作確認。
続いて【URL】/wp-login.phpをブラウザから入力してログイン画面が呼べるか確認。
ログインはさっき設定した仮のユーザー名とパスワードで行う。
管理画面と言うかダッシュボードが表示されれば取りあえずうまく行ってるみたい。
手順８
使っているテーマも先に入れてしまう。
今回はCocoon（→ダウンロード）だったので、ダウンロードしたzipファイルをテーマ設定画面で読込して有効化する事で設定しました。
ま、この辺は通常運転のやり方なので検索すればすぐわかるよねぇ。
なんて不親切なヤツ…
Cocoon作者のわいひらさんを見習えって。物凄くマメで丁寧で親切よ。
さぁて。
空っぽのWordPressが動いているので、ここから中身を一つずつ移し替えて行こうと言うのが今回の作戦。
一つずつ移し替えれば、どこかできっと元通りのログインもダッシュボードも開けなくなると思うのです。それで原因を大体特定できそう。
サーバーの管理画面から、さっき古い方のバックアップを読ませたデータベースを開きました。
テーブルごとにエクスポートして、空っぽの新しいデータベースにインポートして行こう。
空っぽとは言え、WordPressがインストールされたので同じ名前のテーブルがあります。こいつらのレコードを古いものに書き換えて行く作戦ね。
無難そうな所から行きました。
あ。今回もテーブルのエクスポートをする時は詳細オプションは全部✓。
- wp_users
- wp_usermeta
問題無し。以前のユーザーでログインできるようになりました。
インポートは追加読込じゃなくて上書きみたい。さっき入れた仮のユーザー情報は消えちゃったみたいです。
- wp_terms
- wp_termmeta
“term”なんちゃらはとりあえずこの二つから。なんだか”relaitonships”とか”taxonomy”とか付いている名前のは危険な匂いがするので後回しにしました。
これも問題なし。普通に動いています。
そろそろ目当ての本文を入れてみようかしら。
- wp_posts
- wp_postmeta
画像とかはまだ入れてないから無いけれど、記事が復活しました。今の所良い調子。
それじゃあさっき見送った奴ね。
- wp_term_relationships
- wp_term_taxonomy
何が復旧したのかは分からないけれど、問題無し。
他のテーブルはテーマやプラグイン関連だけど、あちらこちらの記事で言われている通り引越がトラブル原因は大体テーマやプラグイン絡みの様で。
今回はテーマやプラグインは入れなおす事にして一切復旧させない事にしました。
そうなると残るのは
- wp_comments
- wp_commentmeta
コメント関連ね。過疎なWordPressでコメントは無かったから新しいデータベースとレコードは同じ。だから復旧は見送りました。
- wp_links
リンク関連なのかしら。これまた何もやっていなかったみたいで同じ内容だったので見送りました。
想像するに、コメントやリンク絡みのテーブルは復旧させても問題は無さそうです。
wp_options
テーブルを移し替えたら。
BINGOoooo!!
ハイ。ダッシュボード出なくなりました。
ログイン画面ですらレイアウトが滅茶苦茶。犯人はこれね。
巷の記事で「テーマを止める」「プラグインを止める」とよく書かれていますが、テーマのファイル名やフォルダ名を変えてもダメ、プラグインも同様と言うのが今回のトラブルでした。
wp_optionsテーブルは凄く大きくて、試しに印刷したら紙が膨大に出て来て読む気にもなりませんでした。
いろんなテーマやプラグインその他諸々の設定情報が全部載っているみたい。
wp_postsが本文の実体だとすると、wp_optionsは体裁や動作の設定の実体のテーブルみたいなものなのかしら。
ま。今回はwp_optionsテーブルをもうコピーしちゃって元の木阿弥になったのでまた手順１からやり直しましたが、同じ目に合っている方がいたらwp_optionsテーブルは諦めましょう。
これで結構普通にWordPress復旧するみたいです。
今回のトラブルの原因は今となっては正確には分からないけれど、恐らく古くて開発も終了しているプラグインが残っていたのが原因だったのではないかと思います。こいつのオプションデータを読み込んでおかしくなったんじゃぁないかしら。
画像とかは
wp-contentsフォルダの下の/uploadsフォルダに入っているので、前のサーバーから持って来たバックアップからフォルダごとアップロード。
これで画像も表示されるようになりました。
…あれ？
一部画像がNO IMAGEになっちゃうな。
前のサーバーは途中から独自ドメインにしたのでメディアのリンク名のURLが古いままのものがある様です。
取りあえずwp_postsテーブルに目につく形で古いURLのかかれているカラムがあったので、サーバーの管理画面からデータベースを開いてSQLを直打ちしました。
これよ。
UPDATE テーブル名 SET カラム名=REPLACE(カラム名,”置換対象”,”置換後の文字”);
テーブル名はwp_postsね。カラム名はいわば列の名前。置換対象は間違っているURL、置換後の文字は正しいURL。テーブル名とかカラム名には’とか”で挟む必要は無かったです。
これで一発変換完了。
他の所にもありそうだけど、まずは動作確認して。
管理画面から修正する方が無難そうなので素人がSQLを振り回すのはここまでにしました。
かくして。
２週間以上かかりましたが、WordPressの手動お引越しはどうにか完了と相成りました。
細かい所は気にしない感じの復旧となりましたが、動かないよりはマシよ。
と言うわけで教訓。
wp_optionsには手を出すなっ!!
そんなこんなでお粗末様でした。
コメント