WordPressのサイトを移行・復元したあと、管理画面にログインしようとしたところ、なぜかログインできなくなりました。
phpMyAdminでデータベースを確認すると、wp_usersにはちゃんとユーザーが存在しています。
「ユーザーはいるのに、なぜログインできない？」
今回はこのような状態になったときに確認したいポイントと、対処方法をまとめます。
今回の症状
今回遭遇したのは、WordPressサイトを別環境へ移行したあとに管理画面へログインできなくなるという症状です。
- WordPress自体は表示されている
/wp-admin/にもアクセスできる- phpMyAdminで確認するとユーザーは存在する
- ユーザー名・パスワードを入力してもログインできない
特にサイト移行後や、バックアップからWordPressを復元したときに発生した場合は、データベースを確認してみましょう。
まずはwp_usersを確認する
phpMyAdminを開き、WordPressで使用しているデータベースを選択します。
ユーザー情報は通常、wp_usersというテーブルに保存されています。
ただし、環境によってはwp_の部分が異なる場合があります（後ほど説明します）。
wp_usersを開くと、以下のような項目があります。
IDuser_loginuser_passuser_emailuser_registered
まずはuser_loginを確認し、自分がログインしようとしているユーザーが存在するか確認します。
ユーザーが存在する場合
ユーザーが存在するのであれば、少なくともユーザー情報自体はデータベースに残っています。
次にパスワードや権限情報を確認していきます。
パスワードをデータベースから再設定する
パスワードが怪しい場合は、phpMyAdminから一時的にパスワードを変更できます。
なお、データベースを直接編集する前に、phpMyAdminの「エクスポート」からバックアップを取っておくと安心です。
wp_usersから対象ユーザーの「編集」を開き、user_passの「関数」をMD5に変更します。
値には、新しく設定したいパスワードを入力します。たとえば、
temporary-password-123など、一時的なパスワードを設定します。
保存後、https://example.com/wp-admin/から、
user_loginのユーザー名- 今設定したパスワード
でログインしてみます。
WordPressはログイン後、MD5で保存したパスワードをWordPressの通常のハッシュ形式へ自動で更新します。そのため、緊急時のパスワード再設定方法として利用できます。
もちろん、ログインできたら推測されにくい強力なパスワードへ変更しておきましょう。
wp_usermetaも確認する
ここが意外と重要です。
wp_usersにユーザーが存在していても、そのユーザーに管理者権限が正しく設定されていない場合があります。
WordPressのユーザー権限などは、wp_usermetaに保存されています。
対象ユーザーのuser_idを確認して、meta_keyがwp_capabilitiesのデータが存在するか確認します。
管理者の場合、値は基本的に以下のようになります。
a:1:{s:13:"administrator";b:1;}さらに、wp_user_levelが10になっているか確認します。
これらが存在しない、または壊れている場合、ユーザー自体は存在していても管理者として正常に扱われない可能性があります。
テーブルプレフィックスの違いにも注意
サイト移行時に意外とハマるのが、テーブルプレフィックスの違いです。
通常WordPressのテーブルは、wp_users・wp_posts・wp_optionsのようになっています。
しかし、セキュリティ対策などで、abc_users・abc_posts・abc_optionsのように変更されている場合があります。
WordPressがどのプレフィックスを使用するかは、wp-config.phpの以下の設定で決まります。
$table_prefix = 'wp_';たとえば実際のデータベースがabc_usersになっているのに、wp-config.phpが$table_prefix = 'wp_';になっていれば、WordPressは別のテーブルを参照してしまいます。
サイト移行後に問題が発生した場合は、「phpMyAdminで見ているテーブル」と「WordPressが実際に参照しているテーブル」が同じかを確認してみましょう。
wp_capabilitiesの名前にも注意
テーブルプレフィックスを変更した場合、wp_usermeta内のキーにも注意が必要です。
たとえばプレフィックスがabc_の場合、wp_capabilitiesではなくabc_capabilitiesになっている必要があります。同様に、wp_user_levelではなくabc_user_levelになります。
サイト移行時にテーブル名だけ変更した場合、この部分が古いプレフィックスのまま残っていることがあります。
ユーザーは存在しているのに管理者権限がおかしい場合は、このあたりも確認してみましょう。
Cookieやキャッシュも確認する
データベースに問題が見つからない場合は、ブラウザ側も確認します。まずは、
- Cookieを削除する
- キャッシュを削除する
- シークレットモードで試す
- 別ブラウザで試す
といった方法を試してみます。
特に、example.comからlocalhostや別のテストドメインへ移行した場合などは、Cookieの影響で正常にログインできないケースがあります。
siteurlとhomeも確認する
移行後にログイン画面がおかしい、ログインすると元サイトへ飛ばされる、といった場合はURL設定も確認します。
wp_optionsテーブルの、siteurlとhomeを確認します。
移行先がhttp://localhost/exampleなのに、https://example.comのままになっていないか確認しましょう。
URLが間違っている場合、ログイン処理後に別ドメインへリダイレクトされるなど、ログインできていないように見えることがあります。
プラグインが原因か確認する
ここまで確認しても原因が分からない場合は、プラグインの影響も疑います。特に、
- ログインURL変更系
- セキュリティ系
- 二段階認証
- ログイン試行回数制限
- CAPTCHA
などのプラグインが入っている場合は注意が必要です。
管理画面へ入れない場合は、FTPなどからwp-content/pluginsのフォルダ名を一時的にplugins_oldなどへ変更します。これで全プラグインを強制的に無効化できます。
ログインできるようになった場合は、プラグインのどれかが原因だった可能性が高くなります。
確認後はフォルダ名を元に戻し、プラグインを一つずつ有効化して原因を特定します。
WordPress移行後ならここを重点的に確認
今回のように「サイトを移行した直後からログインできなくなった」という場合は、以下を優先して確認すると原因を見つけやすいです。
wp_usersにユーザーが存在するかuser_passを再設定してログインできるかwp_usermetaに管理者権限が存在するかwp-config.phpのテーブルプレフィックスが正しいかwp_optionsのsiteurlとhomeが移行先URLになっているか- セキュリティ系プラグインが影響していないか
- Cookieやキャッシュを削除しても同じか
闇雲にWordPressを再インストールするより、この順番で確認したほうが原因を切り分けやすいと思います。
まとめ
WordPressで「データベースにはユーザーがいるのにログインできない」という場合、ユーザーそのものが消えているとは限りません。
特にサイト移行後の場合は、
wp_users → パスワード → wp_usermeta → テーブルプレフィックス → URL → プラグイン
という順番で確認すると、比較的原因を見つけやすいです。
個人的には、WordPressでログインできなくなると最初はかなり焦ります。ただ、phpMyAdminでwp_usersにユーザーが残っているのであれば、まだ復旧できる可能性は十分あります。
同じ症状が発生したときの備忘録として残しておきます。