この記事では、WordPress更新失敗、リダイレクトループ、WordPressの削除、WordPressの再インストール、リストア、サイト復元まで、私がやった一連の流れをお送りします。
- リダイレクトループ発生原因の調べ方
- ConoHaWINGでWordPressを削除する方法
- ConoHaWINGでWordPressを再インストールする方法
- ConoHaWINGで自動バックアップよりデータをリストアする方法
- ConoHaWINGでリストアされたデータからサイトを復元する方法
というわけで、昨日の早朝、WordPress 5.8.3を5.9へ更新しました。
厳密には更新失敗しました。
はい。
やっぱり、更新作業は慎重にやらなくちゃねと、思い知らされた1日となりました。
WordPress5.9は今のところ不具合が多いそうなので、まだ更新しないほうがイイみたいです。
ちなみにWordPressとは、これ。
WordPress（ワードプレス）は、オープンソースのブログソフトウェアである。
このサイト「tobitaka」もWordPressで作られています。
誰でもブログをつくることができるソフトウェアです。
このWordPressの更新のお知らせが来ていたから、素直に更新したわけです。
この記事が参考になるのは以下のような方です。
- ConoHaWINGを使用中
- ConoHaWINGでWordPressを削除する方法を知りたい
- ConoHaWINGでWordPressを再インストールする方法を知りたい
- ConoHaWINGで自動バックアップよりデータをリストアする方法を知りたい
- ConoHaWINGでリストアされたデータからサイトを復元したい
時系列でお送りします！それでは参りましょう。
リダイレクトループ発生原因の調べ方
8:00 WordPressを5.9へ更新→更新失敗のメッセージ
ダッシュボードを再読み込みするも、リダイレクトの表示に．．．
リダイレクトループが発生し、ログイン画面も表示されず。
サイトはレイアウト崩れ発生。
緊急事態。
8:30 リダイレクトループ発生時の対処法はことごとく失敗
WordPressの更新失敗といっても、リダイレクトループが発生しているので、「通常のリダイレクトループの対処法」、以下のことをやる。
- ブラウザのキャッシュクリア
- プラグインの「Redirection」を無効にする
- ConoHaのコントロールパネル＞サイト管理＞サイトセキュリティ＞WAFタブで「WAFの利用設定」をOFFにする
普段はこの3つをやれば収まっているんだけど．．．
ブラウザのキャッシュクリア
はい、変化なし。
プラグインの「Redirection」を無効にする
．．．できない、だってログインできないし。
「WAFの利用設定」をOFFにする
ConoHaのコントロールパネル＞サイト管理＞サイトセキュリティ＞WAFタブで、「WAFの利用設定」をOFFにする。
「WAFの利用設定」をOFFにする
変化なし。
やっぱり、ただのリダイレクトループじゃないっぽい。
9:30 リダイレクトループの原因がどこにあるか探す
ググって以下のことを試す。
- ConoHaのファイルマネージャーより、「wp-content」の中の「plugins」をリネーム
- ConoHaのファイルマネージャーより、「wp-content」の中の「themes」をリネーム
リネームとは、名前を変更することです。
「wp-content」の中の「plugins」をリネーム
有効化しているプラグインを強制的に無効にして、プラグインなしでサイトが動くかを確認する作業です。
「wp-content」の中の「plugins」をリネーム
「plugins」を「_plugins」のように名前を変更して、ログイン画面が表示されるか確認。
これで表示されれば、「plugins」フォルダの中にあるプラグインのどれかが、リダイレクトループを引き起こしている可能性あり。
はい、変化なし。ちーん。
ちなみに「SiteGuard WP Plugin」というプラグインを使用しているので、普段はログインURLの末尾がlogin_5桁の乱数になっています。
プラグインを無効にしているということは．．．
もしかしたら、ログイン末尾を「wp-login.php」に変更すれば行けるかも！
ちーん。
「wp-content」の中の「themes」をリネーム
「WordPressのテーマがリダイレクトループを引き起こしている可能性もある」という文言を発見したので、「plugins」と同様に、早速リネーム。
こちらは、使用中のテーマを強制的に無効にして、サイトが動くかを確認する作業。
これもダメ。
10:00 ConoHaサポートに問い合わせる
万策尽きました。もっと勉強しなければと反省しきり。
限界値を超えたので「迷惑だよな～」と思いながらも、ConoHaサポートに問い合わせ。
ConoHaWINGでWordPressを削除する方法
やはり、原因はWordPress更新による不具合しか考えられなかったので、いったんリセットすることに。
10:30 WordPressを削除
WordPressの更新で失敗しているのだから、今入っているWordPressをいったん削除して新しく入れなおすのは大丈夫。
- FTP「FileZilla」を使いバックアップを取る
- データベースを残し削除
FTP「FileZilla」を使いバックアップを取る
削除する前に、サーバーにあるデータのバックアップをローカルに残しました。
ただし、一抹の不安が．．．
WordPressの更新途中でエラーになったのなら、サーバーにあるWordPressに不具合があるわけで、それをまた入れなおしても意味がないような．．．
データベースを残し削除
- ConoHaコントロールパネル＞サイト設定＞WordPressタブを開く
- 削除したいサイトURLの右端にあるゴミ箱をクリック
- ポップアップをよく読み、データベースを残すため、□にチェックを入れずに「はい」をクリック
ConoHaコントロールパネル＞サイト設定＞WordPressタブを開いたら、削除したいサイトURLの右端にあるゴミ箱をクリックします。
ポップアップをよく読みます。
今回はデータベースを残すので、□にチェックを入れずに「はい」をクリックしました。
conoHa データベースを残し削除サイトの復元が目的なので、データベースを残しました。
ConoHaWINGでWordPressを再インストールする方法
私の頭の中では、削除→再インストール→元データベースにつなぐというシナリオができていたので、次は、WordPressを再インストール。
- ConoHaコントロールパネル＞サイト設定＞WordPressタブを開く
- 右上にある水色の「＋WordPress」のボタンをクリック
- 「新規インストール」を選び、必要事項を入力して保存する
10:40 WordPressを再インストール
conoHa WordPressを再インストールまず、ConoHaコントロールパネル＞サイト設定＞WordPressタブを開きます。
右上にある水色の「＋WordPress」のボタンをクリックすると、下記の画面が出ます。
「新規インストール」を選び、必要事項を入力して保存します。
私にとっては再インストールですが、ここは「新規インストール」を選択。
そして、なんと、サブディレクトリを指定し忘れるという失態をおかしました。
注意 このタイミングで、ConoHaWINGの「自動バックアップ」からリストアするのが正解！
ここまでに、データのバックアップ、WPの削除、WPの再インストールを終えました。
この後、
- FTPでデータを上書き
さらに「サブディレクトリの指定忘れにより」
- 再度、WPの削除、WPの再インストール
をしますが、これらは必要ありません。
この後の、ConoHaWINGで自動バックアップからWordPressをリストアする方法を参考にしてください。
10:50 バックアップしていたデータをFTPで転送し上書き
バックアップしていたデータを「FileZilla」で転送し上書き。
11:00 [500 Internal Server Error]と[FatalError]が発生
ログイン画面はリダイレクトループから「500 Internal Server Error」へ、サイトはFatalError（致命的なエラー）へ。
致命的って。くっ、苦しい。
いったん落ち着くため、買い物へ出かけます。
そして途中で「もしかして、サブディレクトリ、指定してなかった？？？」、頭から離れなくなり、買い物が上の空に。
14:30 ConoHaサポートより返信が．．．
なんとなんと、ConoHaサポート様より返信が。
しかしながら、個人的なことですから、具体的な回答をしていただくことはできませんでした。
ただ、メールにはこんなことが．．．
そうなんです。
だから、もう1度、削除して、再インストール。
次の再インストールでサブディレクトリを指定すれば、今度こそ行ける！
18:30 もう1度、WordPress削除・再インストール
そしてもう1度、WordPressを削除・再インストールしました。
今度は、サブディレクトリも指定。
っていうか、「なんでサブディレクトリ作っちゃったんだ？？？」と後悔。
そして2度目の削除と再インストールをしている時に発見します。
「自動バックアップ」
？？？．．．えっ、ここから行けんじゃね？
ConoHaWINGで自動バックアップからデータをリストアする方法
ちなみにこの後、自動バックアップよりリストアします。
「リストア」とは復元することです。
ちなみに私は、WordPressのレンタルサーバーにConohaWING
を使用しています。
自動バックアップは、このようなピンチの時にとても便利なのでおすすめです。
と、その前に、再インストールでしっかりサブディレクトリを指定したので、ログイン画面が表示されるか、サイトが正常に動くか試しに確認。
ち～ん。
19:00 自動バックアップよりWebとデータベースをリストア
ConoHaWINGには自動バックアップという機能がありました。
あることを忘れていました。
気がついてよかった。
- ConoHaコントロールパネル＞サーバー管理＞自動バックアップを開く
- 戻したい日付の「Web」「Mail」「DB」からリストアするデータをクリックする
- ポップアップが出るので、よく読んで「リストア」をクリック
ConoHaコントロールパネル＞サーバー管理＞自動バックアップを開きます。
自動バックアップよりWebとデータベースをリストア戻したい日付の「Web」「Mail」「DB」から「リストア」するデータの「リストア可」をクリック。
下のようなポップアップが出るので、よく読んで「リストア」をクリック。
これは「Web」のリストアを選んだもの。
自動バックアップよりWebとデータベースをリストアこのあと、同様にDB（データベース）のリストアもしました。
両方合わせて15分から20分くらいかかったかな、という感じです。
ちなみに「リストア履歴」には、リストアした情報が記録されます。
Webのリストアデータの保存先は、ConoHaファイルマネージャーから確認できます。
「backup_data_web」というフォルダが出現しています。
Webのリストアデータの保存先
DB（データベース）のリストアデータの保存先は、ConoHaコントロールパネル＞サイト管理＞データベースで確認できます。
新しいデータベース名（元データベース名_リストアした日付8桁_数字1桁の形式）が出現しています。
リストアされたデータからサイトを復元する方法
何とか見通しが立ちました。
この後は、以下のように進めます。
- リストアした「backup_data_web」のデータをローカルへダウンロード
- サーバーの「○○○@localhost」下へダウンロードデータを上書き
- ConoHaコントロールパネル＞サイト管理＞データベースで、先ほどリストアしたデータベースのネームタグをリネーム
- 「wp-config」を新しいデータベース情報に書き換え
- ConoHaコントロールパネル＞サイト管理＞データベースのユーザーで、接続先データベースを変更する
19:20 リストアした「backup_data_web」をローカルへダウンロード
リストアした「backup_data_web」をConoHaファイルマネージャーより、ローカルへダウンロードします。
「backup_data_web」を右クリックして「ダウンロード」を選択。
リストアした「backup_data_web」をローカルへダウンロード
ファイルサイズが大き過ぎるのか何度もエラーになり失敗。
「public_html」フォルダのみで再度ダウンロード
「backup_data_web」を丸ごとダウンロードだと失敗するので、「public_html」フォルダのみをConoHaファイルマネージャーより再びローカルへダウンロード。
これまた失敗。ファイルサイズ的に大丈夫かと思いましたが．．．
FTP「FileZilla」で「public_html」をダウンロード
ConoHaファイルマネージャーからダウンロードするのをあきらめ、結局、FTP「FileZilla」経由にしました。
時間がかかりましたが、「public_html」のダウンロードに成功。
20:40 サーバーの「○○○@localhost」下へダウンロードデータを上書き
ローカルへダウンロードしたデータを、FTP「FileZilla」経由で、サーバーの「○○○@localhost」下にある「public_html」へ上書きします。
サーバーの「○○○@localhost」下へダウンロードデータを上書き無事終了。
21:15 リストアしたデータベースのネームタグをリネーム
リストアしたデータベースのネームタグをリネームConoHaコントロールパネル＞サイト管理＞データベースを確認してみると、上から
- 「リストアしたデータベース ○○○_new」
- 「新規インストールの時に作ったデータベース」
- 「元データベース ○○○」
があります。
画像の「○○○_new」は、すでにリネームした後のものです。
リストアしたデータベースのネームタグは最初、「○○○_日付(yyyymmdd)_数字1桁」の形式になっています。
○○○の部分が「元データベース」と一緒でややこしいので、「○○○_日付_数字1桁」を「○○○_new」のように変更しています。
「_new」のような感じで、リストアで新しく作ったデータベースということがわかるようにしておきます。
21:40 「public_html」の中の「wp-config」を編集する
先ほど上書きした「public_html」の中のサイト名フォルダーの中から「wp-config」を編集します。
通常は編集前にバックアップを取りますが、今回はローカルにすでに「public_html」があるので取っていません。
必要な場合には「wp-config」を、右クリック→ダウンロードしてバックアップを取ったほうが安心です。
「wp-config」には、データベースに関わる設定が記述されています。
だから、該当部分を新しい内容に書き換える必要があります。
ConoHaファイルマネージャーを開きます。
「public_html」の中のサイト名フォルダーの中から「wp-config」を探し、右クリック→ファイル編集→ACE Editorを、下記のように選択。
「public_html」の中の「wp-config」を編集
エディターが開いたら、下記のピンクの線で囲った2か所を編集します。
「public_html」の中の「wp-config」を編集それぞれ、下記のように書き換えます。
「define( ‘DB_NAME’, ‘リストアしたデータベース名’ );」
リストアしたデータベース名は「元のデータベース名_リストアした日付_数字1桁」の形式です。
「define( ‘DB_USER’, ‘新しいデータベースユーザー名’ );」
どちらも、ConoHaコントロールパネル＞サイト管理＞データベースを開くと確認できます。
ここで試しに、ログイン画面が表示されるか、サイトは表示されるかを確認。
「Error establishing a database connection」
はい、出ました。
「データベースの接続ができとらんぞ！」
どうやら、データベース関係の何かがおかしい．．．
22:00 新しいデータベースの接続先データベースを変更
とりあえず、「wp-config」をもう1度確認しましたが、記述に間違いは無さそう。
もう1度、ConoHaコントロールパネル＞サイト管理＞データベースを開いて、何か変更できるところがないか確認。
ConoHaコントロールパネル＞サイト管理＞データベースのユーザーのところに、「接続先データベース」という項目が．．．
新しいデータベースの接続先データベースを変更
新データベースユーザーの接続先データベースが新しいデータベースのタグのままになっていました。
なので、リストアした「○○○_new」のネームタグに変更します。
接続先データベースの右端の編集ボタンをクリックして変更しました。
さて、ワクワク、ドキドキ。
ブックマークしてあるログイン画面にアクセス。
出ました！ログイン画面出ました！
まとめ
と、いうわけで、朝8:00から始まり、すべての作業を終えてサイト復活したのが、22:10でした。
ググりながらいろいろと試しましたが、はっきりとした原因はつかめず．．．
プラグインやテーマに起因するものでなさそうだったし、WordPressの更新失敗が原因かと。
反省を込めて、1日を振り返り、今後のために忘備録備忘録をつくっておきました。
これ大事。
もし同じように困っている方いたら、参考になると嬉しいです。
また、WordPressでブログを始めたいと思っている方にオススメなレンタルサーバーが、ConohaWINGです。
今回のようなトラブルの際には「自動バックアップ」がとてもありがたい。
あれやこれやとやって結局はっきりと原因がつかめませんでしたが、何かお役に立つことがあればうれしいです。
