標準添付スキンでは特に使わないが、カスタマイズする際に使えるかも知れないキーワードをいくつか作る予定で、今2つほどできた。◆[[RANDOM:10]]で、1～10までの整数のうちランダムに1つが得られる。投稿ごとにランダムに装飾を変化させたい場合に <div class="design[[RANDOM:10]]"> のように書けば、.design1 ～ .design10 の範囲でランダムに1つのclassが適用されるように作れる。これは外側スキンでも内側スキンでもどちらでも使える。最大数は自由に指定できるので、[[RANDOM:555]]と書けば1～555の範囲内でランダムに1つの数値が入る。◆[[LOOPCOUNT]]で、そのページ内での表示順を整数で得られる。例えば1つの投稿を <div class="order[[LOOPCOUNT]]">～</div> で囲んでおけば、そのページ内で1番目に表示される投稿では .order1 のclassが適用される。もし1ページに30件表示されるなら、30番目の投稿では .order30 のclassが適用される。そのまま表示して 1～30 の番号を振る用途に使っても良さそうだ。表示される投稿番号に関係なく「そのページで何番目に表示されているか」だけを基準に振られるので、「先頭(末尾)の投稿にだけ特別な装飾を加えたい」という場合にも活用できるだろう。(てがろぐの話) もっとも、「先頭にだけ」とか「末尾にだけ」のような、位置に応じて適用する装飾を分けたい場合はCSSの:first-child疑似クラスや:last-child疑似クラスを使う方がスマートに済む気もするが。CSSだけで指定できないくらい複雑なHTMLになってしまっている場合などには使えるかも知れない。

てがろぐの前身になったFumy News ClipperというフリーCGIがある。今もまだ配布中なのだが、開発はほぼ停止している。Fumy News Clipperを最初に作ったのは2004年頃で、文字コードがSHIFT-JISなこともあって、現代ではもはや使いやすいとは言い難い。絵文字も投稿できないし。なので、基本的には「てがろぐCGIがFumy News Clipperの後継CGI」という扱いで居るのだが、「Fumy News Clipperにはあって、てがろぐにはない機能」がまだ少しあるので、Fumy News Clipperの公開も続けてはいる。最近ではごく稀になったが、このFumy News Clipperに対して機能面の要望を頂くことがある。そして、その機能は「てがろぐには既にある」という場合もある。なので、できるだけ「てがろぐ」の使用を検討して欲しいという意味も込めて、Fumy News Clipperの公開ページには「てがろぐ」の案内も掲載していたのだが、昨日その掲示をより目立つ形に修正して、掲載場所も増やしてみた。また、「開発検討中の機能」は削除した。もはや検討していなかったためだ。

「Fumy News Clipperにはあって、てがろぐにはない機能」には、●サイトマップを生成する機能、●修正した投稿の掲載位置を先頭に繰り上げる機能、●投稿本文中にHTMLタグを使用可能にする機能がある。あと、投稿入力欄が複数ある（タイトル入力欄、URL入力欄、コメント入力欄が分かれている）という仕様の違いもある。この入力欄数の違いをどうするかが少々悩ましいところだ。てがろぐには「本文の1行目をタイトルとして扱い、2行目以降を本文として表示する」というようなスキンも作成可能なのだが、その点が初見で分かりやすいか？というと、そうでもないだろう。オプション設定で入力欄の個数を増やせるようにする手もあるが、それで分かりやすさが向上するかどうかは分からない。むしろ、てがろぐをベースにしてFumy News Clipperの新バージョンを再構築して、入力欄を複数設けておくという方が望ましいのかもしれない。なお、総合的な機能は、てがろぐの方が圧倒的に多いので、「てがろぐにあって、Fumy News Clipperにはない機能」というのはもう挙げればキリがない。(いや、キリはあるが。)

てがろぐCGIで「1行目をタイトルとして扱う」みたいなブログっぽいスキンを作っていても、そのタイトルを（出力されるHTMLの）title要素に指定することはできない。なので、ブログ用途にはあまり向かないよな、と思っていたのだが、最近のGoogleはページ上のJavaScriptも実行した上で情報収集してくれるようなので、投稿単独表示時にだけ「ページ内のタイトル表示部分の中身」を document.title に指定するようなJavaScriptを書いておけば、ページタイトルも望み通りにできるのではないか。投稿単独表示時にだけ指定のJavaScriptを実行するには、(標準添付スキンの場合は)onelogというclass名がbody要素に指定されているかどうかを判断すれば良い。例えば、タイトルのように見せる部分の要素に pagetitle というclass名を付加しているなら、querySelector の引数に .onelog .pagetitle と指定すれば良さそうな気がする。返値がnullなら投稿単独表示ではない（または.pagetitleがない）ので何もせず、返値があればその値を document.title に代入すれば良いのではないか。

てがろぐCGIで、Ⓐ「記事一覧」とⒷ「記事単独」とで全く異なるデザインを用意したいとき、以前なら「Ⓐ用のスキン」と「Ⓑ用のスキン」を用意して……のように考えていたが、そうするよりも、HTMLにはⒶ用・Ⓑ用双方のマークアップをすべて含めておき、Ⓐ用にはCSSでbody:not(.onelog)配下にスタイルを書き、Ⓑ用にはbody.onelog配下にスタイルを書く、それぞれの状況で不要な要素にはdisplay:none;を適用する……という方法の方が簡単で分かりやすい構造になるのだな、と気付いた。この方法だと、用意するスキンは1つで済むので、状況に応じて適用スキンを分けるようなアクロバットなことをしなくて済む。

(追記) 詳しくはこちら➡一覧表示時と単独表示時とで適用デザインを分ける方法

適用スキンはそのままで、CSSだけを変更できる着せ替え機能を実装したい気もしている。そうすると、色違いバリエーションを提供しやすくなるし。「スキン」という形でしか配布できない仕様よりも、CSSを1つだけでも配布できる仕様の方が手間が減って望ましそうだし。ただ、その前に、以前のロードマップで示した「投稿ごとのパスワード保護機能」を先に作る方が良いか、ちょっと迷う。

内側スキンに使える新しいキーワード [[POSTSTATUS]] を実装した。ローカルのソースに。これを、「1投稿を構成する親ブロック」に例えば <div class="onelogbox [[POSTSTATUS]]"> みたいな感じで書いておけば、その投稿が先頭固定な場合には class="onelogbox logstatus-fixed"、鍵付き投稿の場合には class="onelogbox logstatus-lock"、下げる投稿の場合には class="onelogbox logstatus-rear" みたいな感じで出力される。投稿の状況に応じて装飾を分けたい場合に、そこそこ活用できるかもしれない。鍵付き投稿にだけ特別な装飾を加えたいときとか。なお、鍵付きの投稿で、正しい鍵が入力された後では class="onelogbox logstatus-lock logstatus-unlocked" のように表示されるようにした。とりあえず、 標準添付各スキンの内側スキンには [[POSTSTATUS]] を全部書き加えておこう……。

約3ヶ月前（6月下旬）にリリースしたカレンダー表示CGI「さんごよみ」は、20年前に配布を開始した同種CGI「Fumy Teacher's Schedule Board」の後継という位置付け（ただしCGIは、てがろぐCGIベース）で、旧CGIにある機能はすべて新CGIにあるので、旧CGIページは最終的には閉鎖してリダイレクトする予定でいた。旧CGIページには予告として「後継CGIは別にあるよ」という意味のリンクを掲載した上で、「このCGIはもう開発終了」という案内も掲載していた(下図1枚目)。さっき「カレンダーCGI」の検索語でググってみたところ旧CGIページよりも新CGIページの方が上位にヒットするようになっていたことだし(下図2枚目)、旧CGIページを新CGIページへリダイレクトするよう.htaccessを書いた。

ディレクトリ丸ごと一括リダイレクトさせようかとも思ったのだが、配布ページTOPにアクセスした場合にだけリダイレクトされ、ZIPファイルに直接アクセスした場合にはForbiddenエラーになるようにした。ページ中の解説用画像は他のページ(ブログ記事とか)で流用掲載している可能性があるので、画像(というかTopのHTMLやZIPファイル以外のファイル)にアクセスされた場合には(リダイレクトされずに)そのまま表示されるようにした。具体的には.htaccessに以下の5行を書いただけだが。
RewriteEngine on
RewriteRule ^(index\.shtml)?$ /cgi/sangoyomi/ [R=301,L]
<Files ~ "\.zip$">
deny from all
</Files>
RewriteRuleの正規表現パターンは、その.htaccessファイルがサブディレクトリ内にある場合には「そのサブディレクトリ名の終わりに付く『/』記号よりも後の部分」だけにマッチするので注意する必要がある。とりあえず思いつくままに書いたところ動かなかったのでググったところ、このページの解説(リクエストのどの部分が正規表現パターンと比較されるのか)が分かりやすかった。感謝。

インスタ埋め込みとか、細々した要望の分を実装したいのだが、そろそろVer.4に向けた実装も始めたい。主にセキュリティ回りの機能のアップデートだが。あとは、HTMLソースを直接書ける機能とか。それがないから、まだFumy News Clipper（てがろぐの前身だった古いCGI）の公開を停止できないでいるので。

てがろぐのスキンには INCLUDE記法 を使って任意のファイルの中身をそのまま読み込めるので、ウェブサイト共通のヘッダやフッタ等を単体のファイルに独立させてSSIやPHPで合成している場合には、そのファイルをINCLUDE記法で読み込めば、てがろぐの出力ページをサイト全体のレイアウトと合わせやすい……という話はどこかに書いていたっけな……？

このサイト内には、てがろぐ生成ページが2種類ある。1つは「今日のひとことログ」(ここ)で、もう1つは「てがろぐリリースノート」だ。これらは対極的な使い方をしている。前者は1投稿あたりの文字数は短く装飾も少ないが総投稿数は多い。後者は総投稿数はすごく少ないが1投稿あたりの文字数が多く装飾も多い。数値で比較すると、以下のようになる。

• 今日のひとことログ：投稿総数9190件、データファイル5.00MB（＝5,121KB）、1投稿あたり平均0.56KB、出力1ページ目のHTMLサイズ106KB
• てがろぐリリースノート：投稿総数39件、データファイル0.43MB（＝439KB）、1投稿当たり平均11.3KB、出力1ページ目のHTMLサイズ394KB

投稿総数で見てもデータファイルで見ても、圧倒的に前者の方が大きいのだが、アクセスしてみて重たいのはどちらかと考えると後者の方が重たい気がする。前者は1ページに100件掲載し、後者は1ページに10件しか掲載していないにもかかわらず。（※1投稿あたりのデータサイズを比較すると、後者が前者の20倍あり、生成されたHTMLのサイズは4倍ある。）
ここから考えて、やはり（投稿総数とかデータファイルの大きさとかはあまり関係なくて）1投稿あたりの装飾の多さが重たさに直結しているのではないか。装飾の多さというか、「てがろぐ内部で独自記法をHTMLに変換する作業数」という意味だが。その変換が多ければ多いほど、ページを出力するよりも前に遂行しないといけない作業が多くなるので、重たくなりやすい気がする。
なので、動作を軽くするためには、その変換作業を軽減してやれば良い。装飾量を減らすとか、1ページ当たりの表示数を減らすとか。装飾量(とかリンク量とか)さえ少なければ、文字数そのものは多くても問題ない。
HTMLソースをそのまま自力で書けるようにすると、（HTMLで直接装飾等を書けば）てがろぐ側の独自記法をHTMLに変換する作業が省けるので、重たくならずに済みやすいかもしれない。

てがろぐ経由でUPした画像を、投稿内で使われているかどうかに関係なく、単に新着順に全部リストアップして並べるだけの表示モード（イメージリストモード）の実装を考えているのだが、これ、てがろぐ内部機能として実装するよりも、独立したPHPとして用意して、「てがろぐの画像保存用ディレクトリに置けば連動して（てがろぐ側で設定したフラグとかキャプションとかを反映して）動作」して、「てがろぐとは無関係のディレクトリに置けば、そこにある画像を対象にして表示」みたいな、独立したスクリプトとしても使える形で用意すると、複数のディレクトリを使って画像を管理している場合にも役に立つのではないか、というような気もなんとなくしている。どの場合も、ページの出力は「てがろぐ用スキン」を読んで解釈して出力する感じで。ただ、そうすると、PHP1つファイルが増える問題とか、てがろぐ側から「1ページあたりの表示件数」とか何かそういう系統の調整をどうするかとか、そもそも（そこにある画像をただひたすら表示する系としては）同種のスクリプトが他にもあるだろうとか、ちょいと懸念点もあるにはある。