カスタム投稿のパーマリンク(スラッグ)は95%「Custom Post Type Permalinks」で可能だが…

ごきげんよう。

VICI様のマガジンは、とある技術者による実験のサイトなので記事内容が雑で適当なのは許せ。また、記事の内容は常に自分本位であり、自分が興味を持ったことが中心である。つまり、他人の質問は一切受けぬ!

ということであるが、この題材は誰しもが最初はもがき苦しむところだろう。

「Custom Post Type Permalinks」について

このプラグインは読んで字のごとく、カスタム投稿のパーマリンクを指定できるプラグインである。WordPressをブログから1歩2歩進めた先に必ず遭遇するのがこのカスタム投稿であり、そのパーマリンクも然りだ。特にSEOまでこだわるプロの諸君は、おそらく私同様この難題に苦しんだ経験があるのではなかろうか。

そもそも、SEO的な話をすると、理想的なサイトマップは必ずしも実現可能とは限らないという前提がある。第一に技術者に突きつけられる課題とは、常に実現可能かどうかの”調査”だ。事実、最も大変なのは”調査”であり、実現可能かどうかの判断を出すまでが仕事の8割りとも言えるのではないかと思う。いや、言い過ぎか。

とにかく、カスタム投稿のパーマリンクはそのレベルの問題であり、同時に一瞬で解決した、と”思わせてくれる”プラグインが「Custom Post Type Permalinks」だ。

なぜ思わせてくれたかというと、実は経験から言ってこのプラグインは穴だらけである。といっても、普段使いでまずその穴にははまらない。だからコレは良い!と思うがそれこそが穴だ。具体的には以下の様なことをすると穴に落ちる。

  1. 階層持ちのカスタムタクソノミーをパーマリンクに指定する
  2. カスタム投稿記事内にページングを作る
  3. 複数のタームで検索できるようにする
  4. 設定したrewrite設定を上書きされる

などである。つまり、シンプルにカスタム投稿だけを使い、記事にページングも使わずパーマリンクを例えば%post_id%にしたい、等であれば全く問題はない。だがそれ以上を求めるなら自力での設定がオススメだ。

階層持ちのカスタムタクソノミーをパーマリンクに指定する

これは要するにこのプラグインを有効化してパーマリンク設定画面にも記述がある、%custom_tax%/%post_id%などと指定した場合だ。このエラーは症状が軽いので何とかなるが、そもそも論理矛盾があるのでオススメできない。それは記事に必ずしもタクソノミータームが指定されているとは限らないからだ。

もちろん、”運用の方針で必ず1つタームを指定する”とルール化するのは勝手だが、そんなヒューマンエラーの予感しかしない発言はエンジニアには聞こえない。また、そうしたとしても2つ目の問題として、2階層異常のタームを指定した場合、%custom_tax%/%post_id%と%custom_tax%/%custom_tax%/%post_id%の2つ異常のURLが生成されることだ。

一見、どちらかにリダイレクトなどを噛ませればゴリ押しで解決できそうだが、1つ目の課題は解決されていないのでモヤモヤは残ったままだ。

まあカテゴリーの「未分類」みたいに、other系のタームを無理やり指定するようにすれば良いかもしれないが、SEOのカテゴリー分けに「未分類」はよろしくはないだろう。

カスタム投稿記事内にページングを作る

これは唯一個人的な実装経験がないが、起こるらしい。また、よく見かける。最新バージョンでは解決できているのかもしれないが、1年ほど前はできなかった。とはいえ確かなことは言えないので言及はしない。

複数のタームで検索できるようにする

カスタムタクソノミーはパラメーター検索できる様にした場合、配列形式で指定すればデフォルトでかなりのことができることは以外に知られていない。たとえば?taxonomy[]=term1&taxonomy[]=term2は有効で、たしかANDで検索される(ORかもしれん)。

しかし、この指定で結果が0だった場合、プラグイン側で警告文が出る。まあ、出力しなければいい話だが、なんとなくムカツク。

設定したrewrite設定を上書きされる

基本的にこれが一番ムカツク。というのも

/%custom_post_type%/%post_id%/で記事ページ、/%custom_post_type%/%custom_tax%/%custom_tax_term%でタームページ、ただし一般の投稿は/blog/%postname%/などで指定した場合、Custom Post Type Permalinks」ではどう頑張っても指定できない。

なぜかというと、たぶん/blog/%postname%/この可能性が仕様上にないからだろう。2年くらい前はこの方法で詰まった時、カスタム投稿でblogを作り、デフォの投稿は無効にしていた。それはそれで問題ないが、そんな無駄なことはしたくないため、久々にCustom Post Type Permalinks」を使おうと思ったが今回はこれでやめることにした。

正直、優秀なプラグインではあるが、そもそも仕様に矛盾があるのと、他にも穴がある可能性を考えたら怖くて使えない。WordPressのリライト機能を手書きする方がはるかに無難だ。

総括

Custom Post Type Permalinks」は優秀であり、95%の人はこれで事足りるであろう。だが、仕様に矛盾がありカスタムしまくったWordPressでは完全に動作はしない。残り5%の人は、自分でリライトしよう。

そもそも、WordPressは使い方に幅がありすぎる。それは良い反面、そうなるともうプラグインでは役不足。何でもプラグインで解決できると思ったら大間違いなのだ。プラグインはそれこそ、大多数の95%が満足できればそれは最高傑作であり、少数派はそれに不満をいう資格はない。そんな例外的な使い方するなら自分で頑張れという話だ。

というわけで、同じ壁で躓いた人がもしいて、自分のカスタマイズが少数派であると感じたら、潔くプラグインは捨てよう。そして、それがそもそも実現可能かどうかの調査からリスタートするめんどくささも重要かもしれない。

WordPressで”フツー”のブログを超爆速表示にするワザ

ごきげんよう。

VICI様のマガジンは、とある技術者による実験のサイトなので記事内容が雑で適当なのは許せ。

今日はこのサイトを公開した理由が、とある実験を兼ねているためというのと、適当とはいえある程度実践を考えた模擬運用をする必要があったからだ。

そんなわけで、このサイトはWordPressを使っていながら、超爆速表示を実現しているわけだが(今のところ異常なしで)、何もサーバーのスペックが神なわけでもなければ、特に技術力がなければできないようなトリックじみたことをやっているわけではない。

今回は、テストも兼ねどういう仕組みになっているかを説明する。

Simply Static & AMP

使ったのは2つのプラグインだ。

1つは「Simply Static」というWordPressのページを静的HTMLに置換してアウトプットするというプラグイン。

2つ目は「AMP」。こちらはスマートフォン向けにAMP対応したページを生成するというプラグインだ。

静的HTMLにすることによるメリット

静的HTMLにするということは、いちいちWordPressの膨大なPHPプログラムを実行する必要がない。昨今はレンタルサーバーにも速いものがあるが、それでも静的HTMLの表示速度には絶対に敵わないのは自明である。

この表示速度が爆速になることが最大のメリットである。そしてもう1つあるのがセキュリティ対策だ。

WordPressは常に外部からの攻撃者に狙われる格好の的である。その理由はいろいろあるが、とにかくこじ開けようと思えば開くドアがたくさんあるので、本域のプログラマーからは懸念の声が常に上がっていた。

解決方法も実にいっぱいあるが、もっとも根本的な解決策は、静的HTMLにしてしまうということだろう。プログラムが走っていないのではハッキングはできない。

通常のブログであれば、いちいちプログラムが走るデメリットより、サクっと静的HTMLを出力するメリットの方が多いと私は判断できた。

静的HTMLにすることによるデメリット

あえてサイドバーに検索窓を残しておいたのだが、使えば分かる通り、検索機能は動かない。というより、動的ページは生成できないのは欠点である。

大規模な情報データベースを作るのには適さない。また、コメント欄も使うことができない。こちらは、別の機能で補完できなくはないが、純正のコメント欄は動かないのだ。

最後に1つ。静的HTMLを出力する際、書き出しにはやはり若干時間がかかる。また、スラッグに日本語URLが含まれると不具合を起こしてしまうが、これはプロなら問題ないだろう。

とにかく、最もシンプルなブログ形態から進歩した形を実現する場合は障壁になりうるのである。つまり、最もシンプルなブログとして運営する場合のみ、これは推奨できる。

AMP対応について

私は前述した内容に概ねメリットが多いと判断し、またそういった限定的な機能でもって運用するサイトを今後構築するケースは多くあるだろうと考えた。

そのため、最もシンプルなブログを再軽量および爆速表示で安全に作成するWordPressの設定を考えているわけだ。そこで、爆速表示といえば「AMP」になる。

「AMP」とは何か?それはぐぐってくれ。

ここでの問題は「AMP」に「Simply Static」が対応できるか?という1点だけだ。結論からいうと、問題なくできた。

総括

このやり方がアリかどうかは、このサイトを今後フォローすることでより明白になるだろう。

少なくとも、現状の数ページの状態では、全く問題なく快適な運用が実現できていると思う。

興味のある方もいるだろうから、近々にでも導入方法を具体的に記事にしたいと思うところだ。