にしし らぼらとりー

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

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

RSS Feed

開発放言 カテゴリ「てがろぐ」に属する投稿[485件](5ページ目)

新規投稿 / 管理用

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

ただ、現状ではサムネイル画像をアップロードする機能がないので、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. てがろぐ <1427文字> 編集

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

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

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

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

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

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

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

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

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

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

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

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

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

by nishishi. てがろぐ,開発ネタ <661文字> 編集

「管理画面そのものもスキン式にしたい」という需要があるっぽいことは分かったが、なかなか実現は難しそうな気がしている。元々スキン式にすることを微塵も考えていなかったので、実装に一貫性がないのよな。行き当たりばったり製作というか。ただ、「スキンで利用しない設定を見えなくしたい」というだけなら、以前ちょっと考えた skin.ini ファイルを使うことで実現はできそうな気がする。このファイルに、設定項目のON/OFFも指定できる機能を加えておけば、「そのスキンがメインスキンとして適用されている状況では、特定の設定項目は見えないようにできる」みたいなことはできそうだ。たしかに、「そのスキンで利用していない項目」をすべて非表示にできれば、設定画面がスッキリするだろうとは思う。

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

【ナビゲーションリンクの表示】関連の設定項目は、スキン側からも強制指定できる方が望ましいのかも知れない。「スキン側の指定を使う/ここの指定を使う」みたいな選択肢で切り替えられるとか。

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

画像インデックスを生成することそのものはまあ良いのだが、それを使って画像管理画面を作ろうとすると、画像管理画面での画像一覧生成処理をかなーり大きく書き換えないといけないことが分かった。これは……、大変だ。この実装をしようと思ったら、クッキーとチョコレートがめちゃくちゃたくさん要る。あと、それらをたくさん食べても太らない身体が……。_(:3」∠)_

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

画像インデックス生成機能を作ってキャプションとかを登録できるようにする前に、No.2211の「./mini/ディレクトリに同名画像ファイルがあったらサムネイルだとみなす」機能の方を先に作った方がいいか……?(なんとなく、そんな気がしてきた。ちょっとだけ。)

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

うーん、1枚の画像に対して、代替文字とキャプションを別々に登録できる必要はない……か? 別々に登録できるようにすると汎用性は高まるような気はするが、登録画面が複雑で面倒になる気もする。あまり、「手軽」という設計思想にはそぐわないような気もしてきた。

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

相対時間をどういう単位で掲載したいかを設定画面から指定できるようにしようか……?
  • [   ]秒未満なら秒を表示(デフォルト:60)
  • [   ]分未満なら分を表示(デフォルト:60)
  • [   ]時間未満なら時間を表示(デフォルト:48)
  • [   ]日未満なら日を表示(デフォルト:365.25)
  • それ以上なら年を表示
とか。
……あんまり需要はないか? 3つ目の選択肢だけ(=単位を「時間」から「日」に切り替える時間)を設定できれば充分かも知れない。

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

なんか、比較的古いバージョンのPerlで実行すると、Unrecognized escape \\v passed through at tegalog.cgiというアラートがサーバのエラーログに記録されるな……。Perl5.8.9では記録されたが、Perl5.14.4では記録されなかった。垂直方向の空白を一括で示せる正規表現内の記法 \v が、Perl 5.8.9あたりではサポートされていないっぽい。どのバージョンからサポートされたのかは分からんけども。「垂直方向の空白」というのは、改行(LF)、復帰(CR)、垂直タブ(VT)、フォームフィード(FF)の4つくらいのことを指している。Unicode環境だと、他にもLINE SEPARATORとかPARAGRAPH SEPARATORとかも含むようだけども。てがろぐではそこまで全部調べたいわけではなくて、単に「LFとCRを一気に指定できる」くらいの意味で使っていた。ここは、\v ではなく \r\n と書くようにしておこう……。

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

外側スキンだけでなく、内側スキンにも [[NO-LINKADJUSTMENT]] を書けるようにしてみた。内側スキンに書いた場合、投稿本文やその他(内側スキンで生成される内容すべて)に含まれる各種リンクやフォーム(=鍵付き投稿の鍵入力フォーム)で、「現在適用中のスキンでの表示」を維持しないようになる。実験してみた限りでは、うまく動作しているような気がする。

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

さっき、『「ここ本当に変更して大丈夫なのか」みたいな疑問』と書いたが、よくよく考えるとそういう疑問が出るケースはあまりない。コメントがたっぷりあるので、だいたいの役割は分かるから。それよりもよくあるのは、「書き換えるのは本当にここだけで充分なのか」みたいな疑問だ。ソースがスパゲッティすぎて、1つの機能を実現するための記述が1カ所に留まっていない場合がよくある。「ここを書き換えるなら、あっちも同時に書き換えないといけない」みたいなケースがあって(そういう箇所はまさしくリファクタリングすべき箇所なのだが)、そういうのを見逃していないかどうかの確認が必要なケースがよくある。

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

設計はほぼナシの、思いつきだけでちょくちょく機能を増やしてきたツールなので、ソースがスパゲッティすぎるのよな……。「ここ本当に変更して大丈夫なのか」みたいな疑問は、やってみて動かしてみて確かめる、という方法しかない。さすがになんかちょっとリファクタリングをする方が良いとは(ずっと)思っているのだが、リファクタリングは重い腰を上げてするものではなくて、もっと頻繁にやっとかないといけないものだよな……。あまりにもソースが絡まりすぎると、もはやリファクタリングする気力が出なくなる。「オブジェクト指向?ナニそれ」というソースだしな。久しぶりにソース量を確認したら17,636行あった。よく書いたな……。まあ、ざっくり3割くらいはコメントだと思うけども。コメントは本当に潤沢に書いておかないと未来の自分がソースの意味を把握できなくなるので、過剰気味に書いておかないと開発が続けられなくなる。

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

今のカスタマイズ方法ページに掲載しているリファレンスはやはり見やすいとは言い難いので、なんか専用記法だけを独立させた(PDFとかで)「てがろぐカスタマイズ・チートシート」みたいなのを作った方が良い気がしている。

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

次のβ版は、明日(もう今日だが)には出せる予定である。今回はほとんど、スキンを自前で大きくカスタマイズする方々向けの機能ばかりだけども。それを配布したあとは、画像管理機能の強化に進みたい。たぶん11月のてがろぐ開発はそればっかりになる気がしている。

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

INCLUDEされたファイルの中からでも、さらにINCLUDEの記述を可能にした。ただし3階層(3重)まで。別に何階層でも単にループすれば良いだけなので処理は簡単だが、同じファイルを呼び出して無限ループにはならないように。3階層もたどれば充分だろう。「複数のスキンで埋め込みたい一連のファイル群を1つのINCLUDEファイルにまとめておきたい」みたいな需要は、2階層で充分満たせるだろうから。

いま実施中のアンケートの自由入力欄で、『INCLUDEしたファイル内に [[CALENDAR]]、[[DATEBOX]]、[[LATESTLIST]] 等を書いても埋め込まれないが、[[SEARCHBOX]]、[[CATEGORY]]、[[HASHTAG]] は反映された。全部反映されるようにして欲しい』という感じの要望を頂いた(※表現はもっと丁寧だった)。そういえば、そのような動作になる可能性もあった(そうならない場合もある)。その点もソースを修正したので、次のバージョン(β版)からは、どの記述もすべて(INCLUDEされたファイル内でも)使えるようになる。

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

代替文字とキャプションを画像管理画面で登録できるようになるなら>>2238、投稿本文内に代替文字やキャプションを含ませる必要はないわけだから、No.2212みたいな複雑な記法は必要なくて、単に [PICT:FIG:ファイルパス] みたいな感じだったら登録済みの代替文字とキャプションを使って figure要素+img要素+figcaption要素を出力する……みたいな処理でいいか。もし引数FIGがなくて [PICT:ファイルパス] だったり、引数にFIG以外の文字列が指定されている場合 [PICT:ぶひぶひ:ファイルパス] だったら、従来通り img要素だけを出力すれば良いわけで。

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

今月中に、今の時点でできている細々したものを Ver 3.8.4βとして配布してしまってから、11月で画像管理機能を作り上げる感じにしたい。で、12月に Ver 3.9.0 正式版をリリースできるようにする。次の正式版までに予約投稿機能くらいは追加したかったが、そこは余力次第な気がする。先送りの可能性が(今のところは)濃厚な感じだ。

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

画像保存用ディレクトリに自動生成する index.xml(画像インデックス)は、とりあえず初回実装時の仕様としてはだいたいこんな感じでどうか。
<tegalogimages>
   <image><date>2022/10/15 17:35:30</date><file>20221015173530-admin.png</file><user>admin</user><bytes>1286</bytes><size>800x600</size><flag>lock</flag><alt>代替文字</alt><cap>キャプション</cap></image>
   <image>~</image>
   <image>~</image>
   : : :
</tegalogimages>

  • 代替文字(alt)とキャプション用文字列(cap)を別々に登録できる需要があるかどうかはよく分からないが、代替文字に指定したい文字列とキャプションとして見せたい文字列が同じとは限らないので、別にできる方が望ましそうな気はする。もっとも、今はそのキャプションを表示する機能がないので、キャプションの登録機能を用意するなら表示機能も同時に用意しないといけないが。登録機能の実装だけはしておいて、最初の公開時にはそこだけ無効(非表示)にしておいても良いかもしれない。
  • 画像を一覧に表示して良いかどうかを知るため(とか、そのほか将来的に何らかの属性を保存するため)にフラグ(flag)も記録できるようにする。
  • その画像自体の仕様として、縦横サイズ(size)とファイルサイズ(bytes)もここに記録しておけば、何度も再取得する必要がなくなる。ただ、ユーザがFTP等で画像を差し替えた場合に備えて、実際の表示に使う際の縦横サイズは、毎回取得する方が良い気はする。そう考えると、別にデータファイルに縦横サイズを記録する必要はないかもしれない(原寸サイズではなく手動指定したサイズで表示したい場合に、それを記録しておく仕様にしても良いかもしれないが)。ファイルサイズの方は、まあ記録しておけば合計サイズを計算するのが早くなるだろうから記録しておく意味はある気はする。
  • 誰がUPしたのかのユーザID(user)を記録しておけば、ファイル名からユーザIDを抜き出さなくても良くなる(というか、ファイル名を自由にしてUPしている場合でもユーザを記録できる)。
  • ファイル名(file)には、とりあえずファイル名だけを記録することを考えてはいるが、パスを加えることで他のディレクトリに存在する画像も扱えるようにしても良さそうな気がする。将来的に、画像保存用ディレクトリを複数用意できるようにすることを考えるなら特に。
そのほか、サムネイル画像の存在有無も記録できるようにしても良いかな……という気もするが、「./mini/サブディレクトリに同名のファイルがあればそれをサムネイルと見なす」みたいな仕様にするなら、別にそれは記録する必要はない気もする。あまり最初から盛ってしまうと企画倒れになる可能性が高いので、最初の段階ではシンプルにしておきたい。

デフォルトの画像ファイル名が「YYYYMMDDhhmmss-USERID」の形式なのは、このようなindexを一切設けず、ファイルのタイムスタンプすらも調べずに、ただファイル名を得るだけで「UP日時」と「UPユーザ」が分かるようにするお手軽仕様だったからだ。……が、もはやファイルの整列にはタイムスタンプを参照しているし、UPユーザもindexから分かるようになるなら、ファイル名をこの形式にする必要性が全くない。もっとTwitterとかでやっているような、短いランダムな文字列を生成して gPfKn4tsWI.png みたいな感じの意味のないファイル名にする方が良いだろうか?

たぶん、画像をカテゴリ分けする需要はあるのだろうな……。ただ、そこまで一気に実装するのは無理なので(※カテゴリを表す文字列を記録すること自体は簡単だが)、そこは先送りだ。データファイルにカテゴリを記録できなくても、UP先のサブディレクトリを選択できるようになればそれでカテゴリ分けの役割になるだろうけども。ただ、UP先のディレクトリを選択できるようにするのもそこそこ手間はかかりそうだが。

ユーザがFTP等の手段で手動UPした画像も漏れなく記録するために、画像管理画面にアクセスされた際には毎回ディレクトリを走査して、index.xmlに含まれていない画像を発見したらその都度追記する仕様にする必要がある。

少なくとも、altとcapは自動復元ができないのだから、このindex.xmlもバックアップディレクトリに自動バックアップするようにしておいた方が良いだろう。

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

投稿されたのがどれくらい前なのかを「40秒前」とか「3分前」とか「12時間前」とか「50日前」とか表示できるようにした。投稿日時を表示できる [[DATE:~]] 記法で、
  • 「A」と記述すれば、5秒前、6分前、7時間前、8日前、9年前 のように表示(未来の日付だと、1日後、2時間後、3分後のように表示)
  • 「a」と記述すれば、5秒、6分、7時間、8日、9年 のように表示(未来の日付だと、-1日、-2時間、-3分のように表示)
するようにした。なので、表示するかどうかはスキンの書き方次第だ。(記号にAを採用したのは、Agoの意味で。)

デフォルトのスキンでどうするかは考え中。あまりにも加えすぎると画面が煩すぎる気がするので、サイトマップページ用スキンに加えておくくらいに留めておくので良いかもしれない。全投稿を一覧で見るための(サイトマップページ)スキンなら、何日前に投稿されたのか、という表示もあれば分かりやすくて便利な気もしないでもないので。

図は標準スキンの投稿日時区画で、[[DATE:Y年G月N日(b) h:m:s (A)]] と書いてみたところ。
20221025140239-nishishi.png

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

あまり必要性はないと思っていたので公式サイト上でも軽く述べるに留めて詳しくは解説していなかったのだけども、てがろぐには『サーバに存在しないモジュールは、tegalog.cgiと同じディレクトリ上に(モジュールのディレクトリ構造を維持した状態で)アップロードした上で、89行目にある#use lib '.';の先頭の # を削除すれば動く』という仕様が用意してある。自力でPerlモジュールをインストールできない場合にはこの方法が使える。この方法が必要っぽい状況があることも明らかになったことだし、もうちょっと具体的に解説しておくと後々役に立つかもしれない。

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

Twitterで直近投稿に表示されるような「n秒前」、「n分前」、「n時間前」、「n日前」みたいな表示ができる日付表記オプションもそういえば簡単にできそうなので作ろうか……。Twitterでは「n日前」とは出ないけども。「前」は含めない方が良いか。数値+単位(秒・分・時間・日)だけの出力にすれば、自由な文字と組み合わせて表示をカスタマイズしやすい気がする。需要があるかどうかは分からないけども。#済 >>2236

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

以下の2つが同じファイルを読み込むようになるようINCLUDEの仕様を修正した。どちらも「現在適用中のスキンが存在するディレクトリ内にある hogehoge.html の中身」を読み込んで挿入する。
[[INCLUDE:FROM-THIS-SKIN-DIR:hogehoge.html]]
[[INCLUDE:[[PATH:SKINDIR]]hogehoge.html]] ←ドット記号は不要。

PATH:~記法は、必ず「/」記号で始まって「/」記号で終わることが保証されている仕様。
INCLUDE:~記法に「/」で始まる絶対パスが指定された場合は、WebサイトのDocument Rootからの絶対パスだと解釈して読み込まれる。(従来は、相対パスだけで記述するようリファレンスに書いていた。)

さらにサブディレクトリに存在するファイルを読むこともできる。
[[INCLUDE:FROM-THIS-SKIN-DIR:moemoe/sakura.txt]]
[[INCLUDE:[[PATH:SKINDIR]]moemoe/sakura.txt]]
どちらも「現在適用中のスキンが存在するディレクトリ内にあるサブディレクトリ「moemoe」の中にある sakura.txt の中身」を読み込んで挿入する。

同じことができる記法が2つあってもあんまり意味はないが。
後者の書き方は、バリエーションとしては以下のようなこともできる。
[[INCLUDE:[[PATH:SKINDIR:GALLERY]]hogehoge.html]] ←ギャラリーモードに指定されているスキンのディレクトリ内にあるhogehoge.htmlが読み込まれる。
[[INCLUDE:[[PATH:SKINDIR:SITEMAP]]hogehoge.html]] ←サイトマップページモードに指定されているスキンのディレクトリ内にあるhogehoge.htmlが読み込まれる。

同様に [[PATH:IMAGEDIR]] を使って画像保存用ディレクトリにあるファイルを読み込むこともできるが、あまり需要はない気はする。HTMLに画像データ(バイナリ)を読み込んでも意味がないし。

スレッドを時系列順に見る

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

次の正式版では、計画していた大きめの機能を実装していよいよ Ver.4 に……! と思っていたが、その前に修正しないといけない問題点を見つけたので、次の正式版は Ver 3.9.0 ということにして早めにリリースしたい。12月上旬あたりを目標にしようかな……。

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

……んん? なんか嘘を書いた気がするな……。

tegalog.cgi を設置している場所がドメインの最上階層なら確かに、以下の2つの記述は、同じ結果(=同じファイルの挿入)になる。
 [[INCLUDE:FROM-THIS-SKIN-DIR:hogehoge.html]]
 [[INCLUDE:.[[PATH:SKINDIR]]hogehoge.html]]

でも、tegalog.cgi を設置している場所が何らかのディレクトリの中なら、上記の2つは同じにはならない。というか前者しか正しく動作しない。
カレントディレクトリを示す「.」を頭に付けることで、ドメインの最上階層に設置されている場合にだけ例外的にうまくいく。これではダメだ。_(:3」z)_
スキンのディレクトリ名だけを返してくれる記法って何かなかったっけ……? >>2233

 

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

細かな機能を一気に実装してしまおうと思って、記法をいろいろ追加した。#済

■RSS Auto-Discoveryを挿入する専用キーワード [[RSS:AUTODISCOVERY]][[RSS:AUTODISCOVERY:FULL]] を加えた。RSSフィードが出力されている設定の場合にだけ、RSSの所在をlink要素で出力する。RSSフィードが出力されない設定なら何も出力しない。(これで、RSSを使わない設定にしているのにAuto-Discoveryの記述だけはある、という状態を避けられる。)

■別スキン適用時の自動調整処理をスキップできる記法 [[NO-LINKADJUSTMENT]] を追加した。これをスキンの先頭に記述しておけば、そのスキンがプレビュー適用されていたり簡易適用されていたりしても、(CSSの読み込み等で使われる)link要素や(全文検索フォーム等で使われる)form要素で、スキンディレクトリを強制挿入する自動調整が入らなくなる。(スキンの先頭に記述した場合のみ有効だが、先頭記述が要求されている他のタグ [[NO-COMPLEMENT]] とは同時に書ける。)

■今読んでいるスキンディレクトリに存在する特定のファイルを挿入できる記法 [[INCLUDE:FROM-THIS-SKIN-DIR:ファイル名]] を追加した。『自分のスキンがどのようなディレクトリ名でUPされているか』が分からなくても任意のファイルを読み込めるように。(長いので、ハイフンはあってもなくても良いようにした。)

■任意のファイルを挿入する [[INCLUDE:~]] 記法の中で、 [[PATH:~]] 記法によるパス指定を可能にした。(というか、ほぼすべての記法に [[PATH:~]] 記法を組み合わせられるようにした。)

※以下の2つの記述は、同じ結果(=同じファイルの挿入)になる。
 [[INCLUDE:FROM-THIS-SKIN-DIR:hogehoge.html]]
 [[INCLUDE:.[[PATH:SKINDIR]]hogehoge.html]]   ←カレントディレクトリを示す「.」が最初に必要な点に注意が要る。
(上記のどちらも、そのスキンが格納されているディレクトリ内に存在する hogehoge.html が挿入される。)
➡嘘でした。>>2229

[[INCLUDE:~]] 記法と [[PATH:~]] 記法を、内側スキンでも使えるようにした。

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

リンク先のURL末尾が hogehoge.pdf だったとき、そのリンクのa要素に class="pdf" を加える機能が欲しい。

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

スキンに同梱できる skin.ini という設定ファイルを用意できるようにすると良いかもしれない。この skin.ini がある場合は、そのスキンが適用されている際にだけ一時的に任意の設定を上書きできるようにする。例えば、ギャラリーモードとして使うスキン名(ディレクトリ名)を変更できるとか。ページネーション関連の出力設定を変更できるとか。そうすると、「そのスキンと組み合わせて使う他のスキン」を全部「そのスキンディレクトリのサブディレクトリ」に含めることも可能なので、(使用者側の)セットアップと管理が楽になる気がする。配布側が skin.ini を生成して用意しないといけないので、たぶんその生成機能を何らかの方法で事前に用意しておかないといけないが。[[INCLUDE:~]] の他に [[INCLUDE-FROM-SKINDIR:~]] みたいなのを用意して、「いま適用中のスキンディレクトリ内に存在する任意のファイル」を合成できるようにしておけば、スキン側が『自分がどんな名称のディレクトリにUPされているか』を気にしなくて済むようになって、自由度が上がりそうな気もする。#済

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

既に [[IMAGELIST]] は実装したわけだから、次の正式版に加わることになる。しかし、鍵付き投稿用としてUPされた画像でも表示されてしまう現状の仕様では問題だから、次の正式版までには何らかの対処方法を用意する必要があるだろう。で、画像管理機能を加えるとそこそこな仕様拡張になるので、画像管理機能は Ver.4 に向けた機能群に加えた方が良さそうだ。一旦、Ver.4 に向けたロードマップを書いてみるかな。Ver.4では、ログインセキュリティ機能とか、ちょっと(影響範囲が)大きめの機能を作る。(以前から作りたかったのだが、他の細々した機能を先に作ってしまおうと思って先送りしてきた。)なので、「鍵付き投稿用としてUPされた画像でも表示されてしまう」今の [[IMAGELIST]] のβ仕様を解決する他の良さげな方法を思いつかない場合は、次は Ver 3.9.0 ではなく Ver 4.0.0 だ。

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

目次モード >>2209 もあっても良いとは思うのだが、「目次」というからには最初に表示されないといかんのではないか、という気はする。「ギャラリーモードをデフォルトにしたい」という要望も頂いていたが、特定のモードを初期表示にするのは実装にちょっと手間がかかる(パラメータなしのときに特定のモードを見せること自体は簡単だが、「modeパラメータがないときは通常モード」という前提でどこもかしこもコーディングされているので、様々ある表示状況(バリエーション)全部に対して整合性を確認して調整するのが大変な気がする)ので保留にしている。畳む 標準添付スキン9種類はどれもTwitter的に「短い呟きを垂れ流す」用途のスキンなので、これらに目次が必要とされるケースはあまりなさそうな気もする(強いて言えばブログタイプスキンだけはちょっと違うが)。それよりは、「初期状態が目次に見えるスキン」を使ってもらう方向の方が(モードを増やすよりも)シンプルで良いのかもしれない。とすると「初期状態を目次のように見せたい」場合に便利な機能を追加していく方向性の方が良いのか。
サイトマップページモードは本当に要らなかった気もしないでもないのだが、Fumy News Clipperを将来的に(公開停止して)てがろぐで置き換えるためには、(Fumy News Clipperに存在する機能を全部てがろぐ側に用意する必要があるので)サイトマップページを生成できる必要があった。

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

やっぱり、画像を管理する仕組みが必要だ。今の [[IMAGELIST]] だと鍵付き投稿に含める用の画像も問答無用でリストアップされてしまうので、それを避けるには、画像1つ1つに何らかの属性を付与できる必要がある。ついでに、代替文字もあらかじめ登録できるようにしておけば、もっと便利になる気もする。./images/ に index.xml とかを用意して、そこに画像一覧データを入れておけば、毎回ディレクトリ内を走査する必要もなくなるので省力化もできるし。index.xml はXSLTで直接閲覧できるようにしても良いかもしれない。

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

カテゴリとしては残しておきたいが、もう追加することはまずないから投稿欄の下部にあるチェックボックスは非表示にしたい……みたいな設定ができるようにしたい。QUICKPOSTからは消えて、管理画面の編集画面では見える、みたいな状態だと(どうしても追加したいときには管理画面の投稿/編集画面の方を出せば済むので)便利な気がする。

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

OGPのog:image用の画像を動的に生成したい場合(テキストの画像化ツールへテキストを送りたい場合)のために、『「Ⓐ指定URL」+「Ⓑ投稿本文の冒頭テキスト」』みたいな文字列をog:imageに指定できる機能とかあると便利だろうか? Ⓐは設定画面で任意指定、Ⓑは自動抽出、みたいな。

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

画像を掲載することがメインのスキンを1つ用意するかなあ……。ただ、これ以上スキンを増やすと、更新時の管理が面倒くさすぎるのだが……。_(┐「ε:)_

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

ページ内リンクを作る記法が欲しい。リリースノートとかで、長い文書を公開するとき、冒頭の目次から見出しへ飛べるリンクが作れると便利だから。アンカーポイントを作る記法として例えば [ANCHOR:hogehoge] とかを用意して([A:hogehoge]の方が良いか)、[>A:hogehoge:リンクラベル] とか書けば「リンクラベル」という文字列で、アンカー名 hogehoge の場所へ移動するリンクになるとかどうか。

(追記) 別の記事からも、アンカーを指定して飛んでこれる記法がある方が望ましい。[>123#hogehoge]とか?

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

新着画像リストの「全191個」の部分は、ギャラリーモードへのリンクにしておいても良いかも知れない。

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

投稿本文の行数がめちゃくちゃ多い場合には、(投稿単独表示以外の表示時では)自動的に指定行数以後を畳んで「続きを読む」ボタンを表示する機能を作りたい。

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

Re:2212◆それよりも、てがろぐ管理画面内の「画像管理」側で、「その画像に対する代替文字とキャプション」をあらかじめ登録しておける仕様にしておいて、[PICT:画像ファイル名] だけなら画像だけ、[PICT:(オプション):画像ファイル名] なら、オプションに「A」があれば代替文字(alt)を出力、「F」があればfigure要素+img要素で出力、「C」があればfigcaption要素でキャプション(C)を出力……みたいな感じにできる方が楽で便利かもしれない(事前に登録可能にする実装が面倒だが)。ただ、それだと臨時のキャプションが付けられないか。

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

画像にキャプションを加えてインライン掲載できるような記法を作りたい。代替文字ではなく。代替文字(alt属性値)を指定する記法は既にある(→ [PICT:ファイルパス] ではなく [PICT:代替文字:ファイルパス] と書く)ので、この記法を維持したまま何らかの拡張をする必要がある。代替文字の指定方法をもうちょっと何か汎用的にするべきだった。orz 代替文字をそのままキャプションにする方法でも悪くはないとは思うが、「代替文字は指定したいがキャプションにはしたくない」みたいな場合もあるだろうから、やはり別に設けた方が良いだろう。

例えば、
figure要素を出力するための [FIG:画像記法:キャプション] というカバー記法を用意しておいて、その内側に既存の画像記法を挿入して [FIG:[PICT:代替文字:ファイルパス]:キャプション] と書くと、<figure class="pictbox"><img ~ alt="代替文字"><figcaption>キャプション</figcaption></figure> みたいに出力されるとか? ただ、見た目が複雑になるので、よほど記憶力が良くないと使えなさそうな気がするから、望ましくはなさそうだ。(内側に画像以外も含められる可能性があるので汎用性は高まるけども。)

例えば、
[PICT:代替文字:キャプション:ファイルパス] とすることで代替文字とキャプションを指定できる方法にすれば簡単だが、この方法だと「ファイルパス以外の文字列」が1つだけ存在するとき、「代替文字が省略されたのか、キャプションが省略されたのか」の判別ができない。まあ、キャプションを指定したい人が「代替文字は出力したくない」と思うケースは少なそうな気はするので、これで良いのかもしれないが。

この「figure要素+figcaption要素」で画像とキャプションを掲載できる仕組みがあれば、「キャプション付きの画像を横並びで掲載する」みたいな表示方法が簡単にできるメリットがある。

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

./images/ディレクトリにある画像ファイル名と同じファイル名で、./images/mini/ディレクトリに画像が存在する場合、「ページ上の表示は./images/mini/側の画像を使って、Lightboxでのリンク先には./images/側の画像を使う」みたいなオプションを加えると、画像をFTP等で別途UPしている人々には役立つかもしれない。FTP前提の機能なので、役立つ範囲は狭そうだが、元々画像をWebへFTP等でUPしているユーザさんにとっては使えるかもしれない。(一番良いのは、てがろぐ側で画像サムネイルを生成することだが、CGI設置環境の制限を極力低く抑えておきたいと考えると、ちょっと採用が難しそうな気がしている。)

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

予約投稿機能の実装もわりと簡単に実装できそうな気がしてきた。既に「投稿日時の手動設定」機能と「下書き」投稿機能があるので、これを活用すれば良さそうだ。

1. てがろぐが実行された際に時刻を確認。
2. 予約時刻に達していなければ「下書き」状態のまま。
3. 予約時刻を過ぎていれば「下書き」を解除して公開。

誰かがアクセスしなければ上記「3」が実行されないので、「予約時刻になったら自動で公開される」というわけではないのだけど、誰もアクセスしていないのであれば、公開されていなくても問題ない。
『予約時刻を過ぎてアクセスしてきた1人目の閲覧タイミング』で(下書き状態を自動解除して)公開状態にすれば、事実上は「予約時刻で自動公開」したのと同じ結果になる。(人間以外のBotやRSSリーダ等がアクセスしてくる場合も同様。BotでもRSSリーダ等でも何でも、アクセスされれば「てがろぐが実行される」ことに変わりはないため。)

コンテンツを静的に事前生成するようなCMSだとこの方法は採れないが、てがろぐのように(WordPressとかもそうだが)全ページを動的に生成するならこの方法で問題ない気がする。
予約投稿の需要がどれくらいあるのか分からないが、企業や組織サイトでお知らせ用途にてがろぐを使っている場合には需要あるだろうか。

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

サイトマップページとSITEMAP XMLが紛らわしすぎるので(たとえカタカナと英字で使い分けても)、「サイトマップページスキン」と呼ぶのをやめて「目次スキン」と呼ぼうかな……。で、「目次モード」と「SITEMAP XMLモード」があることにするとか。スキン用途も「サイトマップ」というよりは「目次」と言う方が分かりやすい気がする。今のskin-sitemapよりももっと目次っぽく見えるスキンを作っても良さそう。

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

内側スキンで [[CATEGORYLINKS:FULL]] と書いても、カテゴリページへのURLがフルパスで出力されない不具合を発見した……。#済 修正した。

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

ハッシュタグの仕様は、最初に実装するときにもうちょっとじっくり考えれば良かったな……と思ってはいる。ただ、今更仕様を変更すると(既存の投稿への)影響範囲が大きそうな気がするので難しい……。「現行仕様」と「半角空白記号のみを終端と判断する新仕様」とを設定で切り替えられるようにして、新規セットアップの場合にだけ後者をデフォルト設定にしておく(バージョンアップの場合は自ら設定を切り替えない限りは前者)、みたいな方法ならいけるかもしれないが。

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

Powered by てがろぐ Ver 4.4.3.

DASHBOARD

■開発放言について

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

編集

■全文検索:

■日付検索:

■カレンダー:

2022年11月
12345
6789101112
13141516171819
20212223242526
27282930

■ハッシュタグ:

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

485件

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

2024年09月20日(金) 22:34:14