最近はブログを全然更新していないのに、ドメイン名だけ頻繁に変えている有様で我ながら阿呆だなと思います。
サイトの移転は結構結構面倒な作業なので、今度こそ、本当にこれで最後にしようと思います。(決意)
そんなこんなで2013年から始めたこのブログで4回目?となるサイト移転の作業をした今日、まさかの自分のブログにログインできなくなってしまったお話です。
Contents
移転後ログインできなくなる
1年に1度以上の頻度でサイト移転していて、記事にもサイト移転の手順をメモってあるので、それを自分で読み返しながら素早く済ませるぞと思い、移転作業を始めるも泥沼にはまりました。
簡単に経緯をまとめると
- 新ドメインを新しいフォルダに関連付けてDNSに登録する
- 旧サイトのディレクトリを新ドメイン用にリネームする
- 空ディレクトリを旧ディレクトリ名で新規作成する
- WordPressのサイドアドレスを新ドメインに変更する
- 旧ディレクトリに301リダイレクト処理を記述した.htaccessを置く
- サイトにデバッグによるエラー文字列が表示されているためwp-config.phpを書き換え<=沼の原因
- メディアのリンクアドレスを変更するために移転先ブログにログインする<=沼の結果
前回のサイト移転時から有効にしていたWordPressのデバッグモードの機能で、サイトのトップに「WP Super Cache」のエラーメッセージが複数表示されていました。
キャッシュ系はいろいろと不具合も起こすことで有名なので、面倒になる前に早めに治そうとFFFTPでFTPにアクセスし、メモ帳でwp-config.php内のパスを書き換えたことが今回の事件の原因となりました。
「WP Super Cache」のパスを書き換えてエラーメッセージが消えたのを確認して、新サイトにログインしようとすると「エラー: 予期しない出力により Cookies がブロックされました」というメッセージが表示され、ブログの管理画面に入れません。
パスワード管理ソフトを使っているので違うはずもないんですが、とりあえずパスワードの再設定をしようとしますが、再設定のリンクに飛ぶと画面が真っ白な状態から進みません。
これは慣習的なログインURLを変更できたりするセキュリティ系「SiteGuard WP Plugin」か、真っ白い画面で有名な「WP Super Cache」の影響かもしれないと勘違いしてしまいます…
様々な対処
SiteGuard WPの対処
まず、ログインURLの変更やログイン時の画像認証機能を追加できる「SiteGuard WP」を手動で削除してみることにしました。
wp-content直下のSiteGuardというフォルダをFTP上で削除して、.htaccessに追記されているSiteGuardに関する一連の記述を削除しました。
これで自分で設定したログインURLから通常のwp-login.phpでログインできるようになりましたが、一向にログインもできなければパスワードの再設定もできません。
WP Super Cacheの確認
問題を起こすならキャッシュ系プラグインの「WP Super Cache」だろうと高をくくっていましたが、知識もないのにこのプラグインを触るのはまずい。
出来る限り手戻りが聞くよう慎重できることを確認しました。
wp-content直下のpluginsフォルダの名前を変更して変化はあるか、サイト移転時にこのプラグインでログインできなくなった人はいないか、真っ白な画面になった人はいないか、触って何か起きたら対処できないのはわかっているのでとにかく調べました。
いろいろ調べてみると、キャッシュ系プラグインで画面が上手く表示されない例はあっても、どうも管理画面や一般のページが真っ白になる事例がおおくて、ログインできないという情報は見つかりませんでした。
ログインできない場合の対象を調べる
どうも「WP Super Cache 真っ白」というようなキーワードではなく、ログインに問題があることが重要な気が始めます。
それで[WordPress ログイン できない」というようなワードで調べてみると、ブラウザのCookieやWordPressのサイトアドレスの設定が原因という情報が出てくる。
複数のブラウザでも試しているし、サイトアドレスの設定は間違えるはずもない。
そこで1つ調べ忘れていたエラーメッセージがあったことを思い出します。
Cookieがブロックされました
ログイン画面に表示されていた「エラー: 予期しない出力により Cookies がブロックされました」というメッセージ。
何度もログインに失敗したせいで表示されたエラーだと思い気にしていませんでしたが、これから対象が見つかるかもと思い検索します。
するとありがたいことにそれらしい情報がいくつも出ます。
wp-config.phpで不正な文字が含まれているのが原因かもしれないとのこと。
パスを書き換えた程度なのでそこまでのへまはしてないはずと思いつつ確認してみるも見た感じはない。
すると「ファイルのエンコードタイプによっても問題が起きる場合がある」という情報を発見。
でも新規作成したわけでもなく、既存のファイルを上書きしているだけなのでこれも問題ないのではと思いつつ、Emacsで開いてBOMの有無を調べてみると編集前のwp-config.phpにはBOMが無いのに対し、パスを書き換えたwp-config.phpにはBOM付きで保存されていました。
「エェ!」という感じです。
原因は文字コードのBOM
調べてみるとWindowsのメモ帳はUTF-8で保存すると必ずBOM有りのUTF-8として保存するらしいですね。
上書き保存は既存の文字コードに従って保存されるような感覚がありましたが、そういうわけではないようです。
BOMは様々なプログラムの不具合を引き起こすということで悪名高いことは聞いていましたが、こういう形で不具合を引き起こすんですね。
今更ですがBOMの悪名高さを体験させられた1日でした。