にしし らぼらとりー

てがろぐ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でログインしている場合には、(ユーザ設定にある)自前のアイコンで表示される、とすると、管理者と不特定多数とをシステム的に区別もできて望ましそうな気もする。

cronが使えないレンタルサーバ向けに、疑似的なcronを提供するCGIを用意すると便利かもしれない。cronは指定した時刻に指定したプログラムを実行する機能だが、cronが使えない場合はその「指定した時刻」に自動実行させる手段がない。しかし、例えば「ダミー画像を表示してから、現在時刻を確認して、指定時刻が過ぎていたら指定プログラムを実行するCGI」みたいなのを用意しておけば、その画像をWebページに埋め込んでおくだけで、誰かのWebへのアクセスとかをトリガーにしてcronっぽい機能が実現できる。もちろん、滅多にアクセスがないようなWebサイトだったら難しいが。……もう既にありそうだな。その手のCGIは。

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

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

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

定期的にサーバ内の全ファイルをZIPに圧縮して自動でメール送信するプログラム(CGIやPHP)があれば良いのかもしれない。自動バックアップ。cronが使えるサーバなら本当に定期起動が可能だが、そうでなくても、適当なテキストなり画像なりを出力する機能を用意しておいて、それをトップページとかに埋め込んでおけば、誰かがアクセスしたときをトリガーにして起動はできるので、前回からの経過日数を計算して処理するようなことはできるだろう。

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

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

スキン式のメッセージ送信システムをPHPで作りたい。メール送信フォームをスキンで用意できるもの。スキンを複数用意しておけば、複数箇所のメッセージ送信を1つのPHPで扱えるような。入力欄の個数とかもスキン側で自由にできるので単なるメール送信フォーム以外にもコンタクトフォームとかアンケートフォームとかにも使えなくもない感じの。メール不達に備えて一定期間はメッセージ本文を管理画面から再確認できる機能もあると良い。

てがろぐを(不特定多数が利用できる)掲示板的に活用したいとすると、少なくとも「名前」の任意入力欄が要る。しかし、そういう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日時）を出力できる記法って要る？