にしし らぼらとりー

おおぅ。すごいバグを見つけた。あまりこのように操作する人は居ないとは思うが、
【前提】「続きを読む」記法を本文中に使っている状態で、
【操作】設定画面で「続きを読む」機能をOFFにすると、
Internal Server Errorになる不具合を見つけた。しかも、一度この状態になると、設定画面から再度「続きを読む」機能を有効にしようとしても、保存時に(保存処理が実行されるより前に) Internal Server Errorになる。ので、一度この状態になったら、データファイル tegalog.ini を直接修正しない限り復帰できない気がする。
どひー！😱
試さないでね……。

原因は究明したのでローカルのソースは修正した。なお、たぶん比較的新しいバージョンでしかこの問題は発生しない。
これ、自分で見つけたから良かったが、ユーザさんからこの現象を指摘されても原因を突き止めるのは難しいだろうなあ。

「IE8対策」なる注釈の入ったコードが残っていて驚いた。消した。

構成ファイル数がめちゃくちゃ多いCMS（例えばWordPressとかMovableTypeとかもそう）をアップロードするときには、ZIPのままアップロードして、サーバにSSHでログインしてunzipコマンドを打って展開する、みたいなことはする。よく考えたら、別に構成ファイル数が少ない場合でもその方法を採って悪いわけではない。てがろぐをZIPのままアップロードして、unzipコマンドを実行するシェルスクリプトも一緒にアップロードして、それを実行する……みたいな手もある気はする。ただ、シェルスクリプトはパーミッションを設定しないと動かないだろうけど。PHPの方が良いか。

たぶん、ファイルをアップロードするとデフォルトでファイルのパーミッションは 604 か 644 になっていると思うので、パーミッション設定指示の 644 (604) というのは「デフォルトのままで何もしなくて良い」と考えて問題ないと思う。特に、suEXEC採用サーバの場合は、tegalog.cgi を 700 にしさえすれば、あとは全部デフォルトのままでも問題ない気もする。というか、suEXECが採用されているサーバで 600 と 604 に違いがあるのかどうかがよく分からん。600 というと、そのファイルにブラウザでアクセスしたら Forbidden になってくれそうな気がするのだが(suEXECだと)そういうわけではなさそうだし。見えたら困るファイルはセッション情報(psif.cgi)で、これは見えなくするために拡張子を .cgi にしてあるので、パーミッションが見えるような値になっていても特に問題はないが。一番確実に安全なのは、Webからアクセスできないディレクトリに置くことだとは思うけども。そこまでしなくても、念のために .htaccess とかを使ってアクセスを拒否しておくとなお安心かもしれない。（.htaccessでのアクセス拒否は、Webからのアクセスを拒否するだけなので、サーバ上にあるプログラムからはアクセスできるので拒否しても問題ない。）

リンク文字列の中に半角角括弧 [ ] が含まれているとリンクにならない仕様をどうにかしたい。ただ、] が登場した時点でそこが「リンクラベルの終わり」だと認識する仕様なので、どうしようもない気もしないでもないが……。単純に考えれば、「\」でエスケープすれば良い仕様にすれば良い気もするけども。エスケープする手間を考えれば、[ ] を消す手間と大した違いがないので、そこまで必要かな……？ という気もする。

画像投稿関連の機能についてだけを言うと、まず「サムネイル用画像があったらサムネイル側を先に表示する」機能は既に実装したので次のバージョンで提供できる。(※注意：サムネイル画像は自動生成ではないので、自らサムネイル用画像を作る必要がある。ただその点はむしろ『自分の納得のいく画質のサムネイルにできる』とか『自分が望む通りのトリミングができる』とか『クッション用画像に差し替えられる』とか、自動生成ではないことのメリットもあるとは思うので、必ずしもデメリット（機能不足）だとは考えていない。）

ただ、現状ではサムネイル画像をアップロードする機能がないので、FTP等の別手段が必要だ。それで良いと思っているわけではないので、将来的には「サムネイル用ディレクトリに画像をUPする機能」も作る予定ではいる。
そのほか、

●画像キャプションをあらかじめ登録しておける機能（＝画像情報のみを記録する index.xml の生成）
●画像単体に「鍵付き」のフラグを登録しておける機能（＝新着画像リストに出すか出さないかを選べる機能）（※上の index.xml での管理機能が先に必要）
●画像をimg要素だけでなく、figure要素＋img要素＋figcaption要素を使って『キャプション付き』でも出力できる機能
●画像のファイル名をもうちょっと自由にできる機能（※先の index.xml での管理機能が先に必要）
●画像のUP先サブディレクトリを選べる機能か、もしくは画像をカテゴリ分けできる機能（※先の index.xml での管理機能が先に必要）
●画像管理画面で、既にUPしてある画像のファイル名（やキャプション等の情報）で画像検索できる機能
●OG:image用の画像を「本文のテキスト」で動的に生成したい場合（＝テキストの画像化ツールへ本文の冒頭文字列を送りたい場合）のために、本文テキストを任意のパラメータ付きでog:imageに加えられる機能

……のようなToDoリストっぽいものがある。
上の方は「計画」だが、下の方は「なんとなくの予定」みたいな感じで、下の方へ行くほど需要を感じなければどんどん先送りする感じである。
どれも一気には提供できないので、1つずつ作ることになる。なぜ一気に提供できないかというと、理由は主に2つある。

➊ 一気に複数の機能を実装すると、もしトラブルが起きたときの原因究明が難しくなるのでその後の開発が行き詰まる。
➋ あれもこれもと盛りすぎると、モチベーションの維持が難しくなって企画倒れになる危険性がとても高くなる。

1も重要だが、何よりも2の方が極めて重大な実際の問題である。過去20年くらい、『作りかけたまま放置して未完成のまま日の目を見ることのなかったフリーソフトやフリーCGI』が多々あるが、そのどれもが「機能を盛りすぎて完成までのモチベーションが維持できなかった」のが最大の原因なので。仕事ではない以上、モチベーション(開発意欲)が失われたらそこで終わりである。
なので、「機能はほんの少しずつ加えて、ちょくちょく公開する」という方策を採るのが鉄則だ。

いま直面している問題が、「画像情報のみを記録する index.xml の生成」機能がわりと大きな改造を必要とするので、「機能はほんの少しずつ加えて、ちょくちょく公開する」という方策を採りようがないことなのよな……。どうするかねえ……。

管理画面の「設定」ページを生成するソースをリファクタリングしている。ブラウザ上での見た目は一切変わらないのだが、後々カスタマイズしやすくなるような気がする。なんとなく。ただ、具体的な計画がない段階でのリファクタリングは、もしかしたら不毛なのでは……という気もしないでもないのだけども……。まあ、プログラムサイズ（ソース分量）がいくらか減るメリットはある。