見出し画像

WordPressの「次へ、前へ」の仕様制限と、新サイトの作り直しの話

(約 4,100文字の記事です。)

新サイトの実装だが、一周回ってゼロに戻る

さて、あとはnoteの記事をWordPressに移植して本格稼働開始!かと思いきや、そうでもない。そう、一周回って、また振り出しに戻ってきたのである😭

さすがに色んなことを開発した経験上、まぁ、そういうことは割とあるよな、と思っているのであまり精神的なダメージはない。達観している。

何だか一気に書き殴ったらすぐに4千文字を超えちゃった😱またしても長文です……。


WordPressの仕様「前へ、次へ」の制限


これ、next_post_link( '%link', '▶ 次の記事' , true); という、trueを付けるだけで仕様上は「そのカテゴリ内限定で前後に移動出来る」はずなのだが、ここに罠があった。

まず「投稿が複数のカテゴリを持っている場合、どうなるか分からん!という仕様」とのこと。また色々実験した結果、複数の投稿が「共通する親カテゴリ、祖先カテゴリ」に入っていれば、後は時系列順に「次へ、前へ」で遷移するのだ。

(記事自体に割り当てられているカテゴリのチェックON/OFFは無関係。カテゴリそのものに親子関係があって複数記事で共有されたカテゴリであれば、後は日付情報が参照される。)

私の場合は、以下のように、「RetopoFlowの使い方記事」と「BlenderのTips集1, 2」の記事が時系列に沿って「次へ、前へ」で遷移してしまう。というのもBlenderというカテゴリに子カテゴリとして各マガジン名カテゴリを入れているため。

3つのマガジンは共通の親「Blender」カテゴリに属している

これ、投稿自体に「Blender」カテゴリをチェックON/OFFどっちでも現象は変わらず。

要するに共通する親・先祖カテゴリに属する複数の投稿は、親・先祖カテゴリのチェックON/OFFに関わらず、「次へ、前へ」の遷移対象になる

そうなると、せっかく苦労して実装した「次へ、前へ」への軽快なアクセス体験も、突然途切れる。書籍のページをペラペラめくるような快適さがなくなる。ある瞬間突然に「全く別のマガジン記事」に飛ばされてしまうのだ😱興ざめである。


一周回って「仕様の作り直し」

はい、というわけで10日間もかけて壮大な予行演習が今終わった😭そう、全ては予行演習。これまで蓄えた知識も、これからの再建のための材料でしかない。

だが過去にこういう経験を幾度となく繰り返してくると、さすがに強くなるw 次への期待のほうが大きい。

カテゴリ階層化は役に立たない

そういう理由なので、次へ・前へで完全に他のマガジンと切り分けるためには、独立したトップカテゴリ1つのみに記事群を所属させる必要がある。なのでカテゴリ階層化は実質的に使えない。何という縛り😭

そうなると色んな仕様が変わる。だが色々考えた結果、むしろその方が都合がいいことも見えてきた。

複数カテゴリの利用はできない

今までは「有料記事」カテゴリのON/OFFでアクセス制御しようと思っていたがこれもNGだ。「次へ、前へ」利用時に時系列的に近い投稿があって同じ「有料記事」に属している記事があればそちらにジャンプする可能性がある。それは今読んでいるマガジンと全く異なる場合もある。

なのでこれからは単一カテゴリにしかチェックONできない。もう、仕様が崩壊した😭ただしSEO的にはかなりいいことになる。


共通する要素は「タグ」で区切る

例えば今までトップカテゴリとしてZbrush、Blenderがあったが、これ、色んな記事に必ずついて回る情報だ。これをカテゴリで階層化すれば2トップから下に下に階層化されることは必然。

でもこれ、何か息苦しいなと思っていた。ほとんどの記事がこの2トップのいずれかに含まれるわけで。階層がどんどん深くなることは必然

う~ん、使いにくいよね?

そして階層構造が変わると今まで仕込んだ色んなギミックの条件文を書き換える必要が出てくる。「メンテのためのメンテ」が生じる。これはすぐに破綻する。こういう仕組みは全くスマートじゃない💢

タグには階層構造もなく、また1記事に複数のタグ付けもごく普通のことだ。なので色んな記事にZbrushやBlenderのタグが付いても不思議ではないし、両者に関わる記事には両方のタグが付くこともある。

そう、カテゴリを2トップにすれば「両者に属する場合」に対応できないのだ。だがタグならば問題ない。それにもし3トップ、4トップとなると階層構造のカテゴリでは破綻する。組み合わせが膨大になるため、階層構造では対処しきれない。

だがタグだと自由だ。何の仕様変更もない。


カスタムメニューの知恵を活用する

実はここまでの実験で、マガジンのカテゴリを選んだときにマガジンのサブカテゴリをメニューとして表示させることでマガジンの内容を分かりやすく見せるための仕組みを導入した。その際に利用したのが「自作のカスタムメニュー」である。

WordPressでは通常、テーマのテンプレとして「カテゴリー」というウィジェットが付いてくると思う。今回メインで使うのはそれではなくて、自由に自分でカスタムできるオリジナルの手作りメニューなのだ。

このカスタムメニューでは並び順は手動でD&Dで簡単に変更できる
またメニュー項目もカテゴリ、固定ページ、投稿ページ、カスタムHTMLなど割と自由だ。

これを活用すれば、WordPress内のカテゴリは全く階層化させず直列なまっすぐな状態であっても、ユーザーに見えるメニュー自体は階層化構造を保てる。

例えばテストとして、どれもTOPカテゴリの最上位カテゴリだが、カスタムメニュー上ではこのように階層化して表現できる。

ユーザーに見せるためだけの階層化が可能

そして最上位のBlender、これは別に「Blender」というカテゴリを作成しなくてもいいのだ。例えばBlenderタグのタグアーカイブページにジャンプするカスタムHTML項目でもいいのだ。

例えばBlenderをクリックすると以下のようにタグのアーカイブページに飛べばいいわけ。

タグのアーカイブページで更新日の降順に並べば何の問題もない。


全ての問題を解決!

こうなると以下の問題が解決される。

  1. 「前へ、次へ」で別のマガジン記事にジャンプしなくなる

  2. なので他のマガジンと「投稿日順の兼ね合い」を考慮せずに済む

  3. カテゴリは全てトップカテゴリのみでいい(階層化の管理不要)

  4. ユーザーに見せるカスタムメニューの並び順はD&Dでいつでも簡単操作

  5. 同様にカスタムメニューの構成はカテゴリに影響を与えない

  6. つまりカスタムメニューの変更はいつでも何度でも自由😍(カスタムメニューの最上位も簡単に増減できるし、階層構造も状況に応じて自由に拡張・変更できる!)

  7. Zbrush、Blender、サブスタンス3Dペインターなどの複数のメインツールにまたがる記事でも気軽にタグ付けでOK

これが本質的な答えかも知れない。昨日まではRetopoFlowの使い方マガジンの移植テストだけだったので気付かなかったが、今日、BlenderのTips集1, 2を追加して見えた新たな課題。これを克服するための手段を、結果として10日間かけて集めたことになった。そのおかげで「最適な答え」つまり理想的な仕組みの構築と実装可能性を見出すことができた。

10日前ならこの答えにならない。というのも「それをやるためには○○が足りない。どうすればいいか分からない」状態だったからだ。今ならばPHPによるIF文が使える!だからこそ考えの幅を広げることができた。

というわけで10日間かけた盛大な予行演習が今日終わった。明日から再び仕様設計の変更と実装に入る。だが、確実に前の仕様よりもシンプルかつ強力になったと感じる。


仕様にこだわった理由

ここまで仕組みにこだわって仕様を洗練させた理由は、今後も何十本も記事を書いては取捨選択をし、洗練させたり廃版にしたりするわけで。

「今後何十本も記事を書いて管理運用するわけです」

というのも今までの活動でnoteでの複数本のマガジン管理は破綻した。管理の仕組み作りに失敗していた。その過ちを繰り返したくはない。だからこそ、

  1. 執筆者が記事を執筆・修正しやすく

  2. サイト管理者がマガジンの構成を管理・修正しやすく

  3. 記事の成長度合いに応じてサイト全体の構成をいつでも柔軟に変更できること

この3つがとても重要だったのだ。

noteでは1はOKだが2は微妙で、3は不可能だった。

記事も最初は書けば書くほどよかったが、すぐに管理の問題にぶつかる。保守するのか、廃版にするのか。廃版にするとしたら、その後のデータ管理はどうするか。ユーザーへのアクセス管理はどうするか?(消すだけなら誰でもできる。だが非公開にしたとすれば今後どう管理するか?)

また保守するにしても「今までのままで行くのか、他のマガジンと統合して全体的に利便性を向上させるのか?もし統合するならばサイト構成の階層をどう変更すべきか、変更自体は可能か?変更後の動作検証は?」という問題がすぐに出てくる。

そうなると、管理者にとって「ユーザーに見える部分の最適化」が簡単にできる必要がある。フロントエンド側の柔軟性が重要になる。

バックエンドのスパゲッティーはとても危険

バックエンドの苦労はユーザーには分からないし分かる必要もない。だがもし保守の際にフロントエンド側で「マガジンの構成変更で気軽に階層構造に追加で入れ子にした」だけでバックエンド側でたくさんのIF文の修正が必要ならば、あるときにもうスパゲッティーになることは目に見えている。

そしてサイトを拡張すればするほど2のN乗で複雑さが増えていく。そうなると今のようにまた破綻する。それは嫌だ。

だからこそ、シンプルかつ本質的な仕様作りが重要なわけ。ここまでこだわっているわけ。後からの仕様変更は、サイトが大きくなった場合にはとても痛みを伴う。

危険だ。だからこそ「今」なのだ!最初が重要なのもそこ。


というわけでようやく本当の仕様が決まったところで今夜は終了🥂

今回の創作活動は約6時間30分(累積 約3,417時間)
(945回目のnote更新)


読んでくれてありがとう。気長にマイペースに書いてます。この出会いに感謝😊