にしし らぼらとりー

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

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

RSS Feed

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

新規投稿 / 管理用

てがろぐのデータファイル tegalog.xml の中身が人間にもそのまま見やすいXMLベースのテキストデータなのは、てがろぐを使うのをやめる場合にも書いた内容を他のツールに転用しやすくする目的もある。……のだが、文字装飾機能が増えた結果、「生のデータ」をそのまま他のツールに持っていこうとすると、(てがろぐ独自形式の装飾を使っている場合には)少々手間がかかってしまう。最初からプレーンテキストしか投稿していないならその問題はないのだが。最初期のてがろぐにはプレーンテキストしか投稿できなかったので、そこまで考えていなかった。てがろぐ独自の文字装飾機能をすべて排してエクスポートできる機能を用意すると(最後には)良いのかもしれない。

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

付箋を付ける機能。表示はされず、ログイン者のみが確認できるような。投稿本文にはコメント機能があるので、画像の方にあると便利かもしれない?

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

新規投稿した直後にだけ、あらかじめ指定しておいたURLにping的なものを飛ばす仕組みを加えると、「新規投稿したタイミングに合わせて外部サービスでも同時に何かする」みたいな仕組みが作れて、何かの役に立つかもしれない……?

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

解決した。>>2530 丸括弧1対と「?」記号の計3文字を追加するだけで、正規表現2セットを1セットにまとめられた。ちょっと考えれば分かるので、最初からそうしておくんだった。_(┐「ε:)_ とはいえ、この方法だと若干の(害のない)副作用はあるのだが。それもなくすことはできるが(その方法は思いついたが)、動作速度の面でよろしくないかもしれないので、「まあ、害がないならいいか」ということで副作用は容認することにした。

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

ああ、そういえば、No.4785で指摘された不具合をまだ解消していなかった。┌(:3」└)┐ そこを何とかせねば。たぶん、2つの正規表現で実現している部分を、1つの正規表現で実現できるように知恵を絞れば解決するはずだ。たぶん。たぶん。

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

新しい「未使用画像を探す」機能は、わりとうまくできたような気がする。

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

アーカイブ機能があれば良いのかもしれない。投稿の編集画面で「アーカイブする」ボタンを押すと、その投稿の中身を指定のテンプレートに沿って静的なHTMLファイルに出力できるような機能が。それをそのまま公開しても良いし、そのファイルを自力で再編集してWebページとして好きな場所で公開しても良いし。

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

今月中にはVer 4.4.4βを公開したいのだが、そのためには未使用画像を探す機能を(主な処理をJavaScriptで実行させることで)ローカルマシンパワーを使って実行するよう作り直す必要がある。そのためには、ある程度まとまった時間と気力が必要なので、なかなか進まない。_(┐「ε:)_

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

てがろぐ完全版パッケージ(ZIP)に同梱している各種スキンも、もうちょっと現代的なCSSに修正したいと思う気持ちもなくはないのだが(今のはまだ「IE考慮」を含んでいるくらい、かなり古いブラウザでも閲覧できるソースなので、あまり現代的ではない)、面倒くさい。_(┐「ε:)_ 最近はありがたいことにスキンを配布して下さる方々も増えたので、もう「そっちを使ってくれ」という気にもなっている、という点もあってなおさら。
そもそも、てがろぐに添付している各種スキン(のうち標準スキンではないスキン)は、元々「そのまま使ってもらう」ことはあまり考えていなくて、カスタマイズできる幅を示すのが主な目的だった。付箋型スキンとか、黒板スキンとかが特にそうだ。標準スキン・付箋型スキン・黒板スキンくらいを見れば、『スキンを書き換えるだけで、わりといろいろカスタマイズできそうだ』と思ってもらえるだろう、という考えで。なので、今でも時々、付箋型スキンや黒板スキンをそのまま活用しているページを目撃すると驚く。(笑)

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

というか、検索アルゴリズムの問題だよな。大学とかのプログラミング講義でほぼ最初の方に出てくるあれだ。線形に検索するから時間が掛かるのであって、もうちょっと何か賢い検索アルゴリズムを採用しろという話だ。

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

てがろぐ関連のアナウンス場所をもうちょっと何か一元化した方が良いよな……。公式サイト、動作試験場、PixivFANBOX、Pawoo、Twitter とかで分散し過ぎな気がする。

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

未使用画像を探す処理が重たい問題は、処理すべき内容を一旦JavaScript用に出力して、ブラウザ側で検索処理を実行して、その結果だけをCGIが受け取ればよいのではないか。実行速度はローカル端末の性能に依存するだろうけども、どれだけ時間が掛かってもサーバに負荷はかからないし。JavaScriptで実行するなら、プログレスバーとかで進捗を見せることもできるだろうし。

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

昨年、てがろぐVer 4.1で搭載した「投稿No.を1から連番で振り直す機能」は、あくまでも『連番でないと抜けが気になって嫌だ!』という気分になる人のために用意した機能であって、別に『そうしないと動かない』からあるわけではないよ、という話をどこかに書いておいた方が良いのかもしれない。現在の仕様では、投稿番号は連番である必要はないし、降順である必要もなく、重複さえしなければどうでも良い。(重複していてもとりあえず表示はできるのだが、再編集したくなっても最初に見つかった1つしかできない。)ただ、将来的な無用なトラブルを避けるためには、連番でなくても良いが、少なくとも降順ではある方が望ましいとは思う。

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

ローカルで稼働しているてがろぐと、Web上で稼働しているてがろぐとで、データや設定の同期を簡単に取れるような仕組みがあると便利なのかも知らんな……と、ちょっと思ったりした。(思っただけ)

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

てがろぐの投稿欄は、Ver.1時代のシンプルなものから、ほぼ行き当たりばったり的な感じで拡張してきたので、エレガントなコードに全くなっていない。このままだと装飾の調整が厳しいので、もうちょっとなんとかすべきなのだが、いきなり仕様を変更してしまうと、(QUICKPOSTでは)既存のスキンで望ましい装飾にならなくなる可能性があるので望ましくない。
とすると、現状の QUICKPOST を QUICKPOST1 としておいて、スキン側に [[QUICKPOSTv2]] みたいに書かれたときにだけ新仕様の投稿欄HTMLを出力する、みたいな配慮が必要だろうな。
いや、今のところ投稿欄を全面改修するような予定はないけども。(必要性は認識してはいるが、優先度が高いとは思っていない、という感じ。)

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

気力さえあれば、画像管理画面に画像検索窓を実装できる。画像管理画面に表示される画像一覧を(検索で)絞り込むことができれば、ある条件に該当する画像だけを一括削除する操作が可能になるので、あとは「使われていない画像」を見つける処理さえ加えれば、「使っていない画像を削除する」こともできるようになる。

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

a要素のaはanchor(アンカー)なので、a要素こそがアンカーなわけだが、a要素ではなくspan要素で作ったアンカー的な記述をアンカーと呼んで良いのかどうか微妙な気がしてきた。span要素で <span id="HiddenPoint"></span> とするよりも、a要素で <a id="HiddenPoint"></a> とする方が良かった……?

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

Ver 4.4.2βで、ギャラリーモード独自の設定として「画像を(原寸画像への)リンクにする」のON/OFFを可能にしたが、それだと自分で使う場合にしか適用できないので、配布スキンでその設定が必要な場合には「そう設定してから使ってくれ」と言うしかない。むしろ、[[ONEPICT:n]] 記法の亜種で、設定に関係なく画像をリンクにせず出力する [[ONEPICT:PURE:n]] みたいな記法を用意する方が便利なのかもしれない……?

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

TegUpに、てがろぐ丸ごと引っ越し機能も加えるか。てがろぐの引っ越しは、サーバ上の全ファイルをそのまま移動させれば良いだけだけども。TegUpを使って構成全ファイルをZIPに圧縮させて、ブラウザからそれをダウンロードすれば、ちょっとは手間が省ける……?

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

もはやWebサイトでUTF-8以外の文字コードを採用するメリットが何もないと思うので、てがろぐもUTF-8固定ということで良いかな、ということにしたい。今までは一応は全ファイルの文字コードを一括で修正するなら、UTF-8以外の文字コード(主にSHIFT-JIS)でも動作可能ということにしてはいたのだけど(※配慮はしていたが直接の動作は試してはいない)。ソースの中にサンプル用の絵文字(SHIFT-JISでは定義されていない絵文字)をそのまま書きたいので、もう「UTF-8でしか動かない仕様」ということにしたい。

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

ああ、ダメかも知らんな……。details要素とsummary要素で作る折り畳み機能だと、span要素とかの内側には文法的に書けないので、安易に実装してしまうと本文中の装飾が崩れることになる。昔の言い方で言うところの「インライン要素の中にブロックレベル要素は書けない」という話だが。
まあ、自由装飾機能みたいに、デフォルトでは非表示にしておいて、「分かっている人だけONにしてくれ」という形態で実装しておく方法でも良いかもしれないけども。ただ、既に隠せる装飾機能が存在することを考えると、あえて(よく分かっていない状態で使うと他のデザインが崩れる可能性のある)機能を加える必要性もなさそうな気もする。

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

やはり、「表示できる投稿が1件も見つかりませんでした。」とか「指定された番号の投稿は存在しません。」とか、表示できる内容がなかった場合には、HTTPステータスコードでも404を返すようにした方が良いんだろうな。(今は全部200)

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

以下の3記法を新設した。(全部、[設定]→[補助出力]で設定できる値を表示する機能。「状況に応じた見出し」の出力用途くらいにしか使っていなかった。)
  • [[GALLERY:NAME]] :ギャラリーモードの名称を挿入
  • [[PICTS:NAME]] :画像一覧モードの名称を挿入
  • [[SITEMAP:NAME]] :サイトマップページモードの名称を挿入
要望を頂いて、そういえばその記法はなかったな、と気付いた。需要があるとは思っていなかった、というのもあるけども。広く需要があるのかどうかが分からないので、まあ検討リストに入れようかな、と一瞬思ったのだが、そもそも処理が極めて簡単だったので、何も考えずに実装した。

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

てがろぐ「画像の管理」画面から、画像ファイルのタイムスタンプを変更できる機能の実装ができた。この機能を使って画像ファイルのタイムスタンプを修正することによって、間接的に画像の並び順(=画像一覧モードでの並び順や、新着投稿画像の並び順や、画像管理画面での並び順)を変更できる。

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

今日は、てがろぐの開発をずいぶん進んだ。ただ、あまり表には見えない部分の実装だけども。いろんなURLに対して短期間に絨毯爆撃してくるBotがサーバ負荷を高めてしまう問題に対処するには、やはりサーバ側の機能に頼るのでは不足なので、てがろぐ自体に『同一IPアドレスからxx秒間にxx回以上の頻度でアクセスがあったら一定時間ほど「429 Too Many Requests」エラーを返す』という負荷軽減機能を用意した。
負荷軽減策なので、極力何も処理しないうち(データファイルを読み込むよりも前なのはもちろん、設定ファイルすら読み込まないうち)にアクセス制限を施す必要があるので、tegalog.cgi と同じ位置に blackcheck.ini という設定ファイルを置いた場合にだけ実行されるようにした。(※管理画面から設定できるようにすると、「設定ファイルを読み込んだ後」のタイミングでしか実行できない問題があるので。)
このファイルに例えば、
  • Duration=60
  • LimitFreq=10
というような記述があれば、『同一IPアドレスから60秒間に10回を超えるアクセスがあったら、次の60秒間は「429 Too Many Requests」エラーだけを返す』というような制限になる。
あくまでも「様々なURLに対して絨毯爆撃してくるBot」(≒毎秒数件みたいな超人頻度でアクセスしてくるBot)への対策が目的なので、「何の表示条件も限定されていないページ」に対しては無制限に閲覧を許可するし、RSSの閲覧も無制限に許可する仕様になっている。もちろん、管理画面へのアクセスも制限の対象外である。それ以外の「サブコンテンツ」のURLに対してだけ、アクセス頻度をチェックして制限を掛ける。要るかどうか分からないが、一応はホワイトリスト的に任意のIPアドレスを制限から除外できる仕様も用意はした。
この機能でしばらく運用してみて、サーバ負荷の高まり(の防御具合)を確認してみるとする。

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

絨毯爆撃してくるBotによる負荷を軽減させるには、やはり「同一IPアドレスから30秒間に2回以上の頻度でアクセスがあったら一定時間ほど429を返す」みたいな処理が必要か……?

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

メインサイトで使っているサーバの障害回復に結構な時間が掛かっている……。2時間以上落ちている障害は、もしかして、さくらインターネット利用歴24年間の中でも最長なのではないか。てがろぐ新バージョンをリリースした翌日だが、今日TegUp等でバージョンアップしようとしている人々に情報が伝わっているかどうか。せっかくメインの .com とサブの .org で2サイトあるのだし、てがろぐの管理画面には動作試験場へのリンクも設けておく方が良いかもしれない。アナウンスの場として。

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

TegUpを置いている場合は、てがろぐ管理画面HOMEの「アップデートがあります」ボタンからTegUpに飛べる。現状では単に「TegUpにアクセスできるだけ」なので、TegUp上で1クリックが必要になる。それも省略できるようにして、てがろぐからTegUpへアクセスした場合には、ダイレクトにバージョンアップするようにしても良さそうな気もする。最新版の確認は、てがろぐ管理画面側で既にできているわけだし。

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

実装を検討している各機能について、どれくらいの需要があるのかの把握が難しい。アンケートを採るくらいしか手段がなさそうなのだが、アンケートを採っても(昨年の夏に採った)、この結果は「その時点での需要」でしかない上に、「それ以降に検討対象に加わった機能」については需要が分からない。もうちょっと何か、リアルタイムに需要を把握できるような仕組みを作れると望ましいのだが。そこでなんとなく思ったのは、(作りかけておきながら放置している)てがろぐユーザリンク集のアカウントに投票権を持たせて、検討中機能リストに投票できるようにする仕組みである。この方法を使って、
  • 検討中機能リストにある各機能に、それぞれ「欲しい」・「とても欲しい」みたいな回答(投票)ができる。
  • 検討中機能リストに項目を追加すると、その時点で投票項目が増える。
  • 投票内容(回答内容)は何度でも変更可能で、「以前は不要だと思っていたが今は欲しいと思うようになった」みたいな場合にはいつでも変更できる。
という感じにすれば、リアルタイムに需要の多寡を把握し続けられそうな気がする。もちろん、ユーザリンク集の利用者がそれなりに多ければの話だが。ユーザリンク集のアカウントを利用すれば、
  • 現役てがろぐ利用者に限定した投票ができる。
  • 1つの検討中機能に対して、同一人物が他票を投じるのをある程度は防げる。
というメリットもありそうなので、より正確なデータが得られそうな気もする。いや、協力者(投票者)がそれなりに居たら、の話だが。┌(:3」└)┐

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

鍵付き投稿で、「1行目を常に見せる」に加えて、「2行目も常に見せる」設定ができるようにする、設定機能だけはできた。(その結果を反映する本体機能はまだ。)

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

JavaScriptで指定範囲を隠すのではなく、<details> <summary>見せる部分</summary> 折りたたむ部分</details> のような、HTMLだけでできる折り畳み機能も設けた方が良いような気もする。

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

ああ、TegUpどうしようかな……。そこも整備してから次の(てがろぐ)正式版を出そうとするとさらに時間が掛かりそうだけど。今回はとりあえずTegUpの同梱はやめて、次に回すか……?

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

TegUpもそろそろ Ver.1 としてパッケージに同梱したいのだが、そのためには公式ドキュメントを(てがろぐ公式ドキュメント内に)設けた方が良いよな……。

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

結局、[[PERMAURL:KEEPCOND]][[PERMAURL:KEEPCOND:FULL]] の2つの記法を実装した。CONDはCONDITIONの略。>>2490

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

[[PERMAURL:KEEPCOND]] みたいな専用記法を追加するよりも、[[KEEPCOND]] みたいな記法を追加して、[[PERMAURL]] と組み合わせて使ってもらう方が便利なのではないか。もしかして。

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

てがろぐCGIで、パラメータ ?mode=around3&postid=123 で、No.123の前後3件の最大7投稿を閲覧できる機能はできた。パラメータを例えば around4 にすれば前後4件ずつの最大9投稿を閲覧できる。投稿単独表示時のURLの末尾に &mode=aroundを加えれば良い。とはいえ、自力でパラメータを加えるのは面倒なので、ユーティリティリンク枠にリンクを追加しておく方が良いか。(もちろん、設定で表示/非表示を選択できるようにする。)

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

パラメータ ?around=123 とかで、No.123 の前後5件ずつくらいの計11投稿を閲覧できるような機能が欲しい。で、そのリンクは投稿単独表示時にユーティリティリンク枠に表示される感じで。

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

WAFによる警告を回避して投稿できるように、フレーズの置き換え機能を用意したら良いのかもしれない。例えば「 @UPUP@ 」と打ったら内部では「 ../../ 」に変換されて解釈されるとか。「 @ETC@ 」と打ったら内部では「 /etc/ 」に変換されて解釈されるとか。「@」記号で挟まれる文字列は、利用者が自由に登録できるようにしたら、好きなように作れて良いのではないか。ショートコードみたいに使う方法もあるかもしれない。

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

次のてがろぐ正式版からは、TegUp も同梱するようにしたい。

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

ログインしていない限り全部見えなくする「完全プライベートモード」的な動作も、そんなに手間を掛けずに実装できそうな気がしてきたので、実装しようかな……。
主に「自分(または仲間内)専用の空間にする」という用途だけども、同時に「ゲスト権限(Lv.1)での投稿を禁止する」という設定も可能にすると、「読めるだけのユーザID」を用意することもできそうな気もする。その場合、事実上「すべての投稿を(共通)鍵付きにする」のと同じ効果にできそうな。(そういう要望もあった気がする。)

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

てがろぐで、最新の1投稿だけを別ページに埋め込みたい場合、今は「埋め込み用のスキンを作ってSSIやPHPで合成する」とか「RSSを読んで整形して合成する」とか何かそういう感じの方法しかないので、何にしても「最新の1件を出力するために、てがろぐCGIが動作する」という背景は避けられない。なので、『最新の1件だけを指定のスキンを適用して出力した結果を、静的なHTMLとして出力しておく』という動作をする「埋め込みモード」みたいなのを用意できれば、埋め込むためだけにCGIを稼働させずに済むので、埋め込み先ページの速度向上(というか速度低下の防止)に役立つ気がする。もちろん、サーバの負荷軽減にもなる。埋め込み先ページはたいていHOMEみたいな「アクセス頻度の高いページ」だろうから。

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

スキンを格納しているディレクトリの中に edit.css や edit.js がある場合、そのスキンで表示されている状態から編集画面にアクセスした場合には、スキンディレクトリにある方の edit.css や edit.js を読むようにしようか……?

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

この実装方法を考えていたときに気付いたのだが、てがろぐの全文検索では AND、OR、NOT検索が可能ではあるものの、ORの構成要素にNOTを使う検索はできない仕様だった。
例えば -りんご -みかん のようにAND検索の構成要素にNOTを使うことはできるが、 -りんご|-みかん のようにOR検索の構成要素にNOTを使うことはできないと気付いた。そんな需要があるかどうか分からないが(なさそうな気もする)。どちらにしても、激しく面倒なので対応する気はない。┌(:3」└)┐ ChatGPTに頼めば良さげなアルゴリズムを教えてくれそうな気はするけども。

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

IF文の実装には、ソースを10行くらいしか追加していない。一番面倒だと思われた条件指定部分 [[IF(この部分):~~~ は、元々てがろぐに実装していた全文検索関数にそのまま丸投げすることで済んだので、ほとんどコードを書く必要がなかった。なので、中身は全文検索機能そのままなので、SITUATION:CLASSとして出力される各キーワードと完全一致ではなく部分一致でも使える。例えば、投稿単独表示時には onelog で、複数投稿の連結時には somelogs というキーワードになる仕様なので、[[IF(log):~~~ とだけ書くと、その両方にマッチできる。この仕様があるので home を条件に指定すると問答無用で grandhome にもマッチしてしまうのだが、元々 grandhome は home を内包しているので問題なかった(たぶん)。

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

てがろぐ本文に書ける装飾記法等は入れ子にできるのだが(できないと不便だから頑張ったのだが)、この判定が凄まじく面倒くさいことに(入れ子を可能にするための)実装段階で気がついた。始まりは [B: のように英字が付いているので探すのは簡単なのだが、終わりは単に閉じカッコ ]があるだけなので、それだけでは「どの装飾の終わりなのか?」が分からない。なので、カッコの対応を外側から順に判別しながらでないと終わりを特定できない。たぶん本職のプログラマが見たら噴飯物の力業で解決してある。世の中にはもっとスマートな解決策があるような気がするが。で、今回実装したIF文にもその問題があるのだが、さすがに面倒くさすぎるので、[[IF(…): で始まるだけでなく ~:IF]] で終わる仕様にした。書くのが少々面倒だが、IF文はそんなに頻繁に書くわけではないだろうから容認してもらいたい。┌(:3」└)┐ なお、IF文自体は入れ子にできない。ELSEとかもない。条件指定部分でAND・OR・NOTを併用できるので、IF文を入れ子にする必要性はないのではないかと思っている。ELSEがあれば便利なのはよく分かるのだが、実装方法を考えるだけで気が遠くなるので考えていない。

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

このIF文は、外側スキンでも内側スキンでも両方で使える。 >>2462

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

IF文を使って、特定の状況だけでHTMLの出力を切り替えられる機能も実装できた。めでたい。
全文検索と同じように、AND OR NOT検索で状況を指定できるようにした。
  • [[IF(onelog):~~~:IF]] と書けば「~~~」の部分が投稿単独表示時にだけ出力される。
  • マイナス記号を付けて [[IF(-onelog):~~~:IF]] と書けば「~~~」の部分は投稿単独表示時以外の状況で出力される。
丸括弧の中は home とか grandhome とか cat-info とか user-tomoyo とか、SITUATION:CLASS に出力される状況キーワードを全部使える。AND OR NOT検索と同じ要領で、複数の単語を同時に指定もできる。
なので、
  • 例えば、[[IF(selected-cat -cat-info):~~~:IF]] と書けば、カテゴリ限定表示時(ただしカテゴリinfoの表示時は除く)だけの状況で出力できる。
これは、便利なのでは……。(自画自賛!)

この機能を使うと、状況別にHTMLを出し分けられるだけではなくて、今までなら複数のスキンを併用しないといけなかったことも、もしかして単一のスキンで済むようにもできたりするのではないか……。(いや、深くは考えていないけども。)

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

ユーザ設定の「紹介文」欄に入力した内容を出力する記法 [[USERINTRO]] を追加した。
USERで始まる記法が複数あるので、どうせなら USER:INTRO とか USER:ID とかにする方が読みやすいかな……と思ったものの、これ以上は増えなさそうだし、そこまで気にするほどでもないかと思い直して、やめた。

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

どうせなら、[[SITUATION:CLASS]]書いたときに出力されるキーワードをそのまま全部使える仕様だと活用の幅が広がって便利かもしれない。 >>2458
例えば [[[IF(onelog): ~ ]]] と書けば、[[SITUATION:CLASS]]に「onelog」と出力される状況(=投稿単独表示時)だけで出力される、とか。その場合は、否定の記法も用意して [[[IFNOT(onelog): ~ ]]] みたいなのもあると使いやすそうな気がする。

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

状況別に出力を切り替えられる記法を用意したい。例えば [[[IF:ONELOG: ~ ]]] と書いたら、その範囲は投稿単独表示時にしか出力されない、とか。今でもCSSで非表示にすることで切り替えられるが、それだと(スキンの内容とか1ページあたりの表示件数によっては)無駄なHTMLが大量に出力されることになるので、もうちょっとスリムにできるようにしたい。

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

Powered by てがろぐ Ver 4.9.0.

DASHBOARD

■開発放言について

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

編集

■全文検索:

■日付一覧:

■日付検索:

■カレンダー:

2024年12月
1234567
891011121314
15161718192021
22232425262728
293031

■ハッシュタグ:

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

544件

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

2026年06月29日(月) 12:58:52