ずっと困っていたが、とりあえずは動くものだからと放置していた件。これがひょんなことから解決に至ったので、その備忘録。
2019年（！）に『WordPressを4.9.9から5.2.2へのアップデートとログインページおよびカスタマイズ画面の不具合が解決しない件 | 脳無しの呟き《土鍋と麦酒と炬燵猫》』というエントリを書いているのだけど、状況を改めて書き出すと以下。
- 管理画面のログインページにて、CSSが効いていない（デザインが崩れる）。ログインはできる。
- ログイン後、エントリの登録や画像のアップロード、そしてエントリ公開もできる。が、JavaScriptが効かないため、部分的に使用できないメニューが複数箇所存在する。
- 特に致命的だったのは、「外観」＞「カスタマイズ」のメニュー。こちらが死んでいるので、サイトの細かいカスタマイズができないでいた。あと、エントリ登録時に設定する「タグ」の指定ができなかったこと。今回解決するまでは、タグ用のプラグインをインストールすることで対応していた。
なかなか解決に至らなかったのは、同じような事例を見つけてもそこで記載される対処方法がすべて空振りに終わったところ（むしろその対応で悪化する）。そしてバージョンを4.xに戻すと、何事もなかったかのように解決してしまうところ。
まったく同じ事例を探してはいたが、結局は見つからずに1年以上が過ぎた。ほとんどもう諦めの境地で、WordPressの使用をやめるかどうするか、くらいまで考えたこともあった。
そんな状態からの復旧の経緯だけども、本日台所にて洗い物をしていたら、急に「nginxの設定ファイルがダメなんじゃないか？」などと脳内に思い浮かび。何も考えていなかったのだけど、急にそんなことが脳内に広がったものだから、そこをちょっと見直してみることに。
nginxの設定ファイル、ざっと流して読んでみたがその時点では問題ないと思っていた。だから、実際に起きているエラー状況をFirefoxの開発ツールから確認。そうすると、以下の状況に判明した。
- wp-admin/jsおよびwp-admin/css以下のファイルがすべて403エラーとなっている。
サーバへアクセスして各ファイルの権限＆パーミッション等を確認するも、それは問題なし。ただ、各ファイルに対して直接アクセスしても弾かれる。ファイルまでのパスに間違いはない。でも、PHPファイルは読めている（だから管理画面にはログイン＆一応操作できる）。
「なんじゃこりゃ、わからん」
というわけで、状況を冷静に考える。「アクセスできないファイルはwp-admin以下の一部である」「そこを管理してるのはどこじゃ」となって、行き着いたのが、nginxの設定ファイル内に記述した「特定IPアドレスのみ管理画面へアクセスできるように制限した」箇所。最初は以下のような記述にしていた。
location ~ ^/blog/(wp-login\.php$|xmlrpc\.php$|wp-admin/((?!admin-ajax\.php).)*$) {
# satisfy any;
allow ｛私の固定IPアドレス｝;
allow ｛サーバのIPアドレス｝;
allow 127.0.0.1;
# auth_basic "｛ログイン名｝";
# auth_basic_user_file ｛.htpasswdまでのパス｝;
deny all;
include fastcgi_params;
fastcgi_keep_conn on;
｛以下fastcgi用の記述｝
fastcgi_pass unix:/var/run/php-fpm.sock;
}
#でコメントアウトしている箇所は、外部からアクセスしたいときにだけ有効にするBasic認証用のもの（sshでログインして#を外して再起動するとBasic認証でもログインできる）。でまぁ、これでずっと動いていた。WordPress 4.xまでは。ちなみに設定ファイルのチェックコマンドでもエラーは出ないし、この箇所はまったくのスルーだったのだなぁ。
が、よくよく考えると、これはおかしいということに気がついた。たまたま他の人のサイトでの設定ファイルの書き方を見て違いがわかったのである。
「fastcgiの箇所、ダメじゃん！」
fastcgiに関する記述はPHPファイルに対する設定なので、他のJSファイルやCSSファイルには関係ない設定で、どうもこれが悪さをしてたようだ。だから以下のようにした。
location ~ ^/blog/(wp-login\.php$|xmlrpc\.php$|wp-admin/((?!admin-ajax\.php).)*$) {
# satisfy any;
allow ｛私の固定IPアドレス｝;
allow ｛サーバのIPアドレス｝;
allow 127.0.0.1;
# auth_basic "｛ログイン名｝";
# auth_basic_user_file ｛.htpasswdまでのパス｝;
deny all;
location ~ \.php$ {
include fastcgi_params;
fastcgi_keep_conn on;
｛以下fastcgi用の記述｝
fastcgi_pass unix:/var/run/php-fpm.sock;
}
}
赤字部分で囲うことで、制限をかけるPHPファイルに対してだけfastcgiの設定が有効になるように明示した。これで設定ファルの修正は終わり、nginxを再起動して管理画面にアクセス。
「うお、ログイン画面がまともになった！」「カスタマイズ画面が動く！」「JavaScript利用のメニューも動く！」
というわけで、長かった旅は終わりを告げました。ずっとWordPress側の問題だと決めつけて、私はさまよっていたらしい。そりゃぁいつまで経っても解決しないし、他に同じような事例でやらかしてる人なんて（居たとしても）まぁそうそう見つかるわけがない。
ただ、1つだけ言い訳を書いておくと、最初の設定ファイルの記述って参考にしたサイトがあるんですよね。要するにそこが間違ってわけで！ ああああ。ちゃんと勉強してない私が悪いのだけど、解決できたからOKということにしておきたい。しておこう。する。
それにしても、設定ファイルにたった2行追加するだけで解決するとわ。やはり、古いバージョンだとうかつにも問題なく動いてしまっていたことが、気付くのに時間の掛かった原因だなぁ。
「プログラムは悪くない。間違ったことを書くとちゃんと間違ったように動く」とは自身がよく云う言葉なのだけど、思いっきり自身に降り掛かった事例であった。ともかくは、やっと肩の荷が降りた気がする。