【大失敗‼】サーバー上のwp-config.phpを上書きして、データベース接続エラーが発生して魔の真っ白画面になった話(泣)

こんにちは!今日はWordPressサイト構築中に「うっかり」やらかしてしまった大失敗について、今後同じようなミスをしないように反省を込めて書いていきます。WordPress構築中の「うっかり」は、WEB制作者なら誰でも一度は経験することだと思いますが、場合によってはかなり面倒なトラブルに発展することもあります。僕と同じようなミスをしないように、ぜひこの記事を読んで参考にしてもらえたら嬉しいです。

何が起きたのか?

まず、何が起きたのかというと、昨日LOCAL環境で構築していたWordPressをテスト環境のサーバーに移行し、最終的なサイトのチェックやコンタクトフォームの確認などを行って、ほぼ完了しました。そこで、クライアントに確認の連絡をしようかなと思ったときに、ふと「あっ、そういえばWordPressのデバッグモードを解除しておかないと…」と思い、「こんなところに気が付くなんて、自分も成長したな…フッ」なんて軽い気持ちで、まずLOCAL環境の「wp-config.php」でデバッグモードを解除した後、FTPでその「wp-config.php」をテスト環境にアップロードし、テストサーバーのファイルを上書きしてしまいました。

その結果、テスト環境のデータベース接続情報がLOCAL環境のものに置き換わってしまい、「WordPressデータベース接続エラー」が表示され、管理画面に入れなくなり、サイトも非表示になるトラブルが発生しました。しかも、移行前にテスト環境の「wp-config.php」のバックアップを取っていなかったので(もう、バカ、バカ、バカ!!)、その後3時間くらい復旧のために格闘することになりました…泣

簡単そうに見えて、意外と復旧が大変だった!!

データベース接続エラーが発生してサイトが非表示になってしまったとき、これまではWordPressのエラーが出ると本当に焦っていたのですが、今回は「はいはい、分かりましたよ。まぁでも…きっとwp-config.phpを上書きしたせいだろう、これを直せば簡単に解決するはず!らくしょー」と軽く考えていました。しかし、実際は意外と面倒なことになっていることに、後から気付くことになりました。

最悪!wp-config.phpのバックアップを取っていなかった。

今回は、エラーが発生した原因が「wp-config.php」のデータベース接続情報が原因だとすぐに分かっていたので、wp-config単体で元に戻せばいいと思ったのですが、テストサーバーの「wp-config.php」のバックアップを取っていなかったため、自力でデータベース接続情報を確認する必要が出てしまいました。ちなみにデータベース接続情報とは以下の情報のことです。

  1. データベース名
  2. データベースユーザー名
  3. データベースパスワード
  4. データベースホスト名

wp-config.phpにはこれら4つの情報が記載されており、これをWordPressに紐づいているデータベース(MySQL)の情報と一致させる必要があります。

ちなみに、今回LOCALのwp-config上書きしてしまったので、以下のようにデータベース接続情報がLocalに上書きされてしまっていました。(阿保ですねー)

データベース接続情報はサーバーパネルから見れない…

バックアップを取っていなかったため、まずはサーバーパネルからデータベース接続情報を調査しました。私はエックスサーバーを使っているので、サーバーパネルから「データベース接続情報」を調べようとしましたが、「データベース名」と「データベースユーザー名」しか確認できず、ホスト名とパスワードは表示されませんでした。また、サーバーの自動バックアップ設定もしていなかった(大馬鹿)ので、他の方法でデータベース接続情報を探しました。

All-in-one-migrationのエクスポートデータから取得できるか?

ここで、そういえばサイト移行前に「All-in-one-migration」でテストサーバーのデータをバックアップしていたことを思い出し、そのデータの中に「wp-config」があることを期待して、圧縮ファイルを解凍してみました。

※ちなみに「All-in-one-migration」でエクスポートしたデータは特殊な「WPRESSファイル」という拡張子だったので、以下のサイトで解凍しました。

WPRESSファイルの解凍サイト

ファイルをアップロードするだけで解凍できます。バックアップデータの一覧が表示されましたが、「All-in-one-migration」にはwp-config.phpが含まれていないことが判明しました…マジか。

他のWordPressの「wp-config.php」を確認

続いてサーバーパネルや、同じドメインのサブディレクトリにインストールしている他のWordPressの「wp-config.php」を確認しました。そこで気づいたのは、同じドメインのサブディレクトリ上にあるWordPressであれば、データベース接続情報の中の「データベースホスト名」が同じ値であることです。あとはパスワードについても、サーバーパネルのMySQL設定からパスワードを再設定し、ユーザーパスワードも新たに取得すればよいということに気が付き、無事に新しいパスワードを設定できました。

これでデータベース接続に必要な情報がすべて揃いました。

いざ復旧へ!

まずはテスト環境の「wp-config.php(現状はLOCAL環境の接続情報)」をダウンロードして、ビジュアルコードエディタ上で、取得した情報を正しく記入しました。入力が完了したら再度テスト環境にアップロードし、サイトを更新したら、無事に表示されました!よかったー泣

今回のミスの反省

今回のミスで特に反省するべき点は以下の4つです。

  1. 「wp-config.php」とWordPressの仕組みをちゃんと理解していなかった
    「wp-config.php」の役割やWordPressの仕組みについての理解が不足していたことが原因でした。特に「wp-config.php」はWordPressの動作を制御する大切なファイルなので、バックアップを取らずに上書きするなど、軽率な行動を二度としないようにします。
  2. サイトのバックアップはサーバー側で自動取得する
    エックスサーバーにはサイトのバックアップを自動で取得するサービスがあるにも関わらず、それを利用していなかったため、余計な手間が発生しました。今後は必ず利用します。
  3. 調子に乗ると事故は起きる
    サーバーやFTPの操作に慣れてきて、少し調子に乗っていました。サイト移行前にバックアップを取らなかったり、軽率に操作してしまったことが反省点です。今回はテスト環境だったから復旧できましたが、本番環境であれば大変なことになっていました。
  4. クライアント確認前にデバッグモードを解除する必要があったのか?
    そもそも今回の事故のきっかけは「デバッグモードの解除」でしたが、テスト環境でクライアント確認前に解除する必要はありませんでした。今後はクライアント確認後に解除するようにします。

まとめ

というわけで、今回は何とか復旧できたのですが、今回のミスを教訓に、サーバー移行やWordPressのコアファイルを触る際は、必ず「サーバーの自動バックアップ取得」+「個別ファイルのバックアップ作成」を行い、慎重に作業を進めるようにします。

もし何かの参考になったら、是非SNSやブログでリツイートしていただけると嬉しいです😊

ではまた!!

この記事を書いた人