ユーザ「にしし」の投稿［484件］（3ページ目） - 開発放言

にしし

No.2333

画像表示時に、画像管理画面で登録されているキャプションを出力できる機能も（ざっくりは）実装できた気がする。画像サイズが手動指定されている場合とか、一覧外フラグが立っている場合に付与するclass名とかの処理はまだこれからだが。

by nishishi. ⌚ 2022年12月20日(火) 22:38:47〈286日前〉てがろぐ＜113文字＞編集

にしし

No.2332

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

by nishishi. ⌚ 2022年12月20日(火) 21:44:46〈286日前〉てがろぐ＜45文字＞編集

にしし

No.2331

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

by nishishi. ⌚ 2022年12月18日(日) 22:50:55〈288日前〉てがろぐ＜261文字＞編集

にしし

No.2330

20日までに次のβ版を公開したいと思っていたが無理っぽいな。なんとか24日までには公開したいが。どちらにしても、年内の正式版リリースはちょっと難しそうな気がする。ただ、1月は仕事が忙しくなる可能性があるので、できれば年内にリリースしたいのだがががががが。

by nishishi. ⌚ 2022年12月18日(日) 22:24:44〈288日前〉てがろぐ＜127文字＞編集

にしし

No.2329

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

by nishishi. ⌚ 2022年12月17日(土) 12:13:17〈289日前〉てがろぐ＜331文字＞編集

にしし

No.2328

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

by nishishi. ⌚ 2022年12月17日(土) 00:41:15〈290日前〉てがろぐ＜72文字＞編集

にしし

No.2327

てがろぐでは、たとえエラーメッセージ用のページを表示する場合でも、HTTPステータスコードはすべて 200 を返している。エラーメッセージを表示するなら 500 とか（存在しない投稿番号を表示しようとされたら 404 とか）を返した方が良いのかもしれないが、そういうのを返すと、サーバ側で独自のエラーページが作られている場合に、てがろぐ側のエラーメッセージが見えなくなってしまうので望ましくない。そう考えると、やはり全部 200 を返すしかない気がする。もうちょっと何か「Webページとしては正しく表示できるが、内容はプログラム側からのエラーメッセージを伝えている」みたいなことを示すHTTPステータスコードが用意されても良いのではないか。……というか、そういうのは（Webページとしては正しく表示できるのだから）200 で良い、ということなのか。Webとして出力できないからこそ、代わりにコードを返しているのだものな……。

by nishishi. ⌚ 2022年12月14日(水) 23:12:20〈292日前〉てがろぐ＜412文字＞編集

にしし

No.2326

1つの関数はもっともっと短くするべきだとは思っているのだが、なかなかそうはいかん。_(┐｢ε:)_

by nishishi. ⌚ 2022年12月14日(水) 13:48:58〈292日前〉＜49文字＞編集

にしし

No.2325

年内に Ver 3.9.0 をリリースしようと思うと、ドキュメントを書くのに1週間は必要な点も考慮しておかないといけないのを忘れないように……。今回もたくさん書かないといけないから……。

by nishishi. ⌚ 2022年12月14日(水) 00:22:38〈293日前〉てがろぐ＜93文字＞編集

にしし

No.2324

画像を投稿する際、画像管理画面からなら(新規UPと同時に)キャプションとかフラグとかも設定できるようになった。

投稿本文と同時に画像をUPする場合でも、「下書き」か「鍵付き」で送信された場合には、同時にUPされる画像は「一覧外」フラグを立てた状態にはなる。キャプションは設定できないので、キャプションが事前に欲しい場合は、画像管理画面から先に画像だけをUPしておく必要がある。今のところは。投稿フォームに画像のキャプションまで設定できるようなUIを加えると、投稿UIのソースが大きくなってあまり望ましくない気がしているので、今のところは「キャプションを設定したければ画像管理画面から」という仕様でいくつもりでいる。（よほど要望があればまた考える。）

あと、「誰が画像をUPしたのか」の情報も独立して管理できるようになったので、画像ファイル名に「-admin」とかIDを加える必要がなくなった。そうすると、デフォルトの画像ファイル名規則「YYYYMMDDhhmmss-(ユーザID)」も必要なくなるのでどうするか。そのうち考えよう。

by nishishi. ⌚ 2022年12月13日(火) 23:02:09〈293日前〉てがろぐ＜467文字＞編集

にしし

No.2323

機能は着々とできつつあるのだが、テストするのが大変だ……。

by nishishi. ⌚ 2022年12月13日(火) 19:08:17〈293日前〉てがろぐ＜29文字＞編集

にしし

No.2322

さんごよみCGIには祝日や記念日を手動で登録しておける機能があるのだが、登録データは「01/01,元日」のように「日付,祝日名」形式のCSVになっている。日付は、その年限りの特別日なら YYYY/MM/DD で指定できるし、毎年存在するなら MM/DD で指定できる。……のだが、単純に日付文字列との一致を比較していただけだったので、2001年1月や2101年1月だと1日～31日まで丸ごと全部が元日になるバグがあった。(爆)

2001年1月だと、「2001/01/01」という日付け文字列だけでなく「2001/01/02」にも「2001/01/03」にも……「2001/01/31」にも全部「01/01」という文字列が含まれるので、日付文字列を「01/01」という対象日付を比較しているだけだと1ヶ月全部が元日になってしまうのだった。┌(:3」└)┐
幸い、さんごよみのリリースは今年(2022年)で、次にその問題が顕在化するのは79年後(2101年)なのでそのままでも特に問題はないかもしれないが。いや、ローカルソースの修正はした。次のバージョンで直る。

by nishishi. ⌚ 2022年12月10日(土) 21:12:42〈296日前〉さんごよみ＜484文字＞編集

にしし

No.2321

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

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

by nishishi. ⌚ 2022年12月09日(金) 22:07:08〈297日前〉てがろぐ＜404文字＞編集

にしし

No.2320

今日は2022年12月6日(火)だが、2022年12月03日(土)の投稿に対して『2日前』と表示される点に若干の違和感があるな……。正確には、今は 2022/12/06 15:02 で、当該投稿の投稿日時が 2022/12/03 22:21:44 なので、まだ3日(＝72時間)は経過していないから「2日(前)」と出力されるわけだが。この開発放言では投稿日時を時分秒まで表示しているから分かるが、日付しか表示しないスキンを使っている場合にちょっと違和感が強くなりそうな気がする。

by nishishi. ⌚ 2022年12月06日(火) 15:03:54〈300日前〉てがろぐ＜239文字＞編集

にしし

No.2319

さんごよみを別サイトに設置したら、「再構築/一括削除」画面を出そうとしたときにInternal Server Errorになって驚いた。プログラムのソースを確認すると、たしかにおかしい。ローカルで実行するとエラーにはならないのが不思議だが。あと、前回の Ver 1.1.0 で、サーバのエラーログにアラートが大量に記録されるようになってしまっていたので、そこも修正して、β版 Ver 1.1.1 を配布した。追加の問題の報告がなければ、早々に正式版にしたい。……報告がなければ、というか、さんごよみの場合、β版の協力者がどれくらい居るか謎だけども。2～3人居たら多い方ではないか、という気はする。

by nishishi. ⌚ 2022年12月06日(火) 14:59:09〈300日前〉さんごよみ＜299文字＞編集

にしし

No.2318

Perl 5.30未満だと、正規表現の「戻り読み」記法が使えないのだと思っていたが、自分の書いたコードの中で既に使っていて、Perl 5.8とかでも動いている。どういうことだ……と思ったら、Perl 5.30未満で使えないのは可変長の戻り読みだけだった。可変長でさえなければ戻り読みは可能なのだ。なるほど。

by nishishi. ⌚ 2022年12月03日(土) 22:21:44〈303日前〉＜153文字＞編集

にしし

No.2317

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

by nishishi. ⌚ 2022年12月03日(土) 01:02:15〈304日前〉てがろぐ＜112文字＞編集

にしし

No.2316

まったく同じコードを2つ書く必要があるとき、

そのコードだけを独立した1つの関数になるようリファクタリングしてから書く
とりあえず、同じコードを2つ書く

のでどうするか迷う。いや、望ましいのは前者に違いないのだが。リファクタリングに結構な手間がかかりそうだと迷う。いや、結構な手間がかかりそうなくらいスパゲッティなコードになっているなら、なおさら（手遅れになるほどこんがらがる前に）リファクタリングすべきなのだが……。
要するに、リファクタリングしないといけないということか。（結論）

クッキーとチョコレートはどこだ！！！（あと食べても脂肪を蓄積しない身体）

by nishishi. ⌚ 2022年12月03日(土) 00:08:24〈304日前〉＜284文字＞編集

にしし

No.2315

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

by nishishi. ⌚ 2022年12月02日(金) 23:39:00〈304日前〉てがろぐ＜45文字＞編集

にしし

No.2314

ああ、そうか。backupフォルダとimagesフォルダにも、README(for-backup).txt と README(for-images).txt が入っていたのだった。もちろん動作には要らないのでUPしなくて問題ないが、UPしても(空間を数KB占有する以外に)害はない。

by nishishi. ⌚ 2022年12月02日(金) 23:25:37〈304日前〉てがろぐ＜141文字＞編集

にしし

No.2313

てがろぐのレンタルサーバ別セットアップ方法は全部で15ページあるのでたくさん存在するように見えるが（まあ確かにたくさんあるのだが）共通部分は1つのHTML(分岐を含むPHP)で作っておいて、サーバごとに異なる部分だけをPHPで合成している。なので、レンタルサーバごとのデータ量はとても少なく10行くらいしかない。ほとんどはフラグだけで済んでいる。mixhostだけは独自の解説を生で書くしかなかったのでちょっと分量があるが。

by nishishi. ⌚ 2022年12月01日(木) 10:21:26〈305日前〉＜214文字＞編集

にしし

No.2312

てがろぐもPerlではなくPHPで書いていれば、もっと楽だったよな、ということはいつも思っている。いや、いつもということはないが。PHPを書くとよくそう思う。今さら変えられないが。

by nishishi. ⌚ 2022年12月01日(木) 10:07:37〈305日前〉＜90文字＞編集

にしし

No.2311

ローカル実験環境でも、これもまたPHPの方が遙かに簡単で、PHPがインストールされているなら、コマンドラインから php -S 127.1.1.2:8080 -t D:\Web のように打ってやるだけで、PHP内蔵のWebサーバが起動するので、ブラウザで http://127.1.1.2:8080/hogehoge.php にアクセスするだけで D:\Web\hogehoge.php に存在するPHPファイルがローカルで確認できる。ただ、これはPHP専用のWebサーバなので、ノーマルなHTMLとかは一切表示してくれないが。

終わらせるときは、[Ctrl]+[c]を押す。いちいちコマンドを打つのは面倒なので、バッチファイルを作っておいてデスクトップ等にショートカットを置いておくと楽だ。

by nishishi. ⌚ 2022年12月01日(木) 09:54:21〈305日前〉開発ネタ＜353文字＞編集

にしし

No.2310

2019年にブログ記事として書いた「てがろぐCGIが出力した最新の1件を任意の場所にSSIで埋め込む方法」の内容は、そのうちに公式サイトのFAQ・豆知識ページあたりにまとめて書き直そうと思ってはいるのだが、面倒なのでそのままリンクだけしている。ちょっとだけ更新した。画面キャプチャも古いのでもうちょっと何かした方が良い気もするのだが。更新したのは末尾で、SSIやPHPで埋め込むほかに、「埋め込み用のRSSフィード」を作ってそれをJavaScript等で読んで埋め込む選択肢もある、という話。ただ、具体的な話はしていないのだが。RSSフィードの内容をJavaScriptとかPHPとかで埋め込む方法の解説はたぶんググればたくさんあるのではないか、と思っている。探していないので分からないが。

by nishishi. ⌚ 2022年12月01日(木) 01:26:50〈306日前〉てがろぐ＜345文字＞編集

にしし

No.2309

そうだわ。今の私の環境にあるPerlは、Active Perlではなくて、XAMPPに含まれているPerlなのだった。README.txtにずっと「Active Perl」と書いたままだった。（どうでもいいが）

by nishishi. ⌚ 2022年12月01日(木) 00:52:26〈306日前〉てがろぐ＜105文字＞編集

にしし

No.2308

てがろぐ用スキンを作る際などのために、てがろぐをローカルWindows環境で動かしたい場合は、AN HTTPDという超軽量ウェブサーバを使うと良い。これは、ファイル拡張子から実行プログラムを選択してくれるので、拡張子が .cgi ならPerlを実行してくれる。なので、CGIソースの1行目にある #! /usr/bin/env perl のような記述は何でも構わない（読まれないので。つまり書かれていなくても動く）。残念なことに既にAN HTTPDの作者さんは公開を停止してしまっているのだが（閉鎖は2015年だが開発終了は2006年）、Wayback Machineからはダウンロードできる。という話を3年半前くらいに書いた。
➡AN HTTPDはWayback Machineから今でもダウンロードはできる
この記事ではActive Perlをインストールするよう書いているが、Perlなら何でも良いのでXAMPPに含まれているPerlでも良いし、Strawberry Perlでも良い。私の現在の環境ではXAMPPに含まれているPerlを使っている。Perlへのパスが通っていない場合は、自力でperl.exeのフルパスをAN HTTPDの設定画面に書く必要がある。例えば、C:\xampp\perl\bin\perl.exeのような感じで。
AN HTTPDではドキュメントルートを指定する必要があるが、設定画面から簡単に変更できるので切り替えるのも簡単な点が良い。ただ、ちょっとだけ癖のような問題があって「\」記号で終わるフルパスを書くと「そんなディレクトリはない」というエラーが出る。ドキュメントルートをフルパスで指定する際はD:\Projects\FreeCGI\Tegalogのような感じで、フォルダ名の終わりには「\」記号を付けないようにする必要がある。（ただし、ドライブのルートを E:\ のように指定する際だけは例外だが。）

by nishishi. ⌚ 2022年12月01日(木) 00:39:10〈306日前〉てがろぐ＜828文字＞編集

にしし

No.2307

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

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

にしし

No.2306

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

by nishishi. ⌚ 2022年11月30日(水) 14:39:43〈306日前〉てがろぐ＜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〈307日前〉＜1160文字＞編集

にしし

No.2304

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

by nishishi. ⌚ 2022年11月29日(火) 00:06:13〈308日前〉てがろぐ＜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〈310日前〉てがろぐ＜267文字＞編集

にしし

No.2302

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

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

にしし

No.2301

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

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

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

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

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

にしし

No.2300

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

by nishishi. ⌚ 2022年11月23日(水) 09:20:39〈313日前〉てがろぐ＜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〈313日前〉てがろぐ＜623文字＞編集

にしし

No.2298

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

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

にしし

No.2297

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

by nishishi. ⌚ 2022年11月22日(火) 22:31:46〈314日前〉てがろぐ＜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〈315日前〉てがろぐ＜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〈315日前〉てがろぐ＜1206文字＞編集

にしし

No.2294

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

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

にしし

No.2293

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

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

にしし

No.2292

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

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

にしし

No.2291

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

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

にしし

No.2290

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

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

にしし

No.2289

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

by nishishi. ⌚ 2022年11月18日(金) 22:00:57〈318日前〉てがろぐ＜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〈318日前〉てがろぐ＜1257文字＞編集

にしし

No.2287

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

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

にしし

No.2285

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

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

にしし

No.2284

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

by nishishi. ⌚ 2022年11月17日(木) 22:07:43〈319日前〉てがろぐ＜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〈319日前〉てがろぐ＜337文字＞編集

«前の50件 / 次の50件»

01 02 03 04 05 06 07 08 09 10

初期表示に戻る

DASHBOARD

■開発放言について

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

編集

ランダムに1件を表示

RSSフィード

■全文検索：

■日付一覧：