にしし らぼらとりー

そういえば、このような掲示板モード用の入力欄カスタマイズ機能を用意すれば、掲示板として使わない場合でも、例えば「タイトルと本文を分けたい」という場合に、「1行目をタイトル、2行目以降を本文」という運用にしなくても、物理的に「タイトル入力欄」と「本文入力欄」に分割して用意できるメリットもありそうな気がする。その場合、もちろん「1行目をタイトル、2行目に分類用タグ、3行目以降を本文」としてきたなら、「タイトル入力欄」・「タグ入力欄」・「本文入力欄」に分割して用意できるメリットもある。

16進数のRGB値だけでなくて、RGBAカラーモデルで透明度も含んだ色を指定したいな……。rgba(255,105,180,0.2) みたいな。まあ、自由装飾機能を使って opacity を指定したclassを事前に用意しておけば似たようなことは今でも可能だけども。

もし「掲示板モード」を作るとしたら、投稿を(管理者へ)メールで知らせる機能が必須だろうから、メール送信機能も加えないとな……。すると、掲示板として使わない場合でも、メール送信機能を流用して「メッセージ送信フォーム」にできるような機能も用意できるメリットがある。

てがろぐFAQページを、てがろぐを使って生成すれば、現状のような「まとめて閲覧」もできるし、「1ネタ1ページで閲覧」もできるし、検索もできるので望ましそうに思えるのだが、あのFAQを作るにはHTMLソースを自由に書けないとまず無理なので（できるかもしれないがかなり大変そうに思えるので）、まず、てがろぐ上に自由なHTMLソースをそのまま書ける機能を実装する必要がある。

関係者だけがアクセスできるクローズドな場所で、既存の(他者製の)掲示板CGIをカスタマイズして連絡板を運営しているのだが、2000年代のCGIなのでカスタマイズになかなか手間がかかる。画像も投稿できないし。なので、てがろぐの「掲示板モード」を作りたい気がかなりしている。No.2366に書いたような、複数の入力項目を作った上で、それらの値を行単位で保存するような形にすれば、現状のてがろぐCGIからそういう大きな改造をしなくても実現できるのではないか、という気がしている。行頭に項目名(id属性名)が記録されるような形にすれば、後から項目を増減した場合でも柔軟に対応できて良いのではないか。
form:name=にしし
form:url=https://www.nishishi.com/
form:title=無題
form:delpass=hogehoge
本文は行頭に何もなしで。
実際の投稿者IDは、全部 guest にするとか。自前のIDでログインしている場合には、(ユーザ設定にある)自前のアイコンで表示される、とすると、管理者と不特定多数とをシステム的に区別もできて望ましそうな気もする。

ファイルのタイムスタンプを取得できるような [[FILE:TIMESTAMP:tegalog.css]] みたいな記法を作ろうかな……。これをCSS読み込みのクエリ文字列に加えれば、「CSSが更新されたときにだけクエリ文字列も更新される」みたいにできるので、確実にキャッシュをクリアできる上に、無駄なキャッシュクリアは避けられる。

CSV形式(カンマ区切り)でリンクリストを登録しておけるようなフリースペース「フリーリンクリスト」みたいな機能も用意しようか……？ リンクラベルとURLをカンマ区切りで1行1件で書けば、それがul＋li要素で出力されるような。レコードに3列目があれば画像ファイルだと判断して画像リンクにしても良いかもしれない。（そういうのは既存のフリースペースにHTMLを書いてくれれば良いと思っていたが、そういう前提にしてしまうと、配布スキン側でデザインを用意しておきにくい問題はありそうだ。）

リンクを作るときに [ラベル:NF]URL みたいにすると、出力されるa要素に rel="nofollow" が加わるような機能を加えたい。（現状でも、あらゆるリンクに rel="nofollow" を加える設定機能ならあるが、それだとリンク先に応じた選択はできないので。） #済

てがろぐのヘルプドキュメントも、技術系ドキュメントサイトでよくある「メニュー段と本文段の2段組で、メニュー内のハイライトが現在位置に連動する」ような感じにしたいが、なんか手軽に作る方法はないものか。てがろぐの場合はメニュー項目数が多いので、そこもちょっと大変そうな気もしたりしなかったり。

レンタルサーバ別のセットアップ方法は詳しく用意したと思ってはいるのだが、それでもまだ情報が足りないという場合、何が足りないのだろうか。FTPソフトを使ってパーミッションを変更する方法が分からないとか、その辺の操作方法？

てがろぐを(不特定多数が利用できる)掲示板的に活用したいとすると、少なくとも「名前」の任意入力欄が要る。しかし、そういうUIを付け加えられるオプションを加えてしまうと、UIもデータもずいぶん複雑になるし、そもそも設定が分かりにくくなる問題がありそうな気がして、望ましくはなさそうに思っていた。のだが、てがろぐには元々「投稿本文を行単位で分解して扱う」機能があるのだから、投稿欄そのものも(スキン側で)分割して用意できる仕様を用意して、投稿欄がいくつに分割されていようとも上から順に1行目扱い・2行目扱い・3行目扱い……というようにデータに記録する仕様にすれば、あんまり複雑にすることなく掲示板のようにできるのではないか、というような気もしてきた。

今のところ、スキン側で投稿欄をどうにかする仕様はないし、未ログイン状態で投稿できる機能もないので、これを実現するとしたらその辺は新しく加えないといけないけども。しかし、「投稿本文を行単位で分解して扱う」機能を活用するなら、掲示板の項目数も好きなようにできるし、わりと柔軟な掲示板にできそうな気もしないでもない。

てがろぐ設置の創作系サイトサーチ「てがWA！」の反響がすごくて、そんなに需要あったんか、と驚いている。いや、需要あったんか、というか、てがろぐユーザがそんなに居たのか、という驚きもあったが。(笑)
サイトを拝見して、私では絶対にこう上手くは作れなかっただろうから、やはりサーチサイトの文化を理解している人が作ると違うな……と感心している。たいへんありがたい。

私が作りかけて放置している「てがろぐユーザリンク集」的なものは、だいたい以下のような形態を考えていたので「サーチ」という感じでは全然ない。

• てがろぐが稼働していれば、内容(ジャンル)に関係なく登録可能。
• てがろぐCGIへの直リンクと、(併載されるバナー等で)サイトTOPへの2つリンクを掲載。
• 定期的に（登録された各てがろぐを）クロールして、タイトル・概要文・更新日時の最新情報を取得して自動更新。
• 最終更新日時の新しい順にソートして掲載。

（もしできあがれば）単に更新日時の新しい順にリンクBOXが並ぶだけの、かなり雑多なリンク集になる気がする。
分類から探すような「サーチ」ではないので、ほぼ「一期一会」みたいな？ たまたま目に付いたものにアクセスしてみるような。
なので、先の「てがWA!」と競合はまったくしないだろう。

※もし完成したら、の話である。^^;（このまま放置が続いて完成しない可能性もある。）
需要はあるっぽくて、登録者もそこそこ居そうな気配なので、製作を再開しても良いかなとは思っているのだが、1からPHPを書いているので、どちらにしても時間はかかる。

てがろぐCGIを1個設置しておくだけで複数個のマイクロブログを作れる仕様になっていると、便利だとは確かに思う。
例えば tegalog.cgi?file=hogehoge.xml のようなパラメータを加えることで、デフォルトのデータではなく hogehoge.xml のデータを読んで表示するような。
最初から複数のデータファイルを扱える仕様で設計を考えていれば、実現はそんなに難しくはなかったとは思うのだが、最初の開発の段階ではそうは考えなかったので、そう簡単にはいかない状態になっている。

便利だとは思うので（実現できたら個人的にも便利に活用するシーンが多々あると思うので）、時々は「何かうまい方法はないかな？」と考えはするのだが。

ハードルは主に2点。

まず、パラメータを絶対にずっと維持しないといけない点。
file=hogehoge.xml というパラメータでアクセスされた後は、あらゆるリンクに &file=hogehoge.xml を漏れなく加える必要がある。どこか1カ所でも抜けてしまうと、そのリンクを踏んだときにデフォルトデータへのアクセスに戻ってしまう。現状のてがろぐ内には（ページ移動でも管理画面内でも）多数の移動経路があるので、本当に漏れなくパラメータを維持させられるか確認するのが面倒という話。(^_^;) これは、「一時適用スキンの維持」と同じ仕組みが使えるので、そこまで大きな問題ではないかもしれないが。ただ、スキンの場合なら「いつの間にかデフォルトスキンに戻っていた」といってもそんなに問題にならないだろうけども、データファイルの場合はそうとも言い切れない。例えば、本当は hogehoge.xml から10件削除するつもりだったのに、デフォルトの tegalog.xml から10件削除されてしまった、とかちょっとダメージが大きそうだし。なので、実装してみてもその厳重な動作テストが要るよな……というハードル。

もう1つは、キャッシュも設定もすべて同じファイル tegalog.ini に記録されている点。
複数のデータを扱う仕様を考慮していなかったので、てがろぐの動作設定も、カウント値とかのキャッシュデータも、何もかもを全部一緒くたにして1つのINIファイルに保存する仕様になっている。なので、複数のデータファイルを扱えるようにするには、既存のINIファイルから「動作設定」部分と「キャッシュ」部分とに分離してファイルを分けないといけない（気がする）。とはいえ、動作設定もデータファイルごとに分ければ良いのではないか（むしろその方が便利かもしれない）という考えもあるかもしれない。しかし、動作設定には「動作に関する設定」だけでなくて「ユーザ一覧情報」も含まれているので、そこを分離すると困る（ユーザ情報は同じデータをずっと保持しないとログイン状態が維持できないので）。
まあ、それなら「ユーザ情報」と「動作設定・キャッシュ」の2つに分割すれば良いのではないか、という話はあるが。

ただ、複数のINIファイルが存在する可能性を一切考慮せずに作り始めたシステムなので、CGIが実行された時点でとりあえずINIを問答無用で読み込むような処理になっている。なので、そこを変えるなら、かなり最初の段階の動作から変更することになるので、連鎖的に変更しないといけなくなる分量が多くなりそうだ。従来なら最初に1回問答無用で1つのINIファイルを読んでおけば良かっただけのところを、INIファイルAだけを問答無用で読み、パラメータに応じてどのINIファイルBを読むのかを判断して読まないといけないわけだし（※これにはさっきの「本当に読むべきファイルの方を間違えずに読み続けられるのか」という問題もある）。そうすると、ただでさえスパゲッティ気味なソースが、救いようのないほどこんがらがるのではないか、という懸念もある。なので、そのような改変を加えるなら、まずは大規模にリファクタリングをして、ソースを綺麗に整頓してからでないと危険だろう。……というハードル。

あと、細かい話だが、
設定ファイルを2つ分割すると、デフォルト状態（＝マイクロブログを1個しか用意しない状態）でも2つの設定ファイルが要ることになるので、構成ファイルの数が1個増える。
できるだけシンプルに見えるようにしたいという思惑もあるので、構成ファイル数を増やしたくないという思いもある。
CGIなのでパーミッションの設定をしてもらわないといけないので、ファイルは少なければ少ないほど望ましい。もちろん、1個増えただけでそんなに手間が増えるわけではないのだが。「1個だけで済むのか」は詳しく考えてみるまで分からない。とにかく、あらゆるデータは全部INIファイルに放り込んでいる仕様なので、もしかしたら3つに分割しないとやっていけないかも知れないし。

……というように、わりと考えないといけないことがかなーり結構たくさんあるので、（実現したら便利になるだろうとは思うのだが）なかなか手が出せない。

で、そこまでするのと比較すると、もう「てがろぐを2つ設置してくれ」となるわけである。(笑)

もしかすると、「設置を1個で済むようにする」よりも、「自動でバージョンアップできるようにする」方が、役に立つのではないか。設置を1個で済ませたいのは、バージョンアップの手間を省きたい、という理由も大きそうだし。

>>2361 ただ、標準添付スキンをベースにしてちょっとだけ（配色とかを）書き換えるだけの小さなカスタマイズだけをして使っていて、バージョンアップのたびに標準添付スキンも（自分のカスタマイズ箇所だけを書き換えて）上書きアップロードしている……という場合、標準添付スキン側のソースが大改造されてしまうと困る可能性がある問題はあるかもしれない。そういう使い方をしているユーザさんが居るかどうかは分からないが……。

画像のタイムスタンプ（≒画像ファイルのUP日時）を出力できる記法って要る？

てがろぐ標準添付の各スキンは、IEを考慮したCSSになっているので、さすがにそろそろ全面的にモダンなソースに書き換えた方が良い気はしている。気は。特に2段組の作り方。

今、唐突に気付いたのだが。てがろぐ配布ZIPの中には、データファイルが3つ含まれている。tegalog.xml と tegalog.ini と psif.cgi だ。これらは、バージョンアップ時に誤って上書きしてしまうとデータが消えてしまうので、あえて 2017年 という古いタイムスタンプにして収録してある。その場合、仮に全ファイルをまとめて上書きアップロードしようと操作してしまっても、FTPソフトで「新しい場合にだけアップロード」みたいなオプションを使っていれば、上書きが阻止されるだろうから。仮にその機能を使っていないとしても、展開したファイルを更新日時でソートすれば、上書きが必要なファイルだけが上に並ぶだろうから。
……のだが、ZIPの展開ソフトによっては、中身を展開した時点で元ファイルのタイムスタンプを破棄して、「展開した瞬間の日時」に書き換えてしまうのもあるのな……。その場合、あえてタイムスタンプを古くしてある配慮に意味がなくなる。

そして、Windowsの標準機能でファイルを展開した場合も、元のタイムスタンプは破棄されて「現在日時」がタイムスタンプになることに、いま気付いた……。_(┐｢ε:)_
なんでやねん。┌(:3」└)┐

投稿日時として50年以上前の日付(1973年とか)を指定したとき、相対時間表記（＝投稿時点からの経過時間の表記）が正しくなくなる問題を修正した。さすがにそんな日付で投稿するユーザは居ないと思うが。エポック秒から日時を割り出す localtime では「年」の値が1900年からの相対値で得られるので、日時をエポック秒に変換する timelocal でも「年」の値をわざわざ「西暦-1900」にしてから渡していたが、この方法だと「現在から50年以上前の日付」に対しては未来の日付だと解釈されてしまう仕様らしい。解説を読んで初めて知った。localtimeとは違って、timelocalの年の値は最初から西暦4桁をそのまま渡せる仕様なので、何も加工せずに西暦4桁の数値を引数に与えれば良いのだった。

一定の間隔（月一とか週一とか）で、データファイル(tegalog.xml)と設定ファイル(tegalog.ini)を指定のメールアドレスに自動送信するバックアップ機能でも用意しようか……？

設定画面の「フリースペース」に、『上書きスタイル』という専用の汎用入力欄を設けておいて、そこにCSSソースを書けるようにして、それをhead要素の最後に読み込む仕様にしようか。そうすると、標準添付スキンをそのまま利用していて毎回上書きしている人でも、自力で作成した配色スタイルだけはずっと維持できる。（head要素の最後に読み込めば、そこに書かれている内容でスタイルが上書きされるから。）した。#済

そうか。予約投稿機能も作らないとな……。作った。#済

インライン系要素の中にブロック系要素を入れると、ブロック系要素の開始位置でインラインが終わったと解釈されてしまうHTMLの仕様があるので注意が必要だ。
てがろぐが出力する [[COMMENT]] には、ブロック系の要素が出力されることがある。例えば、箇条書きリストの <ul>～</ul> とか。なので、もし <p>[[COMMENT]]</p> のようなHTMLを書いてしまっていると、<p><ul>～</ul></p> と出力されることになる。これはHTML的には誤りで、<ul>タグが登場した時点でp要素は終わったと解釈されてしまう（＝HTMLの文法的に、p要素の内側にul要素を含めることはできないため）。なので、CSSが意図通りに適用されなくなる問題が出る。
このような問題を避けるには、とにかく [[COMMENT]] を『ブロック系要素を含められないような要素』で囲まないこと。
[[COMMENT]] を何かで囲みたい場合は、div要素だけを使うと考えておくのがお勧めである。

……という話をFAQに追加しておきたい。カスタマイズ方法ページに書いた。

正式版リリースの場合でも、β版で普段やっているように「バージョンアップ用のパッケージ」（＝更新されたファイルしか入っていないZIP）を用意する方が良さそうな気配だな……。容量の問題ではなくて、上書きしちゃいけないファイルを上書きしないようにするために。

てがろぐのログイン画面では、IDをプルダウンメニュー（セレクトボックス）から選択するようになっている。これは、「自分のIDをここから現実的に選べる程度の人数が上限と考えてくれ」という感じの意味合いもある。仕様上はユーザ数の上限はないのだが、データベースを使っていない構造からしても、たくさんの人数が同時に投稿し合うような用途に使うのは現実的ではない。管理者権限を持つIDを複数作成することもできるが、Aさんが設定画面にアクセス→Bさんが設定画面にアクセス→Aさんが設定を変更して保存→Bさんが設定を変更して保存……のようなタイミングで操作されると、Aさんの設定変更はなかったことになる。（そういう操作から保護するような機能は一切ない。）「全員が1つのTLを共有する」形なので、まあ、そんな大人数で使われる（使おうと思われる）ことはないだろうと思ってはいるのだが。具体的にどれくらいが上限だとかは何も考えていないのだが、せいぜい「数人」くらいが現実的なのではないかと思ってはいる。

Twitterから全データをダウンロードすると、ツイート本体は tweets.js というファイルの中にJSON形式で入っている。"full_text"という項目にツイート本文があって、"created_at"という項目に投稿日時がGMTで入っているので、この2つを抜き出して tegalog.xml で使えるXMLに変換すれば、過去ツイートをてがろぐ形式にはできるだろう。てがろぐ側には文字数制限がないので、そのまま抜き出すだけで良いだろうし。Twitter側には文字を装飾する機能がないのでプレーンテキストだし。たぶん、\nを<br>に変換するくらいの手間だけで良いような。掲載URLが全部 t.co ドメインになっているのはどうしようもないが。GMTの日付は「Thu Nov 03 11:54:17 +0000 2022」みたいな形式で収録されているので、これをJSTに直した上で YYYY/MM/DD hh:mm:ss 形式にしないといけないが。PHPとかにその辺のことを楽にできる関数でもあっただろうか？ ただ、画像は面倒くさそうだ。画像は tweets_media フォルダにまとめて格納されているので、"media_url"項目にあるURLからファイル名部分を抜き出して、さらに"expanded_url"項目にあるURLから数字列を抜き出して、「1588137486144114688-FgoyWg9aAAEKTjj.jpg」みたいにハイフンで繋げれば、画像ファイルを特定はできそうだけども。全部この方法でいけるのかどうかは分からん。

せめて配色部分だけでもカスタム変数にしてCSSソース冒頭にまとめておく方が親切かな、という気もしないでもない。ただ、カスタマイズする人はもっと全体的にカスタマイズするだろうから、配色だけカスタム変数にしてもあまり意味ないのではないか、という気もする。

画像インデックスXMLファイルを直接編集する方法については、どこに書こうか迷ったのだが、投稿データファイルであるtegalog.xmlの直接編集方法を「FAQ・豆知識」ページに書いていたので、それと同じにしておいた。
➡大量の画像キャプションを一括設定(編集)したい場合は、XMLデータを直接編集すると楽かもしれない
全画像データの先頭には、全画像データをまとめた <total>～</total> という情報行があるのだが、ここは実データから常に自動更新されるので、手動でXMLファイル内を編集するときにここを自力で計算して書き換える必要はない。てがろぐ側で再生成されるまで、画像総数とかトータルサイズとかの表示が正しくなくなるが、表示上の問題なので特に不都合はないだろう。すぐにてがろぐ側で画像インデックスを更新させれば問題は何もない。そもそもこの <total>～</total> 行は削除しても（すぐにてがろぐ側で再生成させるのなら）何も問題はない。

あと1時間以内くらいにはリリースできるはず……。

標準添付各スキンのCSSでは、figcaption要素に display: table-caption を適用している都合で、figure要素に border プロパティで枠線を付けても、キャプションは枠線の外側に表示されてしまう。「キャプション自体も含む画像ボックス全体」を枠で囲みたい場合は、border プロパティではなく outline プロパティを使って線を引く方法はある。ただ、outlineプロパティで引いた線は、border-radiusの影響外なので、線の角を丸めることはできないが。

てがろぐの投稿をePub形式に出力して、そのまま電子書籍リーダーで閲覧できるようにならんかな？

代わりに誰か書いてくれー。_(┐｢ε:)_

さすがに昨日のでは見づらすぎるので、リリースノート用の項目を整理した。

目次の段階でそこまで詳しく書かんでも良いだろうし、開発段階のToDoとしては別項目でも、ユーザ側から見れば「単独の新機能」に過ぎない項目もあるので、統合できるのは統合した。分かりやすくする目的もあるが、何より項目数を減らさないと（リリースノートを）書きにくいので。

今後のβ版では、追加機能の解説をFanbox上に書くのではなくて、β版の追加機能の説明自体も本番解説サイトに追記していくようにしたい（正式版にはまだ含まれていない機能であることは、『β版』みたいななんかタグで示しておけば良いだろう）。そうしないと、正式リリースのたびにドキュメントを書く作業がめちゃくちゃ大変で、気力が維持できない……。_(┐｢ε:)_
特に今回は、めちゃくちゃ多いから……。

もうちょっと手前で正式リリースを刻むべきだった……。orz

てがろぐの設定画面で表示/非表示を切り替えられる機能については、できれば設定画面の設定項目を利用して消してくれると嬉しい。
CSSを使って消されてしまうと、

• てがろぐ設定画面での設定でON/OFFできなくなる。
• バージョンアップで新たに追加された機能による出力があっても（CSSによって）最初から見えないままになる。

という問題があるので……。（それに、設定画面で非表示にすれば、無駄なHTMLが出力されるのを防げるメリットもある。）
いや、どう使うのも自由なので、本人が理解した上でCSSで消すなら構わないのだけど。

集中してドキュメントを書く日を作らないと、いつまで経っても書き上がらない気がする。1月の早い内に確保したいが……。

ドキュメントの追記だけで1ヶ月くらいかかりそうやな……。_(┐｢ε:)_

Ver 3.8.0(正式版)以降に追加した機能（つまり、Ver 3.9.0正式版として提供する機能）が以下の通りあるのだが、これ、どれだけドキュメントを追記すれば良いのか……？┌(:3」└)┐
もうちょっと刻んで、この半分くらいで3.9.0にした方が良かったのではないか。いまさらだが。_(┐｢ε:)_
続きを読む
《▼新機能・仕様改善》
●インスタグラムの埋め込み機能。
●新着画像リスト（最近に投稿された画像だけの一覧）の出力機能。(一覧外フラグが付いた画像は表示しない)
●アップロードされた画像1つ1つにキャプションやフラグを登録しておける画像インデックス機能。(index.xml生成機能)
●画像ごとにキャプションやフラグを設定操作できる画像編集画面。
●画像に付与できるフラグ（新着画像リストに表示しない「一覧外」、閲覧注意classを付加できる「NSFW」）機能。
●画像をキャプション付きで表示できる新記法 [PICT:FIG:ファイルパス] を追加。
●画像のキャプションをその都度指定できる新記法 [PICT:FIG(キャプション):ファイルパス] を追加。
●サムネイル画像が存在する場合には『ページ上の表示にはサムネイル画像を使い、Lightboxでのリンク先にはオリジナル画像を使う』ように表示できる機能を追加。
●「続きを読む」ボタンのラベルをその都度指定できる新記法 [H:ボタンラベル:～中身～] を追加。
●リストを表示するための専用記法。（箇条書きリストや番号付きリストが表示可能に）
●経過時間(相対時間)表示（n分前、n時間前、n日前……のような表示）ができる日付表記オプションを追加。使用単位を「時間→日」に切り替えるタイミングは自由に設定可能。
●ページ番号の省略を始める総ページ数を自由に設定できる機能。
●ページ番号リンクの両端（先頭と末尾）に何ページずつ固定表示するかを変更できる機能。
●サイドコンテンツ各種(例えばハッシュタグ一覧やカレンダー等)でも、ギャラリーモードやサイトマップページを維持したリンクを出力できる新記法を追加。
●上位ディレクトリや別階層に存在するスキンも指定可能に。「?skin=../upperdir/some/skin-dir」のような感じで。
●スキン切り替え画面で、任意のディレクトリ名を指定してスキンをプレビューしたり簡易適用したりできる機能を追加。
●画像の新規アップロードと同時に、フラグやキャプションを設定できる画像管理画面でのアップロード機能。(画像が複数ある場合は、全部に同じ値が加わる仕様。)
●鍵付き投稿・下書き投稿と同時にアップロードされた画像には、最初から「一覧外」フラグを立てる仕様。
●投稿本文内に含まれる画像をすべて抽出して表示できる記法 [[COMMENT:PICTS]] の追加。
●各種ディレクトリのパス(PATH)を得られる新記法 [[PATH:CGIDIR]] や [[PATH:SKINDIR]] 等を追加。
●拡大画像をLightboxで表示できるテキストリンクを作る記法 [リンクラベル:LB] に、「画像リンクに独自のclass属性値を追加する」と同じclass属性値も追加されるよう仕様改善。
●記法 [!-- 中身 --] で、任意の範囲をコメントアウトできる仕様。
●RSS Auto-Discoveryを挿入する記法 [[RSS:AUTODISCOVERY]] を追加。(外側スキンのみ)
●投稿本文の行数が得られる記法 [[TOTALLINES]] を追加。(内側スキンのみ)
●スキン内に記述されている link要素やform要素に対して、「現在のスキンでの表示を維持する」目的で自動挿入される各種記述をスキップできる記法 [[NO-LINKADJUSTMENT]] を追加。※スキンの先頭に記述した場合のみ有効。先頭記述が要求されている他のタグ [[NO-LINKADJUSTMENT]][[NO-COMPLEMENT]] は同時に書ける。（外側スキンと内側スキンのそれぞれに記述可能。外側スキンだけに書いた場合、内側スキンには影響しません。）
●[[INCLUDE:～]] 記法と [[PATH:～]] 記法を、内側スキンでも使用可能に。(従来は外側スキン専用でした)
●任意のファイルを挿入できる INCLUDE 記法の仕様拡充。

•    今読んでいるスキンディレクトリに存在する特定のファイルを読み込む [[INCLUDE:FROM-THIS-SKIN-DIR:ファイル名]] 記法を追加。
•    [[INCLUDE:～]] 記法の中で [[PATH:～]] 記法によるパス指定が可能に。
•    [[INCLUDE:～]] 記法で合成されたファイルの中に書かれている [[INCLUDE:～]] 記法も解釈するよう仕様改善。(ただし3階層まで)
•    [[INCLUDE:～]] 記法で合成されたファイルの中に [[CALENDAR]]、[[DATEBOX]]、[[LATESTLIST]] 等、一部の記述があるとき、それが正しく解釈されない可能性があった点を修正。
•    [[INCLUDE:～]] 記法で埋め込むファイル名として「/」で始まる絶対パスが指定された場合は、DOCUMENT ROOTからのパスとして解釈するよう仕様改善。(従来は相対パスでの記述を求めていました)

●文字色として自動入力するサンプルと、背景色として自動入力するサンプルを設定できる機能を追加。
●ログインフォームの下部に表示できるメッセージを設定画面で設定できる機能。
●画像管理画面から画像を選んで新規投稿する際のプルダウンメニュー項目を「新規投稿に使う（キャプション付き）」と「新規投稿に使う（画像のみ）」の2種類に拡張。
●画像の縦横サイズ(HTMLで出力されるwidth・height要素)の値を手動でも設定できる機能。
●ハッシュタグだとは認識されない「 # 」記号を簡単に表示させる方法として、「&#35;」を入力できる項目をハッシュタグ簡単入力プルダウンメニューに追加できる機能を追加。
●ファイル読み書き時の安全処理を追加。
●記述サンプルを自動入力するかどうかの設定項目を追加（リスト、文字色、背景色のサンプル自動入力のON/OFFをまとめて設定）
●投稿本文中にAmazonのURLが書かれたとき、自動で極力短く加工する機能を追加（標準ではOFF）。
●全文検索の強調表示では、半角英字の大文字小文字が一致しなくても強調対象になるよう仕様改善。
●[PICT:/hogehoge/hoge.png] のように、スラッシュで始まる絶対パスで画像が指定されたときに、ファイルが見つからなければその旨をエラー表示するよう仕様改善。（従来は、何も表示されないimg要素が出力されていました。）
●[PICT:../../hogehoge/hoge.png] のように、上位ディレクトリを参照するパスで画像が指定されたときに、ファイルが見つからなければ注釈を含むエラーを表示するよう仕様改善。
●『画像パスに絶対URL(フルパス)を使う』がONで、「スラッシュで始まる絶対パス」で画像が指定されたとき、画像のURLがおかしくなって正しく画像が表示されない不具合を解消。
●読み込むjQueryをVer.3系(jquery-3.6.1.min.js)にアップグレード。
●デフォルトで読み込むLightboxを Ver 2.11.3 にバージョンアップ。（※従来はIE対策として、あえて 2.11.0 を読み込んでいました。）
●将来的に設定画面をカスタマイズできるようにするための布石として画面出力方法をちょっとだけ変更しました（見た目にはほとんど変わりありません）。
●サーバのエラーログに「CGI::param called in list context」のようなアラートが出力されるのを防ぐよう改善。(※引き続き出る場合は教えて下さい。)

《▼スキン更新》
●標準添付の各スキンを更新

•    head要素にあるRSS Auto-Descovery部分を [[RSS:AUTODISCOVERY]] に更新。
•    内側スキンの [[PARMAURL]] を [[PERMAURL]] に修正。
•    投稿日時の相対時間表示も各スキンに追加。
•    「最終更新日時」にも経過時間(相対時間)表記を追加。
•    キャプション付きの画像表示に対応。

《▼不具合修正》
●「続きを読む」機能を本文中に使っていながら、設定画面で「続きを読む」機能をOFFにすると、Internal Server Errorになる不具合を修正。
●「skin=」パラメータでスキンが指定されているとき、投稿本文内のハッシュタグをすべて抜き出す記法 [[COMMENT:TAGS]] が動作しない不具合を解消。
●ハッシュタグに半角アンダーバー「_」を使うと、投稿欄下部の既存ハッシュタグ簡単入力用プルダウンメニューでは角括弧付きでリストアップされる不具合を修正。
●内側スキンで [[CATEGORYLINKS:FULL]] と書いても、カテゴリページへのURLがフルパスでは出力されない不具合を解消。
●鍵付き投稿に含まれる画像が、記法 [[COMMENT:PICTS]] で抽出されるかどうかを、設定項目『n枚目の画像を [[ONEPICT:n]] 記法等で表示する』の設定値に従うよう修正。
●内側スキンに記述できる [[PARMAURL]] キーワードのスペルを [[PERMAURL]] でも認識するよう改善。┌(:3」└)┐ （※両方使用可能）
●スキンを簡易適用中のとき、[[PATH:SKINDIR]] でそのスキンのディレクトリが得られなかった不具合を修正。
●[[PATH:～]] 記法を複数書いたとき、出力HTMLが崩れてしまう可能性がある不具合を修正。
●比較的古いバージョンのPerlで実行すると、「Unrecognized escape \\v passed through at tegalog.cgi」というアラートがサーバのエラーログに記録される問題を解消。
●投稿単独ページのURLを挿入する [[PARMAURL]] のスペル修正版 [[PERMAURL]] を追加。(従来のスペルのままでも使用可能)
●設定画面のHTMLにいくつか存在していた文法ミスを修正。
●リンクラベルの中に &#35; での # 記号が入っていても正しくラベルとして使えるよう仕様を修正。( &#35; ではない # そのものが入っているとハッシュタグとして認識されてしまうので注意)
●「続きを読む」機能を入れ子にして使うと、ボタンラベルが正しく出力されないケースがある不具合を修正。(何階層にも入れ子にしても大丈夫なように改善)
畳む

20時間前に「Ver 3.8.8βとして公開する時点までの実装は全部できた」とNo.2335で書いたがそれは嘘で、今ようやく全部できた。_(┐｢ε:)_
細かい調整を忘れていたり後から気付いたりしたので。

カレンダーの生成もキャッシュしておきたい。

Ver 3.8.8βとして公開する時点までの実装は全部できた。あとはβ版用の解説を書けば公開できる。

画像管理画面で「一覧外」のフラグが設定されていれば、その画像の出力時に class="nolisted" を（画像そのものの）img要素と、（画像をリンクにする場合にはその）a要素に加えて出力するようにもした。これで、画像インデックス関連機能の初回機能としては概ね実装完了したのではないか……？
あと、スキンのCSSにfigure要素関連の装飾を加えておく必要はあるが。特にギャラリーモードでは、figure要素にデフォルトで付加される余白を消すような装飾がないとちょっと困りそうだ。

画像表示時に、画像管理画面で登録されているキャプションを出力できる機能も（ざっくりは）実装できた気がする。画像サイズが手動指定されている場合とか、一覧外フラグが立っている場合に付与するclass名とかの処理はまだこれからだが。

画像インデックスで「一覧外」フラグが立っていたら、新着画像リストに表示しない処理ができた！

しまった。サムネイル画像の存在の有無も画像インデックスに最初から含めるように実装すべきだったかもしれない。将来的にはそうするつもりだったが、最初の段階ではそこは飛ばしてシンプルに実装しよう、と思っていたのだが。よく考えると、画像インデックスにその情報がない場合、実際に画像を表示する段階で毎回サムネイルの存在をチェックしないといけないので効率が悪い。動作の効率ではなく（※動作としては現状と同じなのだから現状より悪くはなっていない）開発の効率が。 実際にソースを見て考えたら、そうでもなさそうだと分かった。┌(:3」└)┐

20日までに次のβ版を公開したいと思っていたが無理っぽいな。なんとか24日までには公開したいが。どちらにしても、年内の正式版リリースはちょっと難しそうな気がする。ただ、1月は仕事が忙しくなる可能性があるので、できれば年内にリリースしたいのだがががががが。

画像インデックスXMLは、画像保存用ディレクトリにただ1つ作成されるだけなのだが、これを将来的に拡張するとしたら2通りの方向性がありそうな気がする。
➊画像インデックスは単一のままで、他ディレクトリに存在する画像も収録できるようにする方向。
➋ディレクトリごとに画像インデックスを1つずつ生成して、複数の画像インデックスを扱えるようにする方向。
どちらの方向でも対処しやすいような感じを（なんとなく）考えてコードを書いたような気がしているのだが、もしかしたら「どちらを採用するにしても中途半端」な感じになっている可能性もある。まあ、その辺はもっと先の話だ。とりあえず、今の「画像保存用ディレクトリに画像インデックス1つ」の状態で正しく動作するようにするのが先で。

画像インデックスの読み書き関連処理は全部実装できた気がする。ディレクトリ内の画像数がめちゃくちゃ多い場合に、重たくならずに処理できるのかどうか。

てがろぐでは、たとえエラーメッセージ用のページを表示する場合でも、HTTPステータスコードはすべて 200 を返している。エラーメッセージを表示するなら 500 とか（存在しない投稿番号を表示しようとされたら 404 とか）を返した方が良いのかもしれないが、そういうのを返すと、サーバ側で独自のエラーページが作られている場合に、てがろぐ側のエラーメッセージが見えなくなってしまうので望ましくない。そう考えると、やはり全部 200 を返すしかない気がする。もうちょっと何か「Webページとしては正しく表示できるが、内容はプログラム側からのエラーメッセージを伝えている」みたいなことを示すHTTPステータスコードが用意されても良いのではないか。……というか、そういうのは（Webページとしては正しく表示できるのだから）200 で良い、ということなのか。Webとして出力できないからこそ、代わりにコードを返しているのだものな……。

年内に Ver 3.9.0 をリリースしようと思うと、ドキュメントを書くのに1週間は必要な点も考慮しておかないといけないのを忘れないように……。今回もたくさん書かないといけないから……。

画像を投稿する際、画像管理画面からなら(新規UPと同時に)キャプションとかフラグとかも設定できるようになった。

投稿本文と同時に画像をUPする場合でも、「下書き」か「鍵付き」で送信された場合には、同時にUPされる画像は「一覧外」フラグを立てた状態にはなる。キャプションは設定できないので、キャプションが事前に欲しい場合は、画像管理画面から先に画像だけをUPしておく必要がある。今のところは。投稿フォームに画像のキャプションまで設定できるようなUIを加えると、投稿UIのソースが大きくなってあまり望ましくない気がしているので、今のところは「キャプションを設定したければ画像管理画面から」という仕様でいくつもりでいる。（よほど要望があればまた考える。）

あと、「誰が画像をUPしたのか」の情報も独立して管理できるようになったので、画像ファイル名に「-admin」とかIDを加える必要がなくなった。そうすると、デフォルトの画像ファイル名規則「YYYYMMDDhhmmss-(ユーザID)」も必要なくなるのでどうするか。そのうち考えよう。