このブログサイトのために使っているWordPressが突然、次の状況になってしまいました。
ポイント
- WordPressの投稿管理画面で記事の一覧が表示されなくなった
- WordPressからログアウトしたらログインできなくなった
- パスワードの再設定もできない
解決するまでに3日半かかりました。
これはその3日目から解決するまでの記録です。
1日目と２日目の記録は以下の記事になります。
-
WordPressにログインできなくなってから復旧までの3日間の記録 Day1
このブログサイトのために使っているWordPressが突然、次の状況になってしまいました。 結論から言うと、プラグインのSiteGuardを無効にすることでログインできるようになりました。「そんな簡単 ...
続きを見る
-
WordPressにログインできなくなってから復旧までの3日間の記録 Day2
このブログサイトのために使っているWordPressが突然、次の状況になってしまいました。 解決するまでに3日半かかりました。今日はその2日目の記録です。1日目の記録は以下の記事になります。 解決まで ...
続きを見る
解決までの3日半、調べては試すことを延々と繰り返しました。
無我夢中だったので忘れてしまったこともありますが、覚えている限りの経過を記録しておきます。
レンタルサーバはConoha Wingを使用しているので、ファイル編集の方法などはそちらの画面を使って説明しています。
WordPressログイン障害 ３日目にやったこと
ConohaWingのバックアップデータで、ログインできていた日の状態に復元
ConohaWingには自動バックアップの機能があり、過去14日までさかのぼって、WordPressサイトの状態を指定した日に戻すことができることがわかりました。
これだ！と思い、WordPressにログインできなくなる前の日に戻す作業を行いました。
大まかな手順は以下の通りです。
- ConohaWingの自動バックアップ画面で復元したい日付のWebとDBをリストアする
- Webを復元する
バックアップしたWebのwp-config.phpとfunctions.phpを一度ローカルにダウンロードし、サーバのサイトドメインのしかるべきフォルダににアップロードする - DBを復元する
バックアップしてできたデータベースのネームタグをConoha WIngで変更し、データベースの参照先を変更後のデータベース名に修正する
１．Conoha Wingの自動バックアップ画面で復元したい日付のWebとDBをリストア
Conoha Wingにログインし、①サーバー管理 → ②自動バックアップ の順に選択します。
③バックアップ が表示されるので、バックアップ取得日から、復元したい日付を選び、WebとDBの「リストア可」をクリックします。
「リストアを開始しますか」のポップアップが表示されるので、「リストア」をクリックします。
「この操作は取り消せません」と書かれているのでちょっとビビりますが気にしなくても大丈夫です。
リストアには数分の時間がかかります。
ここで一点、知っておきたいことがあります。
ポイント
ここでいう「リストア」とは、「指定した日付時点のデータを回収してサーバーに保存した」ということにすぎません。
これだけではWebサイトを復元したことにならないことに注意しましょう。
復元するには、リストアしたファイルを、公開されているサイトドメインの正しい位置にアップロードしたり、ファイルを編集したりレンタルサーバの設定を変更したりしてデータベースの参照先を変更する必要があります。
また、サーバーに保存されたデータ（ファイル）は24時間後に削除されるので、取っておくためには、自分のパソコンにダウンロードする必要がありますが、そのためにはFTPソフトを使います。（この記事ではFTPの説明はしません）
Webを復元する
「リストア」とは「復元」のことなので、リストアが完了するとWordPressが復元できたと勘違いする人もいるかと思います。
しかし実際は、そのデータ（ファイル）を、公開しているサイトのしかるべき箇所にアップロードして初めて完了します。
リストアされたデータ（ファイル）の場所は次のように確認します。
Conoha Wingにログインし、 ①サイト管理 → ②ファイルマネージャー の順に選択します。
ローカルホストにできているbackup_data_webが今回リストアしたフォルダです。
バックアップされたデータ（ファイル）は24時間後に削除されてしまうので、自分のパソコンにダウンロードする必要があります。
でも、このフォルダに入っているファイルの量がとても多いため、確実にダウンロードするには、FTPソフトを使います。
ソフィーはFTPでバックアップをローカルに保存しましたが、それをやらなくても復元はできるので、この記事ではFTPの操作方法は説明していません。
今回はpublic_htmlの中の必要なファイルのみダウンロードします。
必要なのは次の２つです。
①～の手順で目的のファイルを探します。
- functions.php
① ××××@localhostフォルダ → ②backup_data_web → ③public_html → ④自分のサイトのドメインフォルダ → ⑤wp-content →
themes → 使用中のテーマ - wp-config.php
① ××××@localhostフォルダ → ②backup_data_web → ③public_html → ④ 自分のサイトドメインフォルダ
①の××××部分は『データベース名+Conohaアカウント名』の組み合わせになっており、人によって異なります。
①上記ファイルを右クリック → ②プルダウンメニューから「ダウンロード」を選択します。
ダウンロードしたファイルはパソコンの任意の場所に保存します。
次に、ダウンロードしたファイルを、復元したいドメインのフォルダにアップロードします。
復元したいドメインは以下の場所にあります。
functions.phpは public_html → 自分のサイトのドメインフォルダ → wp-content→ themes→ 使用中のテーマ の配下にあります。
wp-config.phpは public_html → 自分のサイトドメインフォルダ の配下にあります。
以下はfunctions.phpのアップロード方法ですが、wp-config.phpはフォルダの位置が違うので、そこだけ注意して同様に行います。
該当するサイトドメイン側のフォルダを開いたら、先ほどダウンロードしたfunction.phpをそのフォルダにドラッグ&ドロップします。
「"functions.phpというアイテム名はすでに存在しています」というアラートがポップアップするので、「はい」をクリックします。
Conoha WIngでは、FTPソフトを使わなくても簡単にファイルをアップロードすることができるので便利です。
funcsions.phpに続き、wp-config.phpもアップロードしました。」
さて、これでWebの復元ができました。
しかしながら、WordPressログインはできませんでした。
DBを復元する
Conoha Wingにログインし、①サイト管理 → ②データベース の順にクリックし、データベース一覧を確認します。
画面中央にデータベース一覧が表示されます。
バックアップすると同じ名称のデータベースができてしまい、紛らわしいので名称を変更します。
ここで表示される名称は「ネームタグ」と呼ばれるもので、実際のデータベース名は最後にはバックアップ日付が記載されているものになります。それをこれから確認します。
名称の左側の「＞」をクリックすると詳細情報が確認できます。
下図のように、「データベース名」の後ろに日付が記載されていれば、それがバックアップされたデータベースです。
そのネームタグを変更するには、①右側の鉛筆マークをクリックします。
ネームタグが編集できるようになるので、①ここではネームタグの最後に「-new」を追加して ②保存をクリックします。
データベース一覧がこのようになりました。
次に、接続先データベースを変更します。
Conoha Wingにログインし、①サイト管理 → ②データベース → ③ユーザー の下にユーザー名が記載されているので → ④ユーザー名をクリックします。
「接続先データベース」が表示されています。
右側のツールマークをクリックしましょう。
接続先データベースが変更できるようになるので、先ほど指定したネームタグを入力します。
次に、wp-config.phpを編集して接続先データベースを変更します。
Conoha Wing 管理画面で ①サイト管理 → ②ファイルマネージャーをクリックします。
public_htmlの下にある、サイトドメインのフォルダをクリックすると、右側のファイル一覧にwp-config.phpがあります。
①wp-config.phpを右クリック → ②ファイル編集 → ③ACE Editor の順にクリックします。
wp-config.phpの編集画面になります。
下図の例でいうと、23行目のdefine( 'DB_NAME', 'XXXXXXXXX' ); を編集します。
define( 'DB_NAME', 'XXXXXXXXX' ); の、XXXXXXXXXの部分がバックアップ前のデータベース名になっているので、バックアップ後のデータベース名に変更します。
ここでは先ほど変更したネームタグではなく、データベース名を入れてください
下図でいうと、「データベース名」に記載されているものです。
編集が終わったら、「保存して閉じる」をクリックします。
さて、これでデータベースの復元ができたので、WordPressにログインしてみました。
結果は、またしてもだめでした。
ログインできていた日の状態にまで戻したのに、どうしてでしょうか？？？
万策尽きて3日目の作業を修了。
いよいよWordPressの再インストールを検討し始めました。
4日目にプラグインのSiteGuardを無効にしてみた
朝からWordPressの再インストール方法を調べ始めました。
でも、やはりうまくいかなかったときのことが心配で不安です。
最後にもう一度、WordPressのログイントラブルについて検索してみると、プラグインのSiteGuardが邪魔していたという事例が見つかりました。
そこでダメ元でSiteGuradの無効化をしてみました。
Conoha Wingのファイルマネージャから 「public_htmal」→「サイトドメインのフォルダ」→「wp-content」→「plugins」→「siteguard」を選び、右クリックで「リネーム」を行い、「siteguardx」に変更しました。
すると、やっとのことでログインできるようになりました。
まとめ
あしかけ3日半にわたるWordPressログイン障害の対応経過をまとめました。
同じ悩みを持っている人の一助となれば幸いです。
結論としてはプラグインのSiteGuardが邪魔をしていたということになります。
でも、2日目にプラグイン全体の無効化をしたときには解決しなかったので、それだけが原因とも思えません。
いろいろやってきたことのどれかと合わせて、解決につながったと考えています。
ソフィーの推測としては、別のプラグインのJetPackと干渉していたか、連携しているブログサイトのWordPress.comと干渉していたかのどちらかではないかと考えています。
でもそれは推測の域を出ないので、参考にはなりません。
3日半かけて自由時間のほとんどをこの作業に費やしてきました。
解決策としては無駄なこともあったと思いますが、今回の作業を通じて以下のことがわかるようになりました。
初心者ブロガーとして一定の学びがあったということで、無駄ではなかったと思います。
- WordPressのファイル構成
- WordPressのファイル編集、ファイル名変更の方法
- phpMyAdminの使い方とデータベースの操作方法
- WordPress.orgとWordPress.comの違い
- FTPソフトの使い方
また、時間をかけてブログをまとめる過程にも多くの学びがありました。
問題は起きないに越したことはありませんが、問題が起きたとしてもそれをプラスにできるということも、ブログの運営を通じて学びました。
2024年6月24日更新
SiteGuardと干渉していたプラグインはWPS Hide Loginだったことが判明しました。
この日、JetPackをやめてSiteGuardに戻ることにしました。
WordPressの管理画面の動作が遅いことが気になったからです。
SiteGuardは削除してしまっていたので、もう一度インストールしして使用開始しました。
するとまたログインができなくなってしまいました。
それで、どのプラグインが邪魔しているのかを検証することにしました。
手順
①Conoha WingからSiteGuardプラグインのフォルダ名を変更することで無効化
②WordPressにログインした後、SiteGuard以外のプラグインを全て無効
③ひとつひとつ有効にしてはログアウト→ログインを繰り返す
以上の方法で、WPS Hide Loginを有効にしたとたん、ログインできなくなりました。
WPS Hide Loginは、SiteGuardと同様に、WordPressのログイン画面のURLを変更する機能があります。
考えてみれば当然のことでした。
けれど、たくさんのプラグインを入れていると、何が何だか分からなくなってしまうことも事実です。
プラグインを整理することも必要だなと感じたしだいです。