2022年11月の投稿［57件］ - 開発放言

スキンを容易にカスタマイズできるようにする1つの方法として、配色とかを全部CSS変数（カスタムプロパティ）にする、というのがある。とても便利なのだが標準添付の各スキンでは採用していない。なぜかというと、IEでは使えなかったからだ。2017年当時だと、Edgeでも微妙だったし、最新版にアップデートしていない各ブラウザだと使えなかったりもした。なので少数のユーザも排除したくないと考えると、「まだ使えない」と判断するしかなかった（いや、全部のスキンを2017年に作ったわけではないが）。しかし、もはやMicrosoftもIEのサポートを終えたわけだし、全部変数に置き換えていくと良いのではないか……とは思うのだが、いまさら全部を書き換えるのが大変だ。

by nishishi. ⌚ 2022年11月30日(水) 23:06:15〈178日前〉てがろぐ＜324文字＞編集

にしし

No.2306

てがろぐ開発ロードマップを書いておきたい。ローカルの書き殴ったメモはあるが（手書きではない）、そうではなくて、なんかちょっと公開して整頓した方が良い気がしている。

by nishishi. ⌚ 2022年11月30日(水) 14:39:43〈179日前〉てがろぐ＜81文字＞編集

にしし

No.2305

開発方針というか、優先順位の決め方の話ですけども。

今の時代、「JavaScriptが動作しない閲覧環境」というのはまずないでしょうし、考慮する必要性はほとんどないと考えて差し支えないでしょう。また、少なくともGoogleは「JavaScriptを実行した結果」を解釈してくれるようなので（SEO効果の度合いには違いがあるかもしれませんが）検索対策を考える場合でもJavaScriptでページを描画して大きな問題はなさそうに思います。

ただ、

RSSフィードのようなXML形式のデータ内ではJavaScriptは使えない
OGPのような「HTML内にmeta要素として静的に存在していないと認識されない物」はJavaScriptで生成・編集できない

というような問題もありますから、「ブラウザ上の描画に関してはJavaScriptを使えば実現できる」ということでも、「できるだけ本体側にもその機能がある方が望ましい」とは言えると思います。

例えば、

RSSフィード内の何かをJavaScriptで変更したり生成したりしたいと思っても（書かれていれば動くRSSリーダももしかしたらあるかもしれませんが）RSSフィード自体は静的なXMLとして存在しているだけなので無理ですし、
OGPを読んで利用するSNS等は（たぶん）HTMLファイルを読むだけでその先のJavaScriptまで読んで実行はしてくれないようですから、JavaScriptでOGPを生成したり編集したりしても効果がありません。

これらのような箇所の出力をどうにかしたい場合は、CGI側でその機能を用意するほかありません。
したがって、「ブラウザ上ではJavaScriptで実現できる機能でも、もしかしたら静的に存在していないと効果がないような箇所で出力したいケースもあるかも知れないので(将来的には)本体側にも実装する方が望ましい」とは考えています。

しかしながら、

「JavaScriptを使えば（ブラウザの描画上では）実現できること」と、
「JavaScriptを使っても（おそらく）実現できないこと」

とがありますから、（この両者を比較すれば）開発を優先するのは後者だと思います。
もちろん実際には「開発のしやすさ」も大きく影響しますから、絶対に後者が優先されるわけではありませんけども。

なので、「JavaScriptで実現できる機能は、（将来的には実装したいと思うものの）開発優先度はそこまで高くならない」と認識しておいて頂けるとありがたい気がします（たぶん）。「気長に待って欲しい」というのは（何もかもを一気に実装するのは無理なので）常に言っていることですが、なお「さらに気長に」待って頂けるとありがたい感じです。

by nishishi. ⌚ 2022年11月29日(火) 16:55:55〈180日前〉＜1160文字＞編集

にしし

No.2304

Ver 3.8.2β以降に存在している、ちょっとマズいバグを発見したので修正する。普通に使っている状況ではまず問題は起きないだろうけども。

by nishishi. ⌚ 2022年11月29日(火) 00:06:13〈180日前〉てがろぐ＜69文字＞編集

にしし

No.2303

投稿日時を「xx日前」みたいな相対時間で表示する機能は、日付から閏年を計算して単位を切り替える配慮が面倒なので、「365.25日を過ぎたら年で表示する」という実装にしてあるのだが、これで問題ないよな……？閏年は4年に1回なのだから。ちょうど1年前の投稿の場合、「365日前」と表示される場合と「1年前」と表示される場合とがある。年単位は、「年」ではなく「年以上」にしておく方が良いか。「1年と0日前～1年と365.25日前」まで全部を「1年前」と表示するのはちょっとおかしい気もする。「1年以上前」、「2年以上前」……なら良さそう？

by nishishi. ⌚ 2022年11月26日(土) 13:17:18〈183日前〉てがろぐ＜267文字＞編集

にしし

No.2302

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

by nishishi. ⌚ 2022年11月24日(木) 22:38:44〈184日前〉てがろぐ＜101文字＞編集

にしし

No.2301

レンタルサーバ別のセットアップ方法(15件)を加えたついでに、パーミッションの値の考え方も書いた。

まず、「suEXEC」の方の値に設定してみて下さい。それで動けばそのままお使い頂けます。
もし動かなかったり不都合がある場合は、次に「一般の場合」の 705 や 604 のように真ん中がゼロの値を設定してみて下さい。それで動けばそのままお使い頂けます。
それでも動かない場合は、「一般の場合」の 755 や 644 の方の値を設定してみて下さい。

これ、「3」でないと動作しないWebサーバって、果たして存在するだろうか……？グループ権限が動作に必要なケースってたぶん存在しないよな……？

「suEXECではない環境」のことの表現は「一般の場合」のままにした。良さげな表現を思いつかなかったので。いや、「その他の場合」でも良かったかもしれないが。「suEXEC対応／非対応」という表記も考えたが、なんか（初心者に）難しそうに感じられると困るなと思ったので。名称は「一般の場合」のままでも、上記のように詳しい考え方のステップを書いておけばまあ良いかなと。

by nishishi. ⌚ 2022年11月23日(水) 22:53:46〈185日前〉てがろぐ＜488文字＞編集

にしし

No.2300

……ということは、「suEXEC環境なのかそうでないのか判断が付かない」みたいなアンケート結果になっていたサーバは、『どっちの値でも問題なく動作する』サーバということなのか。もしかして。

by nishishi. ⌚ 2022年11月23日(水) 09:20:39〈186日前〉てがろぐ＜93文字＞編集

にしし

No.2299

WitchServerの環境についてはアンケート結果がばらけていて（700で動かしている人も居れば755で動かしている人も居るし、Perlパスを変更している人も居れば変更していない人も居る）判断できなかったので、WitchServerの運営者さんに問い合わせてみたところ、丁寧な返信が来た。
それによると、WitchServerはsuEXECを採用しているが、
「設置方法3：パーミッションの設定」の項目で提示されているパーミッションであれば、
suEXEC用、一般用、どちらでも動作します。
とのこと。
どちらでも動作する、という環境もあり得るのか……。知らなかった。CGIが新規ファイルを出力するディレクトリのパーミッションも、別に 705 でも 777 でも構わないようだ。
余計なパーミッションはない方が良いだろうという立場からsuEXEC用を推奨、とさせてください。
ということなので、案内としては「suEXEC側のパーミッションに設定」ということで問題なさそうだ。
Perlパスも書き換える必要はないとのことだった。
それよりも、改行コードを LF にして、バイナリモードでアップロードする点に注意して欲しいという回答だった。

WitchServerさんは、てがろぐセットアップTIPSページを公開して下さっていてたいへんありがたい。そこにパーミッションの話は書かれていないのだが、まさか「どっちでも問題ない」とは予想しなかった。

by nishishi. ⌚ 2022年11月23日(水) 09:19:06〈186日前〉てがろぐ＜623文字＞編集

にしし

No.2298

「指定したNo.を含む前後10件の投稿だけを一括で閲覧する」機能が欲しい。

by nishishi. ⌚ 2022年11月23日(水) 08:44:28〈186日前〉てがろぐ＜37文字＞編集

にしし

No.2297

ちょっとToDoリストを書き直して（再構築して）優先度別にしっかりまとめ直さないと、何も進行できなさそうな感じになってきた。_(┐｢ε:)_

by nishishi. ⌚ 2022年11月22日(火) 22:31:46〈186日前〉てがろぐ＜70文字＞編集

にしし

No.2296

とりあえず、設置方法3：パーミッションの設定をちょっとだけ書き換えた。

細かく書いてはいるが、suEXEC対応サーバの場合は、tegalog.cgiさえ 700 にすれば、他はデフォルトのままでも特に問題はない。suEXEC非対応の場合は、書き込み権限を付与しないといけないファイルとディレクトリがちょっとあるので1つ1つ見て設定する必要がある。suEXECの方で 600 にするよう書いているのは、そうしないと動かないわけではなく、まあ余計な権限は付与しない方が良いよな、くらいの感じだ。skin-cover.html と skin-onelog.html もブラウザで直接閲覧するわけではないので 600 で良いのだが、まあ、これらはただのHTMLで害がないので「デフォルトのままで良かろう」みたいな感じで書いている。

by nishishi. ⌚ 2022年11月22日(火) 00:00:09〈187日前〉てがろぐ＜362文字＞編集

にしし

No.2295

うーむ。スターサーバーでのセットアップ案内をどうすべきかが分からん。てがろぐユーザアンケートの結果 >>2288 では、回答者9名のうち「suEXEC側の設定者3名」「非suEXEC側の設定者6名」なのだが、スターサーバーの公式マニュアルでパーミッションの記載部分を読むと、実行するCGIは「705」か「755」にしろと書いてある。公式にはsuEXEC対応とは書かれていないし、705等を推奨していることからしてsuEXECではないのだろうけども。しかし、アンケートでは 700 でも動作しているようだから、要するに 700 でも 705 でも 755 でも動くのか。まあ、それは別に構わないが、ディレクトリのパーミッションが 705 でも 706 でも書き込めるのはどういうわけなのだろうか？ suEXEC採用なら 705 で書き込めるのは分かるが、もしsuEXEC非対応なら 705 なディレクトリにはファイルは書き込めない気がするのだが。

あと今更だが、suEXEC非対応な環境での（任意のファイルを書き込む）サブディレクトリのパーミッションって 706（766）ではなくて、707（777）でなくて大丈夫なのだろうか……。ディレクトリに実行権がなくても読み書きはできるが、実行権がないとファイルの属性とかが取得できなさそうっぽい情報●◆を読んだのだが。（まあ、ファイルの属性が取得できなくても、日付順にソートできなかったり、ファイルサイズが得られなかったりするだけで、大きな問題にはならなさそうだけども。でも、細かくは問題があるので、やはり 707 か 777 にしてもらわないといけなさそうだ。）

公式が、suEXEC対応とか非対応とか情報を公開してくれていると確実で助かるのだがな……。
対応していないことをわざわざ書くケースはあまりなさそうな気がするが、SPPDでは公式に「いわゆるsuExec機能は有しておりませんので」という解説があって分かりやすかった。
なお、アンケートに回答して下さったエックスサーバーの利用者さんはみな（と言っても2名だが）755等に設定されていたので、エックスサーバーはsuEXEC非対応なのかと思ったが、ググってみたら「はい、対応しております。」というFAQがあった。ディレクトリのパーミッションを 766（706）にしても、画像はちゃんと表示されているだろうか……？ suEXEC対応サーバでディレクトリのパーミッションを 706 とか 766 とかにしてしまうと、プログラム側からの読み書きはできても、ブラウザ上で画像等のファイルが一切参照できなくなってしまうと思うのだが。（画像をUPしない運用だったら問題に気付けないけども。）suEXECが採用されていても、その辺の仕様もサーバの設定によって違うのだろうか？というか、OSの仕様が異なる可能性もあるか。

by nishishi. ⌚ 2022年11月21日(月) 23:21:07〈187日前〉てがろぐ＜1206文字＞編集

にしし

No.2294

他の階層（上位のディレクトリとか）に存在するスキンでもプレビューしたり簡易本番適用したりできるようにした。プレビューの場合は skin パラメータに相対パスや絶対パスでスキンの位置を指定すれば良い。管理画面の「スキン切り替え」でも、ディレクトリを直接手動入力して、プレビューしたり簡易適用したりできる機能を加えた。てがろぐを複数個設置して併用しているとき、同じスキンを使いたいなら1カ所にあるスキンを共用できる方がカスタマイズが楽かもしれないから。 >>2276

by nishishi. ⌚ 2022年11月20日(日) 19:15:51〈188日前〉てがろぐ＜231文字＞編集

にしし

No.2293

設定に『サムネイル画像があればサムネイルの方を表示』というチェックボックスがあるけど、ONでもOFFでも、問答無用でサムネイルの存在を確認に行っていた。(爆) 設定値を使ってねえ。 #済修正した。

by nishishi. ⌚ 2022年11月20日(日) 11:29:23〈189日前〉てがろぐ＜99文字＞編集

にしし

No.2292

隠されている範囲に含まれている文字数を、「続きを読む」ボタンラベル内に表示できるようにしようかな……？

by nishishi. ⌚ 2022年11月19日(土) 22:53:45〈189日前〉てがろぐ＜51文字＞編集

にしし

No.2291

問題の箇所を特定するためにテストしないといけないのだが、面倒くさい……。_(┐｢ε:)_

by nishishi. ⌚ 2022年11月19日(土) 14:37:19〈190日前〉てがろぐ＜44文字＞編集

にしし

No.2290

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

by nishishi. ⌚ 2022年11月18日(金) 23:12:10〈190日前〉てがろぐ＜99文字＞編集

にしし

No.2289

「suEXECで使えている人が居る」場合には「suEXEC」だと案内した上で、補足的にsuEXECではない方のパーミッションで動いている人も居るので、もしうまくいかなかったら云々……みたいに書いておけば良いか。

by nishishi. ⌚ 2022年11月18日(金) 22:00:57〈190日前〉てがろぐ＜105文字＞編集

にしし

No.2288

うーむ。アンケートを採れば、たちどころに各サーバの状況が判明するに違いない！ ……みたいに考えていたのだが、そうも言えない結果が出てきて、どうしたものか。
リトルサーバー（回答者13名）、スターサーバー（回答者9名）、XREA（回答者4名）で、決断しにくい感じに報告が割れている……。

■リトルサーバー13名（ミニプラン5名、ワードプラン5名、リトルプラン2名、ライトという回答1名）のうち、パーミッションの設定は、
●suEXEC（700等）が 5名
●一般（755等）が 5名（内1名はサポートに依頼したら755になったと）
●パーミッションの設定記憶がない 2名
※残りの1名は「suEXECのでは動かなかった」で 705にしたとのことだが、この方は「WordPress配下のディレクトリに置いた」とのことなので、その辺の問題があったっぽい。
suEXECと一般とで見事に半々なので、実際のところどうなのかの判断がしにくい。suEXECで動いている人がいるのだから、suEXECで良いとは思うけども。

■スターサーバー 9名（エコノミー2名、ライト1名、ハイスピード2名、無料サーバ4名）のうち、パーミッションの設定は、
●suEXEC（700等）が 3名
●一般（755等）が 5名
●一般（705等）が 1名
多数決だと「一般」になるけども、まあ「suEXECでいけている」ならsuEXECということで良いんだと思うのだが。たぶん。無料サーバ（スタードメインに付いてくる無料サーバ）の4名に限っても、755が2名、705が1名、700が1名で割れている。どれでもいけるのか……？（プログラムはどっちでも良いとしても、画像保存用ディレクトリのパーミッションは「どっちでも良い」ということはないのではないかと思うのだけども。どうだろう？）

■XREA 4名（フリー 4名）のうち、パーミッションの設定は、
●suEXEC（700等）が 2名
●一般（755等）が 2名
4人居て、見事に半々。
内1名は、$howtogetpath の値が 1 でないとダメだったとの報告。（残りは変更なし）

まあ、「suEXECで動かせている」という回答が存在するなら「suEXECということにする」という決断で良いと思ってはいるのだけども、リトルサーバーの報告が迷う。自由入力欄に「サポートに依頼したら755になった」という感じのことが書いてあった点で。プランとか収容サーバによって仕様が異なる可能性もあるかもしれない。

あと、新規にセットアップする場合、とりあえずWordPressの配下にあるディレクトリは避けてくれ、という話も書いておいた方が良いかもしれない。WordPressの配下にあるディレクトリで動かせないわけではないと思うが、何の工夫もなくそのままアップロードしたのではダメっぽいから。

mixhostは、$howtogetpath を 0 に変えないといけない点では確定みたいな結果だった。

by nishishi. ⌚ 2022年11月18日(金) 21:43:55〈190日前〉てがろぐ＜1257文字＞編集

にしし

No.2287

てがろぐの設定のバックアップは、データファイルと同様にbackupディレクトリに自動出力するよりも、ファイルとして（ローカルに）エクスポートできる機能の方が便利かもしれない。インポート機能もあるとなお良さそう。インポート機能があれば、単にバックアップの復元だけでなくて、スキンに合わせた設定の上書き用途にも使えるかもしれない。いや、全項目を一括して上書きする仕様だったら（バックアップならそれで充分だ）使えないけども。

by nishishi. ⌚ 2022年11月18日(金) 17:11:53〈191日前〉てがろぐ＜209文字＞編集

にしし

No.2285

$howtogetpath変数って、「滅多に使われるケースはないだろうけども念のために用意しておくか」みたいな感じで用意しておいたのだが、そこそこ使われている（使わないとうまく動かない）みたいなことになっているような気がしてきた。

by nishishi. ⌚ 2022年11月17日(木) 22:16:23〈191日前〉てがろぐ＜115文字＞編集

にしし

No.2284

まじか……。私が契約しているさくらインターネットのサーバだと、既定のドキュメントルート用ディレクトリ以外をドキュメントルートにしたドメインがあっても、ドキュメントルートは（そのドメイン用のルートが）正しく取得できているのだが、同じさくらインターネットのサーバでもそうではないサーバがあるのか……。（>>2279 , 試験場No.3245）

by nishishi. ⌚ 2022年11月17日(木) 22:07:43〈191日前〉てがろぐ＜169文字＞編集

にしし

No.2283

Perlがコアモジュール群からCGIモジュール(CGI.pm)を外したのは良いとしても（良くないが）、明確な1つの代わりを用意せずに外してしまうのは乱暴なのでは……。てがろぐのソースではCGIモジュールの機能はほんの一部しか使っていないので、CGIモジュールが不要なように書き換えることも可能ではあるのだが、面倒くさい。_(┐｢ε:)_ いや、最初の最初に「てがろぐVer.1」を開発しようとする段階で「CGIモジュールは使わない」と決めていたら、もうちょっとうまい感じにできたとは思うのだけども。もはやCGIモジュールが使えることを前提に山ほどソースを書いている今更修正するのは気力面でしんどい気がする。たぶん。tegalog.cgiの中だけでも429回使っているし……。

by nishishi. ⌚ 2022年11月17日(木) 21:29:40〈191日前〉てがろぐ＜337文字＞編集

にしし

No.2282

mixhostの新サーバにPerlモジュールがさっぱり入っていないのは、もはやフリーCGIとか使わせる気がないということなのだろうか。Perlは使えるし、Perlモジュールを自力でインストールする機能も提供されているので、Perl自体を拒否しているわけではないけども。「自作のPerlで何かをしたい人は自由にすれば良いが、一般公開されているフリーCGI的なものを使うことはもはや考慮していない」みたいな？とりあえず、mixhostの新サーバ向けの対策はFAQとかに書いておいた方が良さそうだ。

by nishishi. ⌚ 2022年11月17日(木) 13:51:34〈192日前〉＜247文字＞編集

にしし

No.2281

検索時とかカテゴリ別表示時とか個別投稿表示時とかにはナビ領域に「初期表示に戻る」テキストリンクが出るが、何の条件も限定されていない状況での「2ページ目」とか「3ページ目」とかには出ない。ページ番号リンクが表示されているのなら「1」を押せば最初に戻れるので構わないが、ページ番号リンクを表示しないスキンが使われていると1ページ目に戻る手段がない。『何の条件も限定されていない状況でも2ページ目以降なら最初に戻るリンクを表示する』みたいなオプションがあると良いかもしれない。もしくは、『<<最初 <前のxx件次のxx件> 最後>>』みたいな4段階の前後移動リンクが出力できる機能とか。

by nishishi. ⌚ 2022年11月17日(木) 12:16:56〈192日前〉てがろぐ＜291文字＞編集

にしし

No.2280

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

by nishishi. ⌚ 2022年11月15日(火) 23:28:42〈193日前〉てがろぐ＜123文字＞編集

にしし

No.2279

画像をWeb上に表示する場合、相対パスが使われていれば楽なのだが、絶対パスが使われている場合には、2種類のパス(PATH)を生成しないといけない問題がある。1つはWeb上のパスで、もう1つはサーバのファイルシステム内のパスだ。HTMLとして出力する際には前者のパスが必要だが、ファイルの実在を確認する場合には後者のパスが要る。相対パスだったらそれらの差を気にする必要がないのだが、絶対パスだと「/」が指し示す先が異なるので、両者を別々に扱う必要がある。具体的には、Webでの「/」が示しているディレクトリ（＝ドキュメントルート）がサーバのファイルシステム内ではどこなのかを突き止める必要がある。このドキュメントルートの取得は環境変数から取得しているのだが、あらゆるWebサーバで本当に正しいドキュメントルートが得られるのかどうか知る術がないのでやや困る。

by nishishi. ⌚ 2022年11月15日(火) 23:00:24〈193日前〉てがろぐ＜377文字＞編集

にしし

No.2278

16進数での色指定を本文に書くとハッシュタグとして認識されてしまう問題の回避方法は、5文字書く方法で良ければ存在はする。できれば、HTMLの色指定に該当する場合だけハッシュタグだとは認識しないようにできると良いのだが、それを正規表現1つで表現する方法が思いつかないので、実現できないでいる。果たして正規表現でそんな方法があるだろうか？『「 # で始まる文字列」ただし [a-fA-F0-9] が3文字または6文字続く場合だけは除く』みたいな。正規表現をめちゃくちゃ使いこなしている人だと編み出せるのかもしれないが……。

by nishishi. ⌚ 2022年11月15日(火) 21:27:08〈193日前〉てがろぐ＜259文字＞編集

にしし

No.2277

サーバのシェルにログインできるなら、シンボリックリンクを作れば複数のてがろぐで同じスキンを共有できるだろうけども。

by nishishi. ⌚ 2022年11月15日(火) 13:39:31〈194日前〉てがろぐ＜57文字＞編集

にしし

No.2276

てがろぐのスキンを ?skin=../upperdir/some/skin-dir みたいな感じで指定すると、セキュリティの都合上、CGIが存在しているディレクトリよりも上位(浅い)階層のディレクトリにあるファイルを参照することはできません。と拒否される仕様なのだが、この制限に意味あるかな……？この方法で、サーバ内の（何か漏れるとマズい）ファイルが参照されたところで、それはスキンとしては機能しないのだから「スキンがないよ」と表示されて終わりなので、特に問題ない気がする。

skinパラメータで、相対パスを使って上位ディレクトリを参照できれば、「複数のてがろぐで同じスキンを使う」ということができるので、てがろぐを複数個設置している場合でもデザインの共有が楽になりそうではないか。

……そうでもないか。skinパラメータだと、一時適用にしかならないものな……。#済 >>2294

by nishishi. ⌚ 2022年11月15日(火) 13:16:42〈194日前〉てがろぐ＜393文字＞編集

にしし

No.2275

「てがろぐ」と「さんごよみ」では、出力ページに埋め込まれる「Powered-by表記」と、管理画面TOP右端に見える「このCGIについて」枠はどちらも非表示にできる手段を（有償ライセンスの形で）用意している。しかし、管理画面の下端に小さく表示される Copyright表記を非表示にする方法は用意していない。後者は一般のアクセス者からは見えないので非表示にしたい需要は特にないと思っているのだが、あるのだろうか？（今までそれを希望されたことはない。）いや、あっても積極的に提供しようとはあまり思っていないのだが。一般のアクセス者からは見えないにもかかわらず「このCGIについて」枠を非表示にする機能を用意しているのは、ビジネス用途（Web製作会社が客先に提供するなど）の場合に、「作者にコーヒーをおごる」リンク等は見せたくないだろうからだ。

by nishishi. ⌚ 2022年11月14日(月) 23:19:12〈194日前〉＜371文字＞編集

にしし

No.2274

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

by nishishi. ⌚ 2022年11月13日(日) 23:31:02〈195日前〉てがろぐ＜171文字＞編集

にしし

No.2273

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

by nishishi. ⌚ 2022年11月13日(日) 23:22:36〈195日前〉てがろぐ＜397文字＞編集

にしし

No.2272

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

by nishishi. ⌚ 2022年11月13日(日) 00:14:29〈196日前〉＜231文字＞編集

にしし

No.2271

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

by nishishi. ⌚ 2022年11月12日(土) 23:51:35〈196日前〉てがろぐ＜49文字＞編集

にしし

No.2270

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

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

by nishishi. ⌚ 2022年11月12日(土) 22:43:02〈196日前〉てがろぐ＜402文字＞編集

にしし

No.2269

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

by nishishi. ⌚ 2022年11月12日(土) 20:21:55〈196日前〉＜32文字＞編集

にしし

No.2268

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

by nishishi. ⌚ 2022年11月12日(土) 19:10:53〈196日前〉＜286文字＞編集

にしし

No.2267

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

by nishishi. ⌚ 2022年11月12日(土) 18:16:59〈197日前〉てがろぐ＜587文字＞編集

にしし

No.2266

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

by nishishi. ⌚ 2022年11月11日(金) 13:21:16〈198日前〉てがろぐ＜201文字＞編集

にしし

No.2265

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

ただ、現状ではサムネイル画像をアップロードする機能がないので、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 の生成」機能がわりと大きな改造を必要とするので、「機能はほんの少しずつ加えて、ちょくちょく公開する」という方策を採りようがないことなのよな……。どうするかねえ……。

by nishishi. ⌚ 2022年11月11日(金) 12:34:18〈198日前〉てがろぐ＜1427文字＞編集

にしし

No.2264

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

by nishishi. ⌚ 2022年11月08日(火) 22:02:44〈200日前〉てがろぐ＜177文字＞編集

にしし

No.2263

管理画面の「設定」では、冒頭にショートカットリンクが掲載されているが、このショートカットリンクの横にチェックボックスを置いて、「チェックを外した項目は非表示になる」みたいな機能を用意しようか。で、その表示/非表示の選択状態はクエリ文字列（URLの?以降の文字列）に反映されるようにしておいて、「うちのスキンを使うときには、このURLで設定画面にアクセスすれば、余計な設定項目を見ずに済むよ」的なことにできるとか。自分用に取捨選択する場合は、選択後のURLをブックマークしておけば良い、とか。

by nishishi. ⌚ 2022年11月07日(月) 17:55:55〈202日前〉てがろぐ＜245文字＞編集

にしし

No.2262

もしサムネイル画像がアップロードされていたら、最初はサムネイル画像の方を表示しておいて、Lightboxではオリジナル画像を見せる機能の動作テスト ➡試験場No.3204
新着画像リストでも、サムネイルの方を表示するようにした。

by nishishi. ⌚ 2022年11月06日(日) 22:32:13〈202日前〉てがろぐ＜115文字＞編集

にしし

No.2261

「このまま書き進めたら、凄まじいスパゲッティソースになる……！」という確信が得られてしまって、どうするか悩む。┌(:3」└)┐

by nishishi. ⌚ 2022年11月06日(日) 22:02:18〈202日前〉＜63文字＞編集

にしし

No.2260

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

by nishishi. ⌚ 2022年11月06日(日) 21:43:11〈202日前〉てがろぐ＜211文字＞編集

にしし

No.2259

ハッシュタグの認識で、全角/半角の切り替わりをハッシュタグの終わりだと認識する仕様にしたのは悪手だったな……。半角角括弧で括れば何でもいけるのだが、その仕様に気付く人は滅多に居ない気はする。一応、セットアップ直後のデフォルト挨拶文の中にサンプルは書いてあるのだけども。

by nishishi. ⌚ 2022年11月06日(日) 21:12:14〈202日前〉てがろぐ＜134文字＞編集

にしし

No.2258

「miniディレクトリに同名画像ファイルがあったらサムネイルだとみなす」機能は、ほぼできた。画像保存用ディレクトリにminiサブディレクトリがある場合はもちろん、それ以外のディレクトリにある画像を表示する場合でも、その画像の位置にminiサブディレクトリがあればサムネイルの存在を認識できる。あと、新着画像リストで、サムネイル画像(がある場合にはその方)を表示する機能を作れば完成だ。たぶん。 >>2258,2256,2251,2211

by nishishi. ⌚ 2022年11月06日(日) 01:17:34〈203日前〉てがろぐ＜218文字＞編集

にしし

No.2257

昔から、FAQを構築できるCGIを作りたいと思うことが何度かあったのだが、てがろぐでFAQスキンみたいなのを作れば、検索もできるしカテゴリ分けもできるしそれで済むのではないか、という気もしてきた。ただ、FAQのHomeページをどうにかして生成する必要がある。FAQ用のHomeページというと「カテゴリ別にFAQタイトルが並ぶ」という形態が定番だし分かりやすいと思うので、そんな感じのHomeを自動生成できると望ましいのだが。現状の機能だと無理だ。いや、「カテゴリ別に新着タイトルを出力する」ことはできるので、それらをSSIとかで組み合わせて1つのページにするHTMLを用意すればHomeとして機能はするとは思うけども。それだと、カテゴリを追加したときに手動修正が必要になるので運用がちょっと面倒だし、なにより配布するには向いていないだろう（別に配布しなくても良いが、どうせ作る労力を掛けるなら配布できるようにもしたい）。なんかそういう「すべてのカテゴリについて、カテゴリ別に分けつつ、各カテゴリに属する投稿タイトルだけを並べる」みたいな自動生成機能が欲しい。「カテゴリ別タイトル掲載機能」とでも呼ぶか。「カテゴリ別の新着投稿リスト出力機能」だとそれなりに需要はあるかもしれないが、FAQの場合は新着かどうかよりも自ら掲載項目を選択できる方が望ましい気もする。まあ、並べたい順に投稿日時を手動で修正する手はあるが。「下げる」機能を使って、「下げられていない投稿だけがリストアップされる」みたいな感じにすれば良いかもしれない。

by nishishi. ⌚ 2022年11月05日(土) 01:15:19〈204日前〉てがろぐ,開発ネタ＜661文字＞編集

次の50件»

1 2

初期表示に戻る

DASHBOARD

■開発放言について

にしし製CGIの開発進行に関する放言です。思いついたことを適当に放り込む空間なので、どんな呟きも確定的な開発予定というわけでは全くありません。しかしながら、機能面でのご要望や開発予定機能への支持表明はお気軽にどうぞ。ただし、ここには直接は投稿頂けませんので、公式動作テスト用てがろぐ等をご利用下さい。

編集

ランダムに1件を表示

RSSフィード

■全文検索：

■日付一覧：