Lycolog

adiary置き換え計画始動から連なる、Lyndbaum v4.42アップデートの続き。

先週はやることが減ったような気がしていたが、いろいろ思い出したので特大アップデートとなった。特大過ぎたため、後方互換性をまたもや切り捨てておりv4.41からしかアップデートできなくなっている。

実際、GitHubのPRはクソ長いし、GitHubのリリースノートも無限に長い。そしてこの記事もLyndbaum系では過去一長いと思われる。

機能追加

ブログの基本設定に「検索エンジンに掲載しない」（noindex）を追加

ローンチ前のサイトや、その手の創作サイトなどで検索除けをしたいなどのケースを考えnoindex, nofollowを公開ページのヘッダに一律で付与する設定を追加した。この状態でもRSSは出すし、pingやIndexNowも設定すれば飛ばせる。

システム管理に「ディレクトリ使用量」のタブを追加

今のサイトがどれくらい容量を食っているかが分かる画面を追加し、ユーザーが書き込む主なディレクトリの容量とファイルサイズを出すようにした。

メディア管理で動画を動画以外と区別できるようにアイコンを追加

右下に小さな再生アイコンを表示することで、動画であることが分かるようにした。静止画やテキストファイル、PDFに対して個別にアイコンをつけてると大変なので動画だけ対応した。

lyndbaumテーマに2カラム版を追加した

3カラム版しかないので2カラム版を作った。これはLyndbaumそのもののマニュアルサイトを作るのに必要だったため作成した。

そのうち色変更対応も追加していきたいが、今回はやることが多すぎて保留とした。

機能変更

JSをminifyするようにした

Lyndbaumで利用しているJSはadiaryからの引継ぎだが、基本的にminifyされていなかったのでするようにした。

添付ファイルのフォルダをpub/attachments/からpub/attach/にした

attachmentsって長くね？外部サイトとかのURLの長さ制限に引っかかりやすいよなぁ…というか引っかかったので少し縮めた。PukiWikiの添付ファイルプラグインと同じ名前。

タグとページの設定を独立ページにした

元々はネストされた設定だったが単独の設定ページとして引き出した。

adiaryの設定画面は中々カオスなので分かりやすく整備していこう計画の一環。

ツリー操作系のUIでスマホでリネーム操作を行いやすくした

これまでツリー操作系のUIでツリーにぶら下がるノードの名前を変えようとするのは理論上ダブルタップでできたのだが、ほとんど不可能だった。

そこで、それをまともにできるように改修した。

メディア管理のDeleteキーで、フォーカスのないフォルダを消そうとしないようにし、フォーカスがあるときだけ消せるようにした

Deleteキーを何もないところで押したときにフォルダを消そうとしていたので、フォーカスがフォルダにあたっていない限り発火しないようにした。フォーカスがあるときには消えてほしいので、フォーカスが当たっているときだけ機能するようにした。

この挙動は本家adiaryにもあったと思う。

メディア管理で、フォルダをドラッグ＆ドロップするとツリーが閉じるのを閉じないようにした

D&Dでツリーが閉じるのがあまりにも不便だったので閉じないようにした。

この挙動は本家adiaryにもあったと思う。

但しフォルダをD&Dしても記事に埋めているファイルパスは変わらないため、この機能は基本的に使わない機能である。個人的にはフォルダを変なところに作ったので移動したいとか、そういうケースで使う避難ハッチ機能として位置付けている。

フォルダ移動などのパス変更で全記事を書き直したり、その確認を出すと小規模な変更でも大規模な変更でも考慮することが爆発的に増えるため、現状の振る舞いを仕様とした。これはリポジトリの仕様書にも書いてあり、正式な仕様である。

デザイナのリンク集の設定画面で、リンクの行の左に並べ替えのハンドルを付けた

変更前	変更後

この設定ではリンクの順序を入れ替えられるのだが、一見するとそれがちっともわからないのでハンドルをつけてわかりやすくした。操作説明があるとより分かりやすくなると思うが、そこはやれていない。ちょっと今回やることが多すぎて、それどころではなかった。

デザイナのリンク集の設定画面で、リンクをクリックしたとき編集画面を出すようにした

元々の実装ではリンクをクリックするとリンク先に飛んでいたが、編集できたほうが嬉しいので編集できるようにした。

デザイナの記事ヘッダの日時の設定を、更新日を出すかどうかの設定に変更した

元々の設定だと投稿日か更新日しか出せず、更にページ（コンテンツ）の場合は記事の日付という謎要素まであった。個人的には両方出てほしかったし、投稿日を出さないことはあり得ないと考えていたので、投稿日は必ず出すものとし、更新日を出すかどうかに統一した。

元々の設定画面

通常記事の日時は投稿日時or更新日時で、ページ（コンテンツ）の場合は投稿日時or更新日時or記事の日付だった。

これは元々adiaryでは日付はタイトルの横に出すしきたりがあり、日付は出ているという前提があったからだと思われる？*1

改修後の設定画面

改修後は投稿日付が出ている前提で、投稿日付が二重に出る前提を置かず、更新日を出すか出さないかのBoolean判定とした。

ここで出す投稿日付は編集画面で設定する「日付（yyyymmdd）」であり、adiaryが裏で持っている投稿日時（tm）ではない。

設定画面で設定箇所がおかしかったもの、説明が分かりづらかったもので、見ていて気になった箇所を修正

編集画面の設定にあったサイト全体にかかわるものを基本設定に移す、設定項目がよくわからない物の名前をいい感じにするなど、細々とした対応を行った。

普段Coding Agentを使って作業していると、この辺は人間の数少ない手書きコードの出番である。指示するより書いたほうが早いからね。言うて自動テストとの兼ね合いもあるので最終的な整合はLLMにやらせたりすることもあるが…ｗ

投稿本文の上限を既定で8MBにし、システム設定で変えられるようにした

元々のadiaryでは262,144byteがハードコードされていて、過去に倍の524,288byteに上げたのだが、これでも引っかかることがあったのでPHPの既定値*2に合わせて8MBにし、ハードコードではなく設定画面で増減できるようにした。

ぶっちゃけ絵文字やリガチャーをまぜこぜにしても4MBを超えることは現実的にないと思う。流石に一つの記事に広辞苑を突っ込めば超えるとは思うが、そもそもそれはブラウザがまともに表示できるのかとか、誰が読むのかというのは思わなくもない。

名寄せ対応

コンテンツページ、コンテンツ、ページの呼び方を固定ページに揃えた

長年の歴史により呼び方がブレており、何を指しているのかが解り辛かったので統一した。ついでに記事の種別管理に使われていたフラグの物理名をwikiからpageに変更した。

ブログの呼び方をサイトに揃えた

ブログといえばブログなのだが、Wikiとしても使えるし、SatsukiSystemは強力なので、その気になれば普通のサイトを作ることも可能であることからサイトに揃えた。元から一部の呼称は「サイト」だったため、先のページの件と同じ名寄せ対応みたいなものである。

内部処理にもblogが付いたものが大量にあるが、これらは直すのがあまりにも大変すぎて旨味がないため放置している。jQuery並みの苦行になるのが目に見えており、jQueryのように排除したところで保守が楽になるわけでもないためだ。

「アルバム」の呼び方と内部の名前を「メディア管理」「media」に揃えた

アルバムをメディアに変えた時に残骸があり名前がブレ放題だったので、論理名を「メディア管理」、物理名を「media」に統一した。

機能削除

jQueryを排除した

今回最大の目玉。jQueryを葬り去った。

操作感は体感では完全に維持されている。jQueryUIとdynatreeという化け物みたいなライブラリがやってた内容を素のJSに移植した。

但しjQueryにあった$や$$のようなものは残っており、名残りみたいなものは残っている。全部変えると死んじゃうからね。

この影響でカラーピッカーをWeb標準のものに変えているため、ブラウザによって劇的に操作感が変わるようになっている。HSVのコントロールスライダーもinput type="range"で実装したため、見た目がやや変化した。

今回の対応で変化した部分

直接的にはデザイナのみが影響を受けている。間接的には他にも影響があるのだが、細かすぎてキリがないのでそちらは省略する。

カラーピッカーで現新比較ができなくなった

変更前	変更後

jQuery製の従来のピッカーには現新比較機能があったが、MS Edge標準のカラーピッカーには現新比較機能がないので、これはできなくなった。そもそもカラーピッカーを使ってテーマの色を変えている人がどれだけいるのかが謎なので、ほとんど使用感への影響はないと思われる。

カラーピッカーの色選択が素直にできるようになった

変更前	変更後

jQuery製の従来のピッカーは色選択の操作をするとウィンドウが動いてしまい操作しづらかったが、Web標準のものではこれは起きなくなった。ここの操作感はよくなったと思う。

HSV選択のスライダーの見た目が変わった

変更前	変更後

変更前はjQuery製の従来のスライダーはシュッとした見た目だったが、変更によってWeb標準のものに変わった結果、MS Edgeでは丸っこい見た目に変化した。見た目を元通りにできるのかどうかについては調べていないが、見た目は前のほうが良かったと思う。

デザイナでウィジェットが吹き飛ばなくなった

変更前	変更後

変更前はデザイナでウィジェットを操作していると画面外まで吹き飛んでいたが、これがなくなった。何故なくなったのかは解っていないが、実際の動きを理解することが物理的に不可能なLLMがいい感じにハルシネーションしてくれて当たり前の動きに落とし込んでくれたものだと考えている。

私はLLMに指示を出すときに微妙な実装に関しては解釈の余地が残るような指示を意図的にしており、事前に用意していた「互換性を維持する」という指示を絶妙にバイパスした実装をしてくれるように祈っていたりするので、そのせいもあるかもしれない。

デザイナのプラグイン説明のウィンドウサイズを必要最低限にし、タイトルを改善した

変更前	変更後

変更前、jQueryの時は全幅で邪魔くさかったが、変更後は必要最低限の幅に落ち着いている。またタイトルについても何のウィンドウかが分かるようになった。ここは特に指示してないがLLMがいい感じにやってくれた。

最終編集時間から複数アカウントによる同時編集を判定し、同時編集の競合を阻止する機能を削除

v4.08で入れた別の仕組みで上書きを防止するようにしていたため、こちらの機能は削除した。

この機能は設定画面の整理をしているときに見つけた機能で、削除するまで存在すら知らず、私の場合はこの機能で上書き防止が機能したこともなかったので葬った。

サイトマッププラグインの設定を削除

そもそも何も設定できなかったため削除した。

やらなかったこと

更新RSSを出せるようにする

PukiWikiに存在する機能だが、PukiWikiは更新RSSしか出しておらず、新規作成のRSSはないように見えたので、どっちか片方だけ出すなら更新用はいらないかというので実装を見送った。

というか更新情報欲しい人いるかどうか怪しいし、どっちかというと更新記事を読むのは検索流入のほうだろうからということにしておいた。

余談だがsitemap.xmlは更新日時を持っているため、こいつをパースすると更新した記事を取ること自体は可能である。

麻雀牌とVLゴシックフォント、360度画像の除去を検討

麻雀牌を使う人がいるかどうかは未知数だが、使ってみると思いのほかグラフィックの品質が良く、UTF8に入っているグリフを使うにも一般的な環境にはフォントが入っていないはずなので残すことにした。

VLゴシックフォントには非画像のメタデータをサムネイル表示するのに使われており、他に代わりの手段がないので残すことにした。

ここまで考えたところで360度画像は消す意味もないので残した。

バージョンの桁を文字列管理に変える

現状バージョンの下桁が2桁しかなく99に達したときに詰むので文字列化して3桁くらいにしようと考えたが、まだまだ余裕はあるし、そこに達する未来も見えないので一旦忘れることにした。

困ってから考えたらいい。前に検討したのよりマシな案とはいえ打つの面倒だしね。

コア機能を別リポジトリに切り出す

Satsuki systemは元々Perl製のWebフレームワークらしいし、adiaryもSakiaとして独立させようとしているように見えるので、私も本体から切り離して独立させようとしたが、まぁまぁ根が深かったし、分ける旨味もないのでやめることにした。

ぶっちゃけ現状のLyndbaumはadiaryに由来する超柔軟な構造を持つので、何か別のシステムを作りたければLyndbaumからフォークしたらいいだろうというので、コアの切り離しについてはなかったことにした。

adiary v3.52devからアップデートする場合

以下の手順でアップデートを繰り返すことで乗り換えられる。少なくとも、このブログはそうやって乗り換えてきている。とはいえ、既に十分魔境的な内容ではある。

1. v4.29のタグをチェックアウトし、アップデート処理を行う
2. v4.33のタグをチェックアウトし、アップデート処理を行う
3. v4.34のタグをチェックアウトし、アップデート処理を行う
4. v4.41のタグをチェックアウトし、アップデート処理を行う
5. v4.43のタグをチェックアウトし、アップデート処理を行う

あとがき

歴代のリリース記事を見ていたら機能追加・変更・削除・やらなかったの行数で、今回が最大の更新を叩き出すという恐ろしいバージョンになってしまった。

お陰で記事の頭でも書いた通り、またもや後方互換性を切り捨てたので本家からのアップデートは地獄である。記事をエクスポートしてインポートしたほうが早いかもしれない。ただまだその肝心な場所については検証していないので、実際にできるかどうかは不透明だが…ｗ

今回はタスクをGitHub Issueで作り、詳細の管理、やった理由、やらなかった理由などを書きつつMilestoneを使って消込管理をし、PRからそれらの情報をたどれるように工夫してみたが、やった内容が内容だけあり、カウントが面白いことになってしまった。

感触としてはまぁまぁ悪くはなかったと思う。以前PRからIssueをResolveするのは書くのが面倒なうえPR本文も意味不明気味になりがちだったが、こっちはPR本文に影響せず、情報の紐づけを出来るのが良かった。また対応漏れの管理もできる。

唯一の難点はGitHubはMilestoneのキャッシュにバグにしか見えない挙動があり、はがしたMilestoneがはがせてなかったり、いろいろちょっと面倒なことがあったことくらいだ。

今回の対応の関係でIssueのカウントも激増してしまった。何せ41件増えたからね。

残件は13件で過半数はドキュメンテーションで、機能開発の比重は少ない。多分もうそんな思いつかないし気力もないと思うし、十分機能的にはよくなったので、後はこのままクロージングというか、今度こそは本当に穏やかになっていきたいところだ。

今回は変更量が多すぎて到底人力でのレビューができなかったため、Claude Fable 5.2 High, Claude Opus 5.5 Medium, GPT-6.1 Sol Mediumを総動員してクロスレビューを実施したが、なんとClaudeは一度トークンが切れてしまった。幸いFable 5.2リリース記念の無料リセットが使えたので事なきを得たが、ずいぶん盛大な戦いだった。GPTは以前サブスクを切ったため、このためだけに再契約して使った。

そして現在の残りがこんな感じ。Proなら95%の使用量でもう何もできないところだった。

そもそも土曜の14時前時点で26%とかいうPro換算130%とかいう激しい使い方になっていた。

Max x5は今回の契約限りで終わらせたいので、本当に落ち着かせていきたい…とはいえ、Lyndbaum以外にもやりたいことはあるので中々難しいところだが、ここまで盛大に使うことはないと祈りたいものだ…。

しかし2カラムテーマ対応で共通CSSを作ってしまったせいか、PageSpeed Insightsのパフォーマンスが2下がってしまったのが悲しい。ここは対応すべきかやや迷うポイントである…。恐らくHTTPリクエストが増えることによるオーバーヘッドのせいなので、共通化せずにベタのCSSを個別に作れば解決できる可能性はある。それをする旨味があるかどうかはさておきとして…。