5.4.1に限らず、2020/04/29にアップデートされた各ブランチで共通だと思う。このアップデートで、各エントリのパーマリンク設定（カスタム構造）において、以下の記述が利用できなくなった。
https://example.com [ /%year%/%monthnum%/%day%/%hour%%minute%%second%/ ]
このブログでは上記の形式でもうずっとやってきていたのだけど、まさかこれが使用できなくなる日が来るとは思っていなかった。対策をしないまま放置すると、年月日が勝手に “/” で区切られてしまって全文が読めなくなってしまう。（正確には年月日単位のアーカイブ扱いになってしまう）
気がついたのが遅れてしまってかなり慌てたのだが、検索したら『wordpress 5.4.1 からの障害について』を発見。内容を読んで一応は納得する。
ただし問題はパーマリンク設定をどうするかということと、前回までの公開エントリ数が810本あったこと。検索エンジン向けに301リダイレクト処理をしないといけないのを短時間でどう処理するか、ということ。考えだしたら座ってるのに立ちくらみがしてくる。
というわけで、一旦頭を冷やして手順を考えた。
- 方針として新規パーマリンク設定は “post-%post_id%” とする。”%post_id%” を利用するのは好きじゃないのだが、手っ取り早くそれなりにするなら、これを使用するしかない。
- 検索エンジン向けの301リダイレクト対策を行う。私はさくらVPSにてnginxを利用してサーバ構築しているので、301リダイレクト用の .conf ファイルを用意してそれをインクルードして利用することにした。
301リダイレクトするにあたりは、総エントリ数が810ある。各エントリの「年月日時分秒」の箇所を「post-%post_id%」に書き換えるのだけど、ちまちま書き出してたらどれほどの時間が掛かるかわかったもんじゃない。ここはプラグインを利用して全エントリの情報を書き出す。参考にしたのは『WordPressで5分もかけずに記事のURL一覧をCSVで取得する方法 | MAIL de AfiRe:LIFE』です。このエントリがなかったら死んでた。
CSVで現在のパーマリンクとそれに対応するIDがわかれば、あとはExcel等のスプレッドシートを利用して記述を整えてから301リダイレクト用ファイルを作成する。
rewrite ^/blog/20200429223027$ /blog/post-6314 permanent; rewrite ^/blog/20200426075509$ /blog/post-6310 permanent; rewrite ^/blog/20200425184904$ /blog/post-6304 permanent; rewrite ^/blog/20200424221752$ /blog/post-6300 permanent; rewrite ^/blog/20200419203107$ /blog/post-6296 permanent; （以下略）
そうしてnginxをリスタート。Googleにアクセスしてこのサイトの記事を適当に検索し、結果をクリックしてリダイレクトされていることを確認したら終了。問題なければ使用したプラグインは停止（もしくは削除でもいい）。
対応としてこれがベストかと聞かれたらわからないのだけど、まぁ速攻で作業を終えることができたのでヨシ。ただ、ずっと使用していた形式が拒絶されてしまったのは少しさびしい気もする。
自前でサーバ構築して運営してる人はまだ幸運な方で、そうじゃない人たちはかなり大変かと思われる。それにしてもまいったねぇ、こりゃ。