にしし らぼらとりー

今、開発中の画像等ファイル展示PHP >>2477 だが、掲載順序をパラメータで指定できるようにした。デフォルトではタイムスタンプの新しい順に並ぶが、パラメータに

• ?sort=time&order=reverse が指定されたら、タイムスタンプの古い順でソートして並べる。
• ?sort=cap が指定されたら、キャプション文字を昇順(ABC…)でソートして並べる。
• ?sort=cap&order=reverse が指定されたら、キャプション文字を降順(ZYX…)でソートして並べる。
• ?sort=size が指定されたら、ファイルサイズの大きい順にソートして並べる。
• ?sort=size&order=reverse が指定されたら、ファイルサイズの小さい順にソートして並べる。
• ?sort=name が指定されたら、ファイル名を昇順(ABC…)でソートして並べる。
• ?sort=name&order=reverse が指定されたら、ファイル名を降順(ZYX…)でソートして並べる。

……というような感じの指定ができる。

ファイル名やキャプション文字を使ってソートすることもできるので、事実上、自分の好きな順序で画像を並べて掲載することもできるだろう。ファイル名やキャプション文字を工夫すれば。（登録できる情報なら何でもソートキーに使えるようにするつもりなので、キャプション以外にコメント等も登録可能になれば、そのコメントの文字を使ってソートすることもできる。ただ、最初のリリース時点でそこまで作るかどうかは今の時点ではまだ分からない。）

ソートに使うキーをパラメータで指定できるので、複数の並べ方を共存させられる点が、何かちょっとメリットになりそうな気がする。「標準では新着画像の順に並ぶ」が、別途「ファイル名順に並べるリンクも設けておいて、望みの順序で表示するモードとして使う」とか。

主に画像を並べる用途を想定しているが、画像・動画・その他のファイルを並べることもできる。サブディレクトリの存在も認識するので、ファイラーっぽい感じの表示もできるハズ。（サブディレクトリへのリンクは、画像等と並べて同時に表示することもできるし、表示しないでおくこともできる。設定次第で。）

キャプション等を保持するデータファイルは、てがろぐCGIの画像インデックスファイル(index.xml)と互換性を持たせたので、てがろぐCGIの画像保存用ディレクトリを表示対象に設定して、てがろぐと組み合わせて使うこともできるような気がする。たぶん。

このツール上でファイルをアップロードすることもできるが（※まだそこまでは作れていないのだが）、FTP等の別手段でUPされたファイルもすべて認識する。キャプション等の情報はWeb上で1つ1つ登録することもできるが、データファイルはXMLなので、（FTPで一気に大量UPしたファイル群に対するキャプションは）XMLファイルを直接編集すると一気に登録できて楽かもしれない。

画像周りの機能をもうちょっと整理した方が良さそうだな……。まず、サムネイル画像をてがろぐ上から登録できる機能を作って、画像インデックスで正確に管理する仕様にする方が良いか。そうしないと、元画像を表示するのか、サムネイルを表示するのかを選択する場面が増えれば増えるほど、ソースコードを読み解きにくくなって困りそうだ。

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

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; ではない # そのものが入っているとハッシュタグとして認識されてしまうので注意)
●「続きを読む」機能を入れ子にして使うと、ボタンラベルが正しく出力されないケースがある不具合を修正。(何階層にも入れ子にしても大丈夫なように改善)

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

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

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

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

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

画像インデックスXMLの(リリース初期時点での)仕様はfixした。画像管理画面に反映する機能もできた。

あとは、画像ごとに詳細情報(キャプションとかフラグとか)を設定できる画面を作って、キャプション付き画像を掲載できる記法 [PICT:FIG:画像ファイル名] を実装して、画像ごとに設定されたフラグの情報を新着画像リストの表示/非表示に反映する機能を作ったら、とりあえず一応最低限の画像インデックス関連機能は出来上がりそうな気がしている。画像には、ネタバレカバーを加える需要があるっぽいので、できればフラグにはもう1つ「NSFW」(Not Safe For Work)も加えて、class名に活用できるような機能も加えたい気がしている……が、最初から盛るとトラブルシューティングが難しくなるし、企画倒れになる可能性が高まってしまうので、まずは最小限のところから順にリリースしていきたい。

とりあえず、画像インデックスが存在しないときに、画像保存用ディレクトリから画像一覧を読んで画像インデックスXMLファイルを新規に作成する機能はできた。次に、画像管理画面から各種情報を登録できるようにする必要がある。

あのAIに頼んだら、画像インデックス生成機能のソースも書いてくれるのでは。┌(:3」└)┐

画像インデックス生成機能の前に、もう1回β版を出すか……。以前の予定ではこの11月に画像インデックス生成機能を作るつもりだった気がするのだが。いつの間にか11月の残りが1週間を切っていた。なんでや……。

てがろぐの利用者がずいぶん増えてきた気がするので、画像インデックス生成機能よりも先に、セキュリティ関連機能の方を実装した方が良いかもしれない気もしつつある。当初の予定はそうだった（ような気がする）。

なんか、画像インデックス生成機能を作り始める前に、いろいろ解決しないといけない問題が出てきたような気がする。大きな機能の実装を開始してしまうと、それ以外の部分の細かな修正ができなくなるので、細かな修正を済ませてから実装に入りたいのだがががががが。

そもそも、次に実装する予定の（画像キャプションとかをあらかじめ登録しておけるようにするための）画像インデックス生成機能を本当に作れるのか、という気もする。なんかもうちょっと機能(仕様)候補を列挙して、欲しいか欲しくないか、その仕様で良いか良くないか、みたいなのをアンケート取ってから計画した方が良いのかもしれないな、という気もしないでもない。

画像インデックス生成機能（※これがあると、「画像の代替文字やキャプションを事前に登録しておける」・「新着画像リストに鍵付き投稿で使った画像が表示されないようフラグで除外できる」等の利点が得られる）は、Ver 3.0.0 でカテゴリ登録機能を実装したとき並に計画して取りかからないと実現しなさそうだ。まず計画。

画像インデックスを生成することそのものはまあ良いのだが、それを使って画像管理画面を作ろうとすると、画像管理画面での画像一覧生成処理をかなーり大きく書き換えないといけないことが分かった。これは……、大変だ。この実装をしようと思ったら、クッキーとチョコレートがめちゃくちゃたくさん要る。あと、それらをたくさん食べても太らない身体が……。_(:3」∠)_

画像インデックス生成機能を作ってキャプションとかを登録できるようにする前に、No.2211の「./mini/ディレクトリに同名画像ファイルがあったらサムネイルだとみなす」機能の方を先に作った方がいいか……？（なんとなく、そんな気がしてきた。ちょっとだけ。）

画像保存用ディレクトリに自動生成する index.xml（画像インデックス）は、とりあえず初回実装時の仕様としてはだいたいこんな感じでどうか。
<tegalogimages>
   <image><date>2022/10/15 17:35:30</date><file>20221015173530-admin.png</file><user>admin</user><bytes>1286</bytes><size>800x600</size><flag>lock</flag><alt>代替文字</alt><cap>キャプション</cap></image>
   <image>～</image>
   <image>～</image>
　　　：　：　：
</tegalogimages>

• 代替文字(alt)とキャプション用文字列(cap)を別々に登録できる需要があるかどうかはよく分からないが、代替文字に指定したい文字列とキャプションとして見せたい文字列が同じとは限らないので、別にできる方が望ましそうな気はする。もっとも、今はそのキャプションを表示する機能がないので、キャプションの登録機能を用意するなら表示機能も同時に用意しないといけないが。登録機能の実装だけはしておいて、最初の公開時にはそこだけ無効(非表示)にしておいても良いかもしれない。
• 画像を一覧に表示して良いかどうかを知るため（とか、そのほか将来的に何らかの属性を保存するため）にフラグ(flag)も記録できるようにする。
• その画像自体の仕様として、縦横サイズ(size)とファイルサイズ(bytes)もここに記録しておけば、何度も再取得する必要がなくなる。ただ、ユーザがFTP等で画像を差し替えた場合に備えて、実際の表示に使う際の縦横サイズは、毎回取得する方が良い気はする。そう考えると、別にデータファイルに縦横サイズを記録する必要はないかもしれない（原寸サイズではなく手動指定したサイズで表示したい場合に、それを記録しておく仕様にしても良いかもしれないが）。ファイルサイズの方は、まあ記録しておけば合計サイズを計算するのが早くなるだろうから記録しておく意味はある気はする。
• 誰がUPしたのかのユーザID(user)を記録しておけば、ファイル名からユーザIDを抜き出さなくても良くなる（というか、ファイル名を自由にしてUPしている場合でもユーザを記録できる）。
• ファイル名(file)には、とりあえずファイル名だけを記録することを考えてはいるが、パスを加えることで他のディレクトリに存在する画像も扱えるようにしても良さそうな気がする。将来的に、画像保存用ディレクトリを複数用意できるようにすることを考えるなら特に。

そのほか、サムネイル画像の存在有無も記録できるようにしても良いかな……という気もするが、「./mini/サブディレクトリに同名のファイルがあればそれをサムネイルと見なす」みたいな仕様にするなら、別にそれは記録する必要はない気もする。あまり最初から盛ってしまうと企画倒れになる可能性が高いので、最初の段階ではシンプルにしておきたい。

デフォルトの画像ファイル名が「YYYYMMDDhhmmss-USERID」の形式なのは、このようなindexを一切設けず、ファイルのタイムスタンプすらも調べずに、ただファイル名を得るだけで「UP日時」と「UPユーザ」が分かるようにするお手軽仕様だったからだ。……が、もはやファイルの整列にはタイムスタンプを参照しているし、UPユーザもindexから分かるようになるなら、ファイル名をこの形式にする必要性が全くない。もっとTwitterとかでやっているような、短いランダムな文字列を生成して gPfKn4tsWI.png みたいな感じの意味のないファイル名にする方が良いだろうか？

たぶん、画像をカテゴリ分けする需要はあるのだろうな……。ただ、そこまで一気に実装するのは無理なので（※カテゴリを表す文字列を記録すること自体は簡単だが）、そこは先送りだ。データファイルにカテゴリを記録できなくても、UP先のサブディレクトリを選択できるようになればそれでカテゴリ分けの役割になるだろうけども。ただ、UP先のディレクトリを選択できるようにするのもそこそこ手間はかかりそうだが。

ユーザがFTP等の手段で手動UPした画像も漏れなく記録するために、画像管理画面にアクセスされた際には毎回ディレクトリを走査して、index.xmlに含まれていない画像を発見したらその都度追記する仕様にする必要がある。

少なくとも、altとcapは自動復元ができないのだから、このindex.xmlもバックアップディレクトリに自動バックアップするようにしておいた方が良いだろう。

てがろぐの画像投稿機能は元々オマケ機能的にしか考えていなかったので、何一つ管理していない。画像管理画面では投稿画像の一覧は出てくるが、その画面にアクセスした際に毎回ディレクトリ内のファイル一覧を取得して、日付の降順に並べているだけだ。なので、ファイルサイズも縦横サイズも（表示が必要になった時点で）その都度取得している。今のところそれで困ることはなさそうだが、画像数がとても多くなってくるともしかしたら何か不都合が出てくるだろうか？ 内部で画像インデックスみたいなファイルを用意して、そこに各画像の属性を記録しておけば、毎回ディレクトリを走査しなくても良いし、画像の属性を毎回取得しなくても済む。たぶん、その方が望ましいのだろうな……とは思っているのだが。画像をメインにUPする用途で使う場合、画像そのものもカテゴリ（ディレクトリ）分けできて検索できる方が望ましいのかもしれない。ただ、その辺の要望が来たことはないのだけども。