にしし らぼらとりー

自分がてがろぐを画像掲載用途には使っていないので、なかなか画像周りの良さげな仕様を思いつかない問題はある。画像に自由なclass名を付けたいという要望を昔々に受けたことがあって、それを元にもっと汎用的な「自由装飾記法」を作ったわけだが、ギャラリーモードのことは考慮していなかった。いや、ギャラリーモードでも（スキンの作り方は普通のスキンと同じなので）スキンの作り方次第ではあるのだけども。画像掲載用途に使っていて、「こんなことはできんのかー？」と思う場合には、私のところに届くように要望をお知らせ頂かないと（私自身が画像掲載用途に使っていないので）理想的な方向には行かない（行けない）気がする。要望はお気軽に。時々、ずいぶん前にツイートされた「こんな機能があったらいいのにな」的な要望の呟きを偶然目撃することがあるのだが、その度に「それ、私に、知らせてくれなきゃ……！」と思う。_(┐｢ε:)_

そういえば、Lightboxの最新バージョンは 2.11.3 だが、あえてCDNからLightboxの 2.11.0 を読み込んでいるのはIE対策だった。最新版でどうなるのか確認していないが、2.11.1 をIEで読み込んだときには何かおかしかったので（具体的に何がどうだったのかは忘れたが）。これはどうするかな……。別に 2.11.0 のままでも不都合はなさそうだけども。もはや、IEは気にしなくても良いだろうし、2.11.3 にしておこうか。 →した。#済

とりあえず、Ver 3.8.5β として配布しても良いかな……という感じのところまで来た気がする。

おおぅ。すごいバグを見つけた。あまりこのように操作する人は居ないとは思うが、
【前提】「続きを読む」記法を本文中に使っている状態で、
【操作】設定画面で「続きを読む」機能を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からのアクセスを拒否するだけなので、サーバ上にあるプログラムからはアクセスできるので拒否しても問題ない。）