使っていたプラグインが公開停止になったとき、すぐに乗り換えたでしょうか。
わたしはたぶん、しばらく放置します。動いているうちは困らないからです。困るのは、本体の更新で急に壊れたときか、乗り換えようとして固定ページを開いたときでした。
HTMLサイトマップの定番だった PS Auto Sitemap が止まったのが2022年です。4年経っていますが、いま「PS Auto Sitemap 代わり」で検索すると、出てくる記事はどれも「使えなくなりました」から始まって、代替の候補をいくつか並べて終わっています。定番が決まっていない。
機能の問題ではないと思いました。似たことができるプラグインは、いくつもあります。定着しない理由は、たぶん乗り換えのコストのほうです。
それで作りました。設計の中心に置いたのは、そのコストを消すことでした。以下は、決めた5つと、公開までの記録です。
移行のコストを、どこまで消せるか
乗り換えでいちばん面倒なのは、固定ページの中身を書き直す作業です。
PS Auto Sitemap を使っていたページには [!-- SITEMAP CONTENT REPLACE POINT --] のようなHTMLコメントが入っています。正確には角括弧ではなく不等号ですが、ここでは表示のために置き換えています。WP Sitemap Page なら [wp_sitemap_page] というショートコードが入っています。乗り換えるには、これを全部消して、新しい記法に書き換えることになる。ページが1枚なら何ということもありませんが、それでも「あとでやろう」になります。
なので、両方の記法をこちら側で認識するようにしました。ページは開かなくていい。有効化して、設定で切り替えるだけで、同じページが表示され続けます。
ただ、引き取ると決めた時点で、判断が3つ増えました。
ひとつ、既定はオフにする。黙って他人の記法に反応するのは、驚かせます。新しいプラグインを入れたら、書いた覚えのないショートコードが急に描画を始める。動くぶんには問題なく見えますが、何が起きているのか分かりません。設定画面で自分でオンにしてもらう形にしました。
それから、相手が生きている間はショートコードを奪わない。同名で登録すると後勝ちになるので、WP Sitemap Page が有効なあいだは名乗り出ないようにしています。両方入っている状態でどちらが描画しているか分からないのは、いちばん困る状態です。
最後に、旧設定は読むだけにする。PS Auto Sitemap の設定をボタン1つで取り込めますが、相手のオプションには一切書き込みません。うまくいかなかったときに、旧プラグインを有効に戻せば元のままだからです。移行は片道になるべきではないと思っています。
実装の細かいところは、Qiita に分けて書きました。
黙って減らさない
移行とは関係なく決めたことも、いくつかあります。
一覧を出す機能なので、件数の上限が要ります。記事が数千件あるサイトで全部取りに行くと、メモリが足りなくなる。上限そのものは迷いませんでした。
迷ったのは、上限に当たったときにどうするかです。黙って切ると、見た目はきれいです。一覧が並んでいて、途中で切れているようには見えない。読む人は、これで全部だと思います。
一覧というのは、全部載っている前提で読まれます。足りないことに気づく手がかりが、一覧の中にありません。2000件で切って、実際に2400件あったとして、残り400件はどこにも出てこない。持ち主は自分のサイトを2000件だと思ったまま運用します。
なので、切ったときは出力にそう書くようにしました。表示は少し不格好になります。訪問者にも見えます。それでも、遅い一覧より、静かに不完全な一覧のほうが怖いと判断しました。
この判断そのものについては、Zenn に書いています。まだ迷っている部分も含めて。
他人の既定値を、利用者の指定より優先させない
同じ形の問題が、別のところにもありました。
SEOプラグインで noindex に指定された記事は、サイトマップからも外したいはずです。Yoast SEO、Rank Math、SEO SIMPLE PACK、SEOPress、The SEO Framework、All in One SEO、それと Cocoon テーマ。この7つは、設定なしで読めるようにしました。
ただ、読まないことにしたものがあります。投稿タイプ全体やアーカイブ全体にかかっている既定の設定です。
たとえば Yoast SEO は、日付アーカイブを初期状態で noindex にします。これを読むと、利用者が「年月別アーカイブを載せる」と選んだのに、一覧が空になる。設定はオンのままで、何も出ない。なぜ空なのかを調べるには、別のプラグインの初期設定を疑うところから始めることになります。
個別に指定したものは読む。全体にかかっている既定は読まない。この線で分けました。上限の話と、構造は同じです。減っているのに、減った理由がどこにも出ていない状態を作らない。
出せないものは、何が要求しても出さない
カスタム投稿タイプにも対応していますが、ひとつだけ例外を作りました。
サイトの表側で表示できない設定になっている投稿タイプは、ショートコードで名指ししても一覧に出しません。出したところで、クリックすると404になるからです。
ここは、利用者の指定より仕様を優先させています。前の節と逆に見えますが、基準は同じで、開いても何もないリンクを並べるのは、減らすより悪いと判断しました。
日本語のサイトで効くところ
並び順に、カスタムフィールドを使えるようにしてあります。
日本語のタイトルをタイトル順で並べると、文字コード順になって、五十音順にはなりません。読みがなを入れたカスタムフィールドを用意して、それで並べると、意図した順番になります。日本語のサイトで一覧を作るとき、ここは毎回引っかかるところでした。
余談ですが、WPML と Polylang は設定なしで動きます。どちらも投稿と語句のクエリを現在の言語に絞るので、こちらでそのフィルタを切らないようにしただけです。描画のキャッシュは言語ごとに分けてあるので、別の言語のものが出ることはありません。
公開までに、指摘を1つもらった
WordPress.org での公開とは別に、日本語の翻訳を自分で管理できるようにするため、Polyglots に PTE の申請を出しました。
すぐに指摘が返ってきました。日本語スタイルガイドの 1-2、半角の疑問符の前にスペースを入れる、という規則を守れていないというものです。
直したのは10文字列でした。プラグイン本体に2つ、readme に8つ。
ここで、直して再提出するだけにしなかったのは、同じ間違いが他のプラグインにもあるかもしれないと思ったからです。カタログ全体を見直しました。結果としては他に同じパターンはなかったのですが、確認したことで、これは自分のワークフローの穴だと分かりました。
翻訳を書くとき、スタイルガイドを毎回開いてはいません。覚えているつもりで書いて、覚え違いに気づく機会がない。なので、チェックを1つ手順に足しました。指摘されなければ、次も同じところで引っかかっていたはずです。
翻訳と PTE のまわりは、前にまとめてあります。
申請から3日で、全文字列が承認されて PTE に設定されました。
入れてみる
WordPress の管理画面から「Rapls Sitemap」で検索するか、こちらから入手できます。無料で、有料版はありません。
設定項目の詳しい説明と、開発者向けのフィルタの一覧は、製品ページにまとめてあります。
使い方の手順は、Gift by Gifted のほうに書きました。乗り換えの流れを追いたい方は、そちらが読みやすいと思います。
並べてみると、決めたことの多くは「何を出すか」ではなく「何を黙ってやらないか」でした。勝手に記法を引き取らない、勝手に設定を書き換えない、黙って件数を減らさない、他人の既定で利用者の指定を上書きしない。
作る側にいると、機能を足すほうが手応えがあります。ただ、あとで人を困らせるのは、たいてい足りない側ではなく、黙ってやってしまった側でした。
いま使っているプラグインが明日止まったとして、乗り換え先に何を期待するでしょうか。作りながら、そればかり考えていました。
コメント