にしし らぼらとりー

にしし(西村文宏)製スクリプトの公開開発実験場(ラボラトリー)です。各種スクリプトの最新版やβ版の動作確認ができます。バグ報告や、機能面でのご要望などもお気軽にお知らせ下さい。

※当ウェブサイトは、にしし製フリーCGIなどの動作確認サンプルを公開したり、製作進行に関する呟きを掲載している実験場のようなものです。 各種CGIスクリプトの配布パッケージを入手したい場合や、にしし(西村文宏)の個人サイトをお探しの場合は、 本家サイト「にしし ふぁくとりー」へお越し下さい。(╹◡╹)ノ

RSS Feed

開発放言 カテゴリ「てがろぐ」に属する投稿[356件]

新規投稿 / 管理用

てがろぐのログイン画面では、IDをプルダウンメニュー(セレクトボックス)から選択するようになっている。これは、「自分のIDをここから現実的に選べる程度の人数が上限と考えてくれ」という感じの意味合いもある。仕様上はユーザ数の上限はないのだが、データベースを使っていない構造からしても、たくさんの人数が同時に投稿し合うような用途に使うのは現実的ではない。管理者権限を持つIDを複数作成することもできるが、Aさんが設定画面にアクセス→Bさんが設定画面にアクセス→Aさんが設定を変更して保存→Bさんが設定を変更して保存……のようなタイミングで操作されると、Aさんの設定変更はなかったことになる。(そういう操作から保護するような機能は一切ない。)「全員が1つのTLを共有する」形なので、まあ、そんな大人数で使われる(使おうと思われる)ことはないだろうと思ってはいるのだが。具体的にどれくらいが上限だとかは何も考えていないのだが、せいぜい「数人」くらいが現実的なのではないかと思ってはいる。

by nishishi. てがろぐ <439文字> 編集

Twitterから全データをダウンロードすると、ツイート本体は tweets.js というファイルの中にJSON形式で入っている。"full_text"という項目にツイート本文があって、"created_at"という項目に投稿日時がGMTで入っているので、この2つを抜き出して tegalog.xml で使えるXMLに変換すれば、過去ツイートをてがろぐ形式にはできるだろう。てがろぐ側には文字数制限がないので、そのまま抜き出すだけで良いだろうし。Twitter側には文字を装飾する機能がないのでプレーンテキストだし。たぶん、\n<br>に変換するくらいの手間だけで良いような。掲載URLが全部 t.co ドメインになっているのはどうしようもないが。GMTの日付は「Thu Nov 03 11:54:17 +0000 2022」みたいな形式で収録されているので、これをJSTに直した上で YYYY/MM/DD hh:mm:ss 形式にしないといけないが。PHPとかにその辺のことを楽にできる関数でもあっただろうか? ただ、画像は面倒くさそうだ。画像は tweets_media フォルダにまとめて格納されているので、"media_url"項目にあるURLからファイル名部分を抜き出して、さらに"expanded_url"項目にあるURLから数字列を抜き出して、「1588137486144114688-FgoyWg9aAAEKTjj.jpg」みたいにハイフンで繋げれば、画像ファイルを特定はできそうだけども。全部この方法でいけるのかどうかは分からん。

by nishishi. てがろぐ <675文字> 編集

せめて配色部分だけでもカスタム変数にしてCSSソース冒頭にまとめておく方が親切かな、という気もしないでもない。ただ、カスタマイズする人はもっと全体的にカスタマイズするだろうから、配色だけカスタム変数にしてもあまり意味ないのではないか、という気もする。

by nishishi. てがろぐ <125文字> 編集

画像インデックスXMLファイルを直接編集する方法については、どこに書こうか迷ったのだが、投稿データファイルであるtegalog.xmlの直接編集方法を「FAQ・豆知識」ページに書いていたので、それと同じにしておいた。
大量の画像キャプションを一括設定(編集)したい場合は、XMLデータを直接編集すると楽かもしれない
全画像データの先頭には、全画像データをまとめた <total>~</total> という情報行があるのだが、ここは実データから常に自動更新されるので、手動でXMLファイル内を編集するときにここを自力で計算して書き換える必要はない。てがろぐ側で再生成されるまで、画像総数とかトータルサイズとかの表示が正しくなくなるが、表示上の問題なので特に不都合はないだろう。すぐにてがろぐ側で画像インデックスを更新させれば問題は何もない。そもそもこの <total>~</total> 行は削除しても(すぐにてがろぐ側で再生成させるのなら)何も問題はない。

by nishishi. てがろぐ <429文字> 編集

あと1時間以内くらいにはリリースできるはず……。

by nishishi. てがろぐ <24文字> 編集

標準添付各スキンのCSSでは、figcaption要素に display: table-caption を適用している都合で、figure要素に border プロパティで枠線を付けても、キャプションは枠線の外側に表示されてしまう。「キャプション自体も含む画像ボックス全体」を枠で囲みたい場合は、border プロパティではなく outline プロパティを使って線を引く方法はある。ただ、outlineプロパティで引いた線は、border-radiusの影響外なので、線の角を丸めることはできないが。

by nishishi. てがろぐ <251文字> 編集

てがろぐの投稿をePub形式に出力して、そのまま電子書籍リーダーで閲覧できるようにならんかな?

by nishishi. てがろぐ <47文字> 編集

代わりに誰か書いてくれー。_(┐「ε:)_

by nishishi. てがろぐ <21文字> 編集

さすがに昨日のでは見づらすぎるので、リリースノート用の項目を整理した。
20230105002348-nishishi.png
目次の段階でそこまで詳しく書かんでも良いだろうし、開発段階のToDoとしては別項目でも、ユーザ側から見れば「単独の新機能」に過ぎない項目もあるので、統合できるのは統合した。分かりやすくする目的もあるが、何より項目数を減らさないと(リリースノートを)書きにくいので。

by nishishi. てがろぐ <169文字> 編集

今後のβ版では、追加機能の解説をFanbox上に書くのではなくて、β版の追加機能の説明自体も本番解説サイトに追記していくようにしたい(正式版にはまだ含まれていない機能であることは、『β版』みたいななんかタグで示しておけば良いだろう)。そうしないと、正式リリースのたびにドキュメントを書く作業がめちゃくちゃ大変で、気力が維持できない……。_(┐「ε:)_
特に今回は、めちゃくちゃ多いから……。
20230103221827-nishishi.png
もうちょっと手前で正式リリースを刻むべきだった……。orz

by nishishi. てがろぐ <227文字> 編集

てがろぐの設定画面で表示/非表示を切り替えられる機能については、できれば設定画面の設定項目を利用して消してくれると嬉しい。
CSSを使って消されてしまうと、
  • てがろぐ設定画面での設定でON/OFFできなくなる。
  • バージョンアップで新たに追加された機能による出力があっても(CSSによって)最初から見えないままになる。
という問題があるので……。(それに、設定画面で非表示にすれば、無駄なHTMLが出力されるのを防げるメリットもある。)
いや、どう使うのも自由なので、本人が理解した上でCSSで消すなら構わないのだけど。

by nishishi. てがろぐ <261文字> 編集

集中してドキュメントを書く日を作らないと、いつまで経っても書き上がらない気がする。1月の早い内に確保したいが……。

by nishishi. てがろぐ <57文字> 編集

ドキュメントの追記だけで1ヶ月くらいかかりそうやな……。_(┐「ε:)_

by nishishi. てがろぐ <36文字> 編集

Ver 3.8.0(正式版)以降に追加した機能(つまり、Ver 3.9.0正式版として提供する機能)が以下の通りあるのだが、これ、どれだけドキュメントを追記すれば良いのか……?┌(:3」└)┐
もうちょっと刻んで、この半分くらいで3.9.0にした方が良かったのではないか。いまさらだが。_(┐「ε:)_

《▼新機能・仕様改善》
インスタグラムの埋め込み機能。
新着画像リスト(最近に投稿された画像だけの一覧)の出力機能。(一覧外フラグが付いた画像は表示しない)
アップロードされた画像1つ1つにキャプションやフラグを登録しておける画像インデックス機能。(index.xml生成機能)
画像ごとにキャプションやフラグを設定操作できる画像編集画面。
画像に付与できるフラグ(新着画像リストに表示しない「一覧外」、閲覧注意classを付加できる「NSFW」)機能。
画像をキャプション付きで表示できる新記法 [PICT:FIG:ファイルパス] を追加。
画像のキャプションをその都度指定できる新記法 [PICT:FIG(キャプション):ファイルパス] を追加。
サムネイル画像が存在する場合には『ページ上の表示にはサムネイル画像を使い、Lightboxでのリンク先にはオリジナル画像を使う』ように表示できる機能を追加。
「続きを読む」ボタンのラベルをその都度指定できる新記法 [H:ボタンラベル:~中身~] を追加。
リストを表示するための専用記法。(箇条書きリストや番号付きリストが表示可能に)
経過時間(相対時間)表示(n分前、n時間前、n日前……のような表示)ができる日付表記オプションを追加。使用単位を「時間→日」に切り替えるタイミングは自由に設定可能。
ページ番号の省略を始める総ページ数を自由に設定できる機能。
ページ番号リンクの両端(先頭と末尾)に何ページずつ固定表示するかを変更できる機能。
サイドコンテンツ各種(例えばハッシュタグ一覧やカレンダー等)でも、ギャラリーモードやサイトマップページを維持したリンクを出力できる新記法を追加。
上位ディレクトリや別階層に存在するスキンも指定可能に。「?skin=../upperdir/some/skin-dir」のような感じで。
スキン切り替え画面で、任意のディレクトリ名を指定してスキンをプレビューしたり簡易適用したりできる機能を追加。
画像の新規アップロードと同時に、フラグやキャプションを設定できる画像管理画面でのアップロード機能。(画像が複数ある場合は、全部に同じ値が加わる仕様。)
鍵付き投稿・下書き投稿と同時にアップロードされた画像には、最初から「一覧外」フラグを立てる仕様。
投稿本文内に含まれる画像をすべて抽出して表示できる記法 [[COMMENT:PICTS]] の追加。
各種ディレクトリのパス(PATH)を得られる新記法 [[PATH:CGIDIR]][[PATH:SKINDIR]] 等を追加。
拡大画像をLightboxで表示できるテキストリンクを作る記法 [リンクラベル:LB] に、「画像リンクに独自のclass属性値を追加する」と同じclass属性値も追加されるよう仕様改善。
記法 [!-- 中身 --] で、任意の範囲をコメントアウトできる仕様。
RSS Auto-Discoveryを挿入する記法 [[RSS:AUTODISCOVERY]] を追加。(外側スキンのみ)
投稿本文の行数が得られる記法 [[TOTALLINES]] を追加。(内側スキンのみ)
スキン内に記述されている link要素やform要素に対して、「現在のスキンでの表示を維持する」目的で自動挿入される各種記述をスキップできる記法 [[NO-LINKADJUSTMENT]] を追加。※スキンの先頭に記述した場合のみ有効。先頭記述が要求されている他のタグ [[NO-LINKADJUSTMENT]][[NO-COMPLEMENT]] は同時に書ける。(外側スキンと内側スキンのそれぞれに記述可能。外側スキンだけに書いた場合、内側スキンには影響しません。)
[[INCLUDE:~]] 記法と [[PATH:~]] 記法を、内側スキンでも使用可能に。(従来は外側スキン専用でした)
任意のファイルを挿入できる INCLUDE 記法の仕様拡充。
  •    今読んでいるスキンディレクトリに存在する特定のファイルを読み込む [[INCLUDE:FROM-THIS-SKIN-DIR:ファイル名]] 記法を追加。
  •    [[INCLUDE:~]] 記法の中で [[PATH:~]] 記法によるパス指定が可能に。
  •    [[INCLUDE:~]] 記法で合成されたファイルの中に書かれている [[INCLUDE:~]] 記法も解釈するよう仕様改善。(ただし3階層まで)
  •    [[INCLUDE:~]] 記法で合成されたファイルの中に [[CALENDAR]][[DATEBOX]][[LATESTLIST]] 等、一部の記述があるとき、それが正しく解釈されない可能性があった点を修正。
  •    [[INCLUDE:~]] 記法で埋め込むファイル名として「/」で始まる絶対パスが指定された場合は、DOCUMENT ROOTからのパスとして解釈するよう仕様改善。(従来は相対パスでの記述を求めていました)

文字色として自動入力するサンプルと、背景色として自動入力するサンプルを設定できる機能を追加。
ログインフォームの下部に表示できるメッセージを設定画面で設定できる機能。
●画像管理画面から画像を選んで新規投稿する際のプルダウンメニュー項目を「新規投稿に使う(キャプション付き)」と「新規投稿に使う(画像のみ)」の2種類に拡張。
●画像の縦横サイズ(HTMLで出力されるwidth・height要素)の値を手動でも設定できる機能。
●ハッシュタグだとは認識されない「 # 」記号を簡単に表示させる方法として、「&#35;」を入力できる項目をハッシュタグ簡単入力プルダウンメニューに追加できる機能を追加。
●ファイル読み書き時の安全処理を追加。
●記述サンプルを自動入力するかどうかの設定項目を追加(リスト、文字色、背景色のサンプル自動入力のON/OFFをまとめて設定)
●投稿本文中にAmazonのURLが書かれたとき、自動で極力短く加工する機能を追加(標準ではOFF)。
●全文検索の強調表示では、半角英字の大文字小文字が一致しなくても強調対象になるよう仕様改善。
●[PICT:/hogehoge/hoge.png] のように、スラッシュで始まる絶対パスで画像が指定されたときに、ファイルが見つからなければその旨をエラー表示するよう仕様改善。(従来は、何も表示されないimg要素が出力されていました。)
●[PICT:../../hogehoge/hoge.png] のように、上位ディレクトリを参照するパスで画像が指定されたときに、ファイルが見つからなければ注釈を含むエラーを表示するよう仕様改善。
●『画像パスに絶対URL(フルパス)を使う』がONで、「スラッシュで始まる絶対パス」で画像が指定されたとき、画像のURLがおかしくなって正しく画像が表示されない不具合を解消。
●読み込むjQueryをVer.3系(jquery-3.6.1.min.js)にアップグレード。
●デフォルトで読み込むLightboxを Ver 2.11.3 にバージョンアップ。(※従来はIE対策として、あえて 2.11.0 を読み込んでいました。)
●将来的に設定画面をカスタマイズできるようにするための布石として画面出力方法をちょっとだけ変更しました(見た目にはほとんど変わりありません)。
●サーバのエラーログに「CGI::param called in list context」のようなアラートが出力されるのを防ぐよう改善。(※引き続き出る場合は教えて下さい。)

《▼スキン更新》
標準添付の各スキンを更新
  •    head要素にあるRSS Auto-Descovery部分を [[RSS:AUTODISCOVERY]] に更新。
  •    内側スキンの [[PARMAURL]][[PERMAURL]] に修正。
  •    投稿日時の相対時間表示も各スキンに追加。
  •    「最終更新日時」にも経過時間(相対時間)表記を追加。
  •    キャプション付きの画像表示に対応。


《▼不具合修正》
「続きを読む」機能を本文中に使っていながら、設定画面で「続きを読む」機能をOFFにすると、Internal Server Errorになる不具合を修正。
「skin=」パラメータでスキンが指定されているとき、投稿本文内のハッシュタグをすべて抜き出す記法 [[COMMENT:TAGS]] が動作しない不具合を解消。
ハッシュタグに半角アンダーバー「_」を使うと、投稿欄下部の既存ハッシュタグ簡単入力用プルダウンメニューでは角括弧付きでリストアップされる不具合を修正。
内側スキンで [[CATEGORYLINKS:FULL]] と書いても、カテゴリページへのURLがフルパスでは出力されない不具合を解消。
鍵付き投稿に含まれる画像が、記法 [[COMMENT:PICTS]] で抽出されるかどうかを、設定項目『n枚目の画像を [[ONEPICT:n]] 記法等で表示する』の設定値に従うよう修正。
内側スキンに記述できる [[PARMAURL]] キーワードのスペルを [[PERMAURL]] でも認識するよう改善。┌(:3」└)┐ (※両方使用可能)
スキンを簡易適用中のとき、[[PATH:SKINDIR]] でそのスキンのディレクトリが得られなかった不具合を修正。
[[PATH:~]] 記法を複数書いたとき、出力HTMLが崩れてしまう可能性がある不具合を修正。
比較的古いバージョンのPerlで実行すると、「Unrecognized escape \\v passed through at tegalog.cgi」というアラートがサーバのエラーログに記録される問題を解消。
投稿単独ページのURLを挿入する [[PARMAURL]] のスペル修正版 [[PERMAURL]] を追加。(従来のスペルのままでも使用可能)
設定画面のHTMLにいくつか存在していた文法ミスを修正。
リンクラベルの中に &#35; での # 記号が入っていても正しくラベルとして使えるよう仕様を修正。( &#35; ではない # そのものが入っているとハッシュタグとして認識されてしまうので注意)
「続きを読む」機能を入れ子にして使うと、ボタンラベルが正しく出力されないケースがある不具合を修正。(何階層にも入れ子にしても大丈夫なように改善)
畳む

by nishishi. てがろぐ <4700文字> 編集

20時間前に「Ver 3.8.8βとして公開する時点までの実装は全部できた」とNo.2335で書いたがそれは嘘で、今ようやく全部できた。_(┐「ε:)_
細かい調整を忘れていたり後から気付いたりしたので。

by nishishi. てがろぐ <102文字> 編集

カレンダーの生成もキャッシュしておきたい。

by nishishi. てがろぐ <21文字> 編集

Ver 3.8.8βとして公開する時点までの実装は全部できた。あとはβ版用の解説を書けば公開できる。

by nishishi. てがろぐ <50文字> 編集

画像管理画面で「一覧外」のフラグが設定されていれば、その画像の出力時に class="nolisted" を(画像そのものの)img要素と、(画像をリンクにする場合にはその)a要素に加えて出力するようにもした。これで、画像インデックス関連機能の初回機能としては概ね実装完了したのではないか……?
あと、スキンのCSSにfigure要素関連の装飾を加えておく必要はあるが。特にギャラリーモードでは、figure要素にデフォルトで付加される余白を消すような装飾がないとちょっと困りそうだ。

by nishishi. てがろぐ <242文字> 編集

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

by nishishi. てがろぐ <113文字> 編集

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

by nishishi. てがろぐ <45文字> 編集

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

by nishishi. てがろぐ <261文字> 編集

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

by nishishi. てがろぐ <127文字> 編集

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

by nishishi. てがろぐ <331文字> 編集

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

by nishishi. てがろぐ <72文字> 編集

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

by nishishi. てがろぐ <412文字> 編集

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

by nishishi. てがろぐ <93文字> 編集

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

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

by nishishi. てがろぐ <467文字> 編集

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

by nishishi. てがろぐ <29文字> 編集

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

by nishishi. てがろぐ <404文字> 編集

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

by nishishi. てがろぐ <239文字> 編集

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

by nishishi. てがろぐ <112文字> 編集

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

by nishishi. てがろぐ <45文字> 編集

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

by nishishi. てがろぐ <141文字> 編集

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

by nishishi. てがろぐ <345文字> 編集

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

by nishishi. てがろぐ <105文字> 編集

てがろぐ用スキンを作る際などのために、てがろぐをローカル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. てがろぐ <828文字> 編集

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

by nishishi. てがろぐ <324文字> 編集

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

by nishishi. てがろぐ <81文字> 編集

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

by nishishi. てがろぐ <69文字> 編集

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

by nishishi. てがろぐ <267文字> 編集

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

by nishishi. てがろぐ <101文字> 編集

レンタルサーバ別のセットアップ方法(15件)を加えたついでに、パーミッションの値の考え方も書いた。
  1. まず、「suEXEC」の方の値に設定してみて下さい。それで動けばそのままお使い頂けます。
  2. もし動かなかったり不都合がある場合は、次に「一般の場合」の 705 や 604 のように真ん中がゼロの値を設定してみて下さい。それで動けばそのままお使い頂けます。
  3. それでも動かない場合は、「一般の場合」の 755 や 644 の方の値を設定してみて下さい。

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

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

by nishishi. てがろぐ <488文字> 編集

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

by nishishi. てがろぐ <93文字> 編集

WitchServerの環境についてはアンケート結果がばらけていて(700で動かしている人も居れば755で動かしている人も居るし、Perlパスを変更している人も居れば変更していない人も居る)判断できなかったので、WitchServerの運営者さんに問い合わせてみたところ、丁寧な返信が来た。
それによると、WitchServerはsuEXECを採用しているが、
「設置方法3:パーミッションの設定」の項目で提示されているパーミッションであれば、
suEXEC用、一般用、どちらでも動作します。

とのこと。
どちらでも動作する、という環境もあり得るのか……。知らなかった。CGIが新規ファイルを出力するディレクトリのパーミッションも、別に 705 でも 777 でも構わないようだ。
余計なパーミッションはない方が良いだろうという立場からsuEXEC用を推奨、とさせてください。
ということなので、案内としては「suEXEC側のパーミッションに設定」ということで問題なさそうだ。
Perlパスも書き換える必要はないとのことだった。
それよりも、改行コードを LF にして、バイナリモードでアップロードする点に注意して欲しいという回答だった。

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

by nishishi. てがろぐ <623文字> 編集

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

by nishishi. てがろぐ <37文字> 編集

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

by nishishi. てがろぐ <70文字> 編集

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

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

by nishishi. てがろぐ <362文字> 編集

うーむ。スターサーバーでのセットアップ案内をどうすべきかが分からん。てがろぐユーザアンケートの結果 >>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. てがろぐ <1206文字> 編集

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

by nishishi. てがろぐ <231文字> 編集

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

by nishishi. てがろぐ <99文字> 編集

Powered by てがろぐ Ver 3.9.0.

DASHBOARD

■開発放言について

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

編集

■全文検索:

■日付検索:

■カレンダー:

2023年2月
1234
567891011
12131415161718
19202122232425
262728

■ハッシュタグ:

▼現在の表示条件での投稿総数:

356件

▼最後に投稿または編集した日時:

2023年02月02日(木) 22:38:28