先日、メインサイト以下senryutei.sakuraweb.comのサイトをすべて吹っ飛ばしました。
なんちゃってマルチサイト化の残骸を処置し損ねまして、本館、本稿（「WordPressで小説サイト！」）、天キャベ、エンサイクロペディア、画房、閑雲亭、計6つのWordPressが見事白紙。流石に血の気が引きましたね。
要はさくらのコントロールパネルから旧サイトのWordPressを削除したら、その下のディレクトリにあったすべてが消えたという至極当たり前のコトなのです。さくらのコントロールパネルにいつまでも旧サイトの幽霊が存在しているのが心地悪くて、つい「アンインストール」のボタンをポチったらすべてが消えてしまったという阿呆としか言いようのないミスなのですよ。全く、一杯加減 1でコントロールパネルなんかあけるもんではありませんな。
閑雲亭にはサラッと書きましたが、自戒と備忘録のためにもういちどここで復旧の道程をまとめておこうと思います。
バックアップは命綱
何当たり前のコト言ってるんだ、と思われそうですが、これはどれだけ時代が移っても真理です。
今回、吹っ飛ばす2日前にたまたまデータベースのアップデートをしていました。MySQL5.7から8.0へ移行するため、データベースそのものを新バージョンのサーバへコピーしたわけです。このデータベースのアップデート作業そのものはサーバ会社 2側でやってくれるので、ユーザ側でやるのは事前のバックアップ及び無事データコピーが終わった後にデータベースをWordPressに接続してやることぐらいです。
このデータベースの接続、というのがLocalで散々悩まされた「データベース接続エラー」の解決手段だったのです。
config.phpを開けると恐ろしげな謎の呪文がぞろぞろと書いてあるのですが、実際のところMySQL 設定を書き換えるために必要なのは
/** WordPress のためのデータベース名 */
define(‘DB_NAME’, ‘データベース名’);/** MySQL データベースのユーザー名 */
define(‘DB_USER’, ‘ユーザー名’);/** MySQL データベースのパスワード */
define(‘DB_PASSWORD’, ‘パスワード’);/** MySQL のホスト名 */
define(‘DB_HOST’, ‘ホスト名’);
ぐらいのものです。もっと言えばデータベース名やユーザ名、パスワードは変更していなければ書き換える必要もなくて、大事なのはホスト名というやつですね。ここを書き換えることで、参照するデータベースの在処をWordPressに教えてやるというわけです。今回のアップデートでは、サーバ会社のほうからここにつくりましたぜ、というお報せをくれるのでそれをコピペすればいいという次第。
話を戻しまして…
今回吹っ飛んだのはWordPress本体だけだったので、データベースは無傷。上記のようにデータベースの移行前にフルバックアップをとっていたので、そこから吹っ飛んだWordPressのファイルをもう一度サーバにアップロードした上で、改めてデータベースと接続してやれば復旧完了となります。
よかった、バックアップとっといて…
サイト弄る前のバックアップは必須です。いや本当に。
バックアップも使えなかったら只のゴミ
さくらのレンタルサーバにはSnapupというバックアップ＆ステージング機能がありまして、WordPressサイトひとつひとつについて別々にバックアップをとり、状況に応じてステージングサーバという試験環境で確認をすることが出来ます。このSnapUpにおいておけるバックアップファイルの数には上限がありまして、柳はそれぞれのバックアップファイルをローカルへダウンロードしていました。
今回コトの直前にエンサイクロペディアのカスタムフィールドが表示されないという不具合が起きていまして、調整のためにエンサイクロペディアはファイルをSnapUpに置いていました。だからエンサイクロペディアについてはバックアップファイルを本番環境にレストアするだけで良かったのですが、問題は本館。ファイルが多すぎてさくらのファイルマネージャのアップロード上限を軽く越えてしまい、頭を抱える羽目になりました。
バックアップ、あっても使えなきゃ意味がない。
そこで登場したのがFFFTP。FTPのソフトです。有難いことにはフリー。
その昔、（といってもスタンダードプランに乗り換える前までなので、五年かそこらですが）さくらのクイックインストールが使えるようになるまでWordPress本体だって直接アップロードしてたんだから、やってやれないことはないのでした。
SnapUpにアップロードする方法までは流石に考えつかなかった 3ので、本番環境のディレクトリをつくりなおしてローカルに展開したバックアップファイルをまるっと転送しました。こんなバクチ、サイトが吹っ飛んだときぐらいしか怖くてできません。でもまあ、結果オーライでございました。
ファイルはあるのに表示されない謎に関するTips
かくて、WordPressはアップロード出来ました。
しかしWordPressは存在するのにログイン出来なかったり、ログインしてもまっさらなWordPressだったり、トップページは表示させるのにコンテンツは表示されなかったりというトラブルについて…対処するTipsをここに書き留めておきます。どれが何に効いたのか、今となっては実のところよくわからなかったりするので…まあ呪文のようなもんだと思ってください。
データベース接続エラー
冒頭にも挙げた、WordPressが読みに行くべきデータベースを探せない状況。config.phpからMySQLの設定を確認し、必要に応じて書き換えて再読み込みします。WordPress本体が吹っ飛んでいても、WordPressの最終バックアップ日付より後に書いた投稿がデータベースから拾える場合があります。前項「Advanced Custom Fieldsの迷惑な話」はそうやってサルベージされました。万歳！
index.php
実際にはサブディレクトリにあるWordPressをルート直下に置きたい場合に、サブディレクトリにあるindex.phpに以下のような改変を加えた上でルートディレクトリへコピーするのですが、これがうまくできてなかったらサイトが迷子になります。ここもチェックポイント。
/** Loads the WordPress Environment and Template */
require DIR . ‘/（WordPressのあるディレクトリ名）/wp-blog-header.php’;
上記の改変を加えたindex.phpがルート直下にあれば、ルートをサイトアドレスにしていても、サブディレクトリにあるWordPressが読み込まれるという仕組みらしいです。
.htaccess
上記と同様のシチュエーションで、.htaccessというファイルをルート直下にコピーして
RewriteRule . /（WordPressのあるディレクトリ名）/index.php [L] となっているのを
RewriteRule . /index.php [L] に書き換えます。
パーマリンク再設定
【ダッシュボード】→【設定】→【パーマリンク】から 何も弄らずに【変更を保存】を押します。上記の.htaccess書き換えと同じことをやっているらしいのですが、詳細不明。でもこれをやるとトップページしか表示されないというトラブルは改善しました。柳としましては既におまじないレベルの理解ですので、他に手がないという時に駄目モトで試すということにしておいてください。（＜ヒドい…）
残った問題
さて、無事にサイトは復活したのですが…
復帰後にそれぞれのサイトを点検していると、問題点がいくつか見つかりました。いずれもプラグイン系のトラブルです。まあ、プラグインに頼ることの弊害はよく聞く話なので…また対策することに致しましょう。
エンサイクロペディア
ACF不具合（一応復旧したけど、いつどうなるか）
千柳亭画房
Robo Galleryはやっぱり使えない（またやるはめになりましたよ黒ひげ危機一発）
FileBird Liteの動作が不安定（本館で使ってるほうは問題なく動いてるのに？）
コメント