カテゴリ「回答/返信」に属する投稿[650件](4ページ目)
今日の昼食は高菜の冷凍チャーハンでした。🍙🍙🍙
🍘Re:4681◆画像数や投稿数が多い場合にはちょいと負荷がかかる機能ですが、とりあえず実装できて良かったです。Ver 4.4.3βを先程配布開始しましたので、お試し頂ければ幸いです。アンケート等もご協力ありがとうございます。「イラスト差替により未使用画像が溜まってしまう」という点はずっと記憶に残っていまして、開発モチベーションの1つの要素になっていました。(╹◡╹)
🍘Re:4682◆詳細な説明をどうもありがとうございます。「今までは鍵付き投稿で3行目にある『説明書き』は表示できていなかったが、それを表示できるようにしたい」というようなことですかね。とりあえず現状では、投稿データファイル(tegalog.xml)をテキストエディタで編集する方法が最も楽だと思います。
tegalog.xmlファイルをテキストエディタで開くと、下図のような感じになります。(これはEmEditorでの表示例です。)

ここで、黄色矢印の先に緑色でハイライトされている部分のように、<flag>lock</flag> のような文字列で検索すると、それが鍵付き投稿だと分かります。
その行の <comment>~</comment> が本文ですが、改行は <br /> で表されていますので、3つ目の<br />の後 が「4行目の先頭」です。なので、この位置に [SYS:KEYFORM] の記述をペーストすれば、4行目の寸前に鍵入力フォームを挿入できます。
この方法なら、てがろぐ上で1件ずつ修正するよりも遙かに早く済むでしょう。
なお、その場合でも「鍵付き投稿の数が莫大なので大変!」という場合は、正規表現を使って一括置換できるテキストエディタを使うと簡単です。以下のような感じで設定します。
✅検索する文字列:(<flag>.*lock.*</flag>.*<comment>.*?<br />.*?<br />.*?<br />)
✅置換後の文字列:\1[SYS:KEYFORM]

上記の正規表現だと、鍵付き投稿(=<flag>lock</flag>)の本文の、3つ目の <br /> の後に、[SYS:KEYFORM] を追加する、という意味になるハズです。たぶん。^^;
この方法なら、全データを一括して処理できますので、ボタン1つで全投稿に対してお望みの修正が完了します。
投稿数がとても多い場合にはお試し下さい。
(※注:実践する前に、念のためにデータファイルのバックアップコピーを取っておくのを忘れないようご注意下さい。)
なお、たしかに、設定で「n行目まで見せる」と一括設定できる方が楽ではありますので、ToDoリストには入れておきます。
現状では上記の方法をお使い頂ければ幸いです。
🍘Re:4681◆画像数や投稿数が多い場合にはちょいと負荷がかかる機能ですが、とりあえず実装できて良かったです。Ver 4.4.3βを先程配布開始しましたので、お試し頂ければ幸いです。アンケート等もご協力ありがとうございます。「イラスト差替により未使用画像が溜まってしまう」という点はずっと記憶に残っていまして、開発モチベーションの1つの要素になっていました。(╹◡╹)
🍘Re:4682◆詳細な説明をどうもありがとうございます。「今までは鍵付き投稿で3行目にある『説明書き』は表示できていなかったが、それを表示できるようにしたい」というようなことですかね。とりあえず現状では、投稿データファイル(tegalog.xml)をテキストエディタで編集する方法が最も楽だと思います。
tegalog.xmlファイルをテキストエディタで開くと、下図のような感じになります。(これはEmEditorでの表示例です。)

ここで、黄色矢印の先に緑色でハイライトされている部分のように、<flag>lock</flag> のような文字列で検索すると、それが鍵付き投稿だと分かります。
その行の <comment>~</comment> が本文ですが、改行は <br /> で表されていますので、3つ目の<br />の後 が「4行目の先頭」です。なので、この位置に [SYS:KEYFORM] の記述をペーストすれば、4行目の寸前に鍵入力フォームを挿入できます。
この方法なら、てがろぐ上で1件ずつ修正するよりも遙かに早く済むでしょう。
なお、その場合でも「鍵付き投稿の数が莫大なので大変!」という場合は、正規表現を使って一括置換できるテキストエディタを使うと簡単です。以下のような感じで設定します。
✅検索する文字列:(<flag>.*lock.*</flag>.*<comment>.*?<br />.*?<br />.*?<br />)
✅置換後の文字列:\1[SYS:KEYFORM]

上記の正規表現だと、鍵付き投稿(=<flag>lock</flag>)の本文の、3つ目の <br /> の後に、[SYS:KEYFORM] を追加する、という意味になるハズです。たぶん。^^;
この方法なら、全データを一括して処理できますので、ボタン1つで全投稿に対してお望みの修正が完了します。
投稿数がとても多い場合にはお試し下さい。
(※注:実践する前に、念のためにデータファイルのバックアップコピーを取っておくのを忘れないようご注意下さい。)
なお、たしかに、設定で「n行目まで見せる」と一括設定できる方が楽ではありますので、ToDoリストには入れておきます。
現状では上記の方法をお使い頂ければ幸いです。
たこ焼きを食べました。


🍘Re:4679◆背景がちょっと分からないので教えて欲しいのですが、「今までは全公開で運営してきたが、今後は全投稿を鍵付きにしたい。その際は、3行目までを常時表示にして4行目以降を隠したい」とかそういうことですか?
なお、カテゴリごとに異なる設定を適用させるのは、『複数カテゴリに同時に属している場合にどうするか』という問題があるので、(鍵関連に限らず)ちょっと難しそうな気がしています。
🍘Re:4679◆背景がちょっと分からないので教えて欲しいのですが、「今までは全公開で運営してきたが、今後は全投稿を鍵付きにしたい。その際は、3行目までを常時表示にして4行目以降を隠したい」とかそういうことですか?
なお、カテゴリごとに異なる設定を適用させるのは、『複数カテゴリに同時に属している場合にどうするか』という問題があるので、(鍵関連に限らず)ちょっと難しそうな気がしています。
最近のマイブームなので、シューアイスが順調に消費されていきます。ので、さらにシューアイスの備蓄を調達してきました。🍨🍨🍨
🍨Re:4670◆ご要望をありがとうございます。複数チェックした投稿に対して一括で何かをする操作(※今の時点でできるのは削除だけですが)も需要はあるだろうな、とは思います。特定のカテゴリに属させるとか、カテゴリを外すとか。もちろん、下書き化・下書き解除とかもですね。将来的にはできるようにしたいと思いますので、ToDoリストには入れておきます。気長にお待ち頂ければ幸いです。
🍨Re:4671◆詳しい検証をどうもありがとうございます。なるほど、そのような用途があるとは思っていなかったので、そもそも考慮していませんでした。なぜ検証頂いた結果のような動作になるのかな……と私も不思議に思いましたので調べてみたところ、なんとまあ「卵が先か、鶏が先か」問題みたいな感じの要因が出てきました。^^;
現状のてがろぐでは、「スキン内での表示件数の指定」と「IF文」との処理順序は、以下のようになっています。
なので、IF文とかに関係なく、スキンを構成するソースを1行目から順番に下方向に眺めて行って、最初に見えた [[TEGALOG:数値]] の数値が「1ページあたりの件数」として採用されます。
これが、No.4671にお書き下さった動作になる要因です。
最初のケースでは2行目の [[TEGALOG:10]] が「最初に見えた数値指定付きの記述」ですし、次のケースでは1行目の [[TEGALOG:10]] が「最初に見えた数値指定付きの記述」です。なので、どちらも「1ページ10件」になるわけです。
「それなら、最初にIF文を処理すれば?」と思われるかもしれませんが(私も一瞬そう思ったんですが)、
なので、[[TEGALOG:数値]] の記述を発見するよりも前の段階では、IF文の指示を解釈することができない……。┌(:3」└)┐
ならば、「IF文を解釈した後に、改めてもう一度 [[TEGALOG:数値]] の記述を探して、その値を採用すれば良いのでは?」……とも思ったんですが、
この時点では既にページネーションの計算が済んでいるので、ここで「1ページ当たりの表示件数」を変えてしまうと、表示とページ数が一致しなくなって、おかしなことになります。
……と、ここまで書いていて気付いたんですが、
さらにページネーションの計算ももう一回やり直せば良いのでは? ……という気もしてきました。
ページネーションの計算は、SITUATION:CLASS に厳密には影響していますが、再生成してもIF文の判定には影響しなさそうなので、問題ないのかな……という気もします。
畳む……というわけで、いけそうな気もするんですが、本当に大丈夫なのかどうか今の時点ではハッキリしませんので、何か良さげな方法を思いつけたら対処します。現在のバージョンでどうにかする方法は残念ながらありませんので、気長にお待ち頂ければ幸いです。
🍨Re:4672◆IF文が登場するまでのバージョンでは、本当に1回しか使えませんでした。
IF文が使えるようになったバージョン以降では、IF文の条件をうまく調整することで、(IF文の条件を適用した結果として)一連の出力の中に [[TEGALOG]] の記述が1回だけ登場するように書くなら(※2回以上登場しないのはもちろん、0回にもならないように注意が必要です。0回になるパターンではエラー画面が表示されますから)、1スキンの中に [[TEGALOG]] は何回出てきても大丈夫にはなっています。ただ、[[TEGALOG:数値]] のように件数を指定する表示が出てくると、先のように意図しない表示件数になってしまう問題がありますね。
畳む現状のリファレンスでは、先の赤色文字の部分の意味で「1回だけ使える」と表現しています。ヘルプドキュメントのこの辺にちょっとだけ補足的に書いてあります。
意外と需要があるんですね。^^; 全く想像していなかったので、なるほどそういう需要もあるのか、と新たな発見でした。お知らせ下さってありがとうございます。(╹◡╹)
🍨Re:4670◆ご要望をありがとうございます。複数チェックした投稿に対して一括で何かをする操作(※今の時点でできるのは削除だけですが)も需要はあるだろうな、とは思います。特定のカテゴリに属させるとか、カテゴリを外すとか。もちろん、下書き化・下書き解除とかもですね。将来的にはできるようにしたいと思いますので、ToDoリストには入れておきます。気長にお待ち頂ければ幸いです。
🍨Re:4671◆詳しい検証をどうもありがとうございます。なるほど、そのような用途があるとは思っていなかったので、そもそも考慮していませんでした。なぜ検証頂いた結果のような動作になるのかな……と私も不思議に思いましたので調べてみたところ、なんとまあ「卵が先か、鶏が先か」問題みたいな感じの要因が出てきました。^^;
現状のてがろぐでは、「スキン内での表示件数の指定」と「IF文」との処理順序は、以下のようになっています。
- 外側スキンのソース中から [[TEGALOG:数値]] の記述を見つけて、1ページ当たりの表示件数を得る。(※見つからなければ設定値を採用)
- それを元に、ページネーション関連を計算する。
- それらを元に SITUATION:CLASS を生成する。
- その情報を元にして IF文の指定条件を解釈する。
なので、IF文とかに関係なく、スキンを構成するソースを1行目から順番に下方向に眺めて行って、最初に見えた [[TEGALOG:数値]] の数値が「1ページあたりの件数」として採用されます。
これが、No.4671にお書き下さった動作になる要因です。
最初のケースでは2行目の [[TEGALOG:10]] が「最初に見えた数値指定付きの記述」ですし、次のケースでは1行目の [[TEGALOG:10]] が「最初に見えた数値指定付きの記述」です。なので、どちらも「1ページ10件」になるわけです。
「それなら、最初にIF文を処理すれば?」と思われるかもしれませんが(私も一瞬そう思ったんですが)、
- IF文では SITUATION:CLASS の内容を元にして条件分岐するので、IF文の解釈よりも前に SITUATION:CLASS を生成しておかないと処理できないんですよね。
- ところが、SITUATION:CLASS を生成するためには、まず先に「1ページ当たりの表示件数」を知っておく必要があるんですよね。^^;
なので、[[TEGALOG:数値]] の記述を発見するよりも前の段階では、IF文の指示を解釈することができない……。┌(:3」└)┐
ならば、「IF文を解釈した後に、改めてもう一度 [[TEGALOG:数値]] の記述を探して、その値を採用すれば良いのでは?」……とも思ったんですが、
この時点では既にページネーションの計算が済んでいるので、ここで「1ページ当たりの表示件数」を変えてしまうと、表示とページ数が一致しなくなって、おかしなことになります。
……と、ここまで書いていて気付いたんですが、
さらにページネーションの計算ももう一回やり直せば良いのでは? ……という気もしてきました。
ページネーションの計算は、SITUATION:CLASS に厳密には影響していますが、再生成してもIF文の判定には影響しなさそうなので、問題ないのかな……という気もします。
畳む……というわけで、いけそうな気もするんですが、本当に大丈夫なのかどうか今の時点ではハッキリしませんので、何か良さげな方法を思いつけたら対処します。現在のバージョンでどうにかする方法は残念ながらありませんので、気長にお待ち頂ければ幸いです。
🍨Re:4672◆IF文が登場するまでのバージョンでは、本当に1回しか使えませんでした。
IF文が使えるようになったバージョン以降では、IF文の条件をうまく調整することで、(IF文の条件を適用した結果として)一連の出力の中に [[TEGALOG]] の記述が1回だけ登場するように書くなら(※2回以上登場しないのはもちろん、0回にもならないように注意が必要です。0回になるパターンではエラー画面が表示されますから)、1スキンの中に [[TEGALOG]] は何回出てきても大丈夫にはなっています。ただ、[[TEGALOG:数値]] のように件数を指定する表示が出てくると、先のように意図しない表示件数になってしまう問題がありますね。
畳む現状のリファレンスでは、先の赤色文字の部分の意味で「1回だけ使える」と表現しています。ヘルプドキュメントのこの辺にちょっとだけ補足的に書いてあります。
意外と需要があるんですね。^^; 全く想像していなかったので、なるほどそういう需要もあるのか、と新たな発見でした。お知らせ下さってありがとうございます。(╹◡╹)
返信が遅くなってすみません。気力が足りない日が続いていまして。たこ焼きが足りないのか……。_(┐「ε:)_ ...


🥞Re:4663◆とても有用なスクリプトをどうもありがとうございます! 使っていない画像を探して一括削除する機能ももうできそうな感じですので「tweets_mediaフォルダの中身を全部コピーして、てがろぐ上で無関係画像だけを一括削除する」みたいな操作も可能になりそうです。◆フィードバックもありがとうございます! 問題なく動作しているようで良かったです。(╹◡╹)
🥞Re:4664◆ご要望をありがとうございます。なるほど、確かに2ページ目以降に流れて行ってしまうと、カテゴリ欄から探して押すのは面倒ですし、検索コマンドを覚えておくのも打つのも面倒ですね。冒頭に何か加えるようにします。◆フィードバックもありがとうございます。QUICKPOSTでカテゴリに最初からチェックを入れておく機能は、果たして便利なのかわりと半信半疑な感じ(だったものの簡単だったの)で作ったんですが、役に立つんですね。(笑) 良かったです。^^;
🥞Re:4665◆特に非推奨ということはありません。別にそうして使って頂いても何も問題ありません。てがろぐのデータ形式がXMLベースなのは、ローカルで人間が編集しやすくするためですので、FAQにも少し項目がありますが、ローカルで編集したXMLをアップロードして使って頂くのは想定している範囲内です。私もよくします。
なお、iniファイル(tegalog.ini)には各種キャッシュ情報も保管されていますので、「ローカルで更新したxmlファイル」というのが「ローカルで稼働しているCGI(てがろぐ)上で更新したxmlファイル」という意味でしたら、iniファイルもセットでアップロードする方が良いと思います。ただし、ローカルのてがろぐとWeb上のてがろぐとで、異なる設定値で使っている部分があるなら、iniファイルはアップロードしない方が良いです。その場合(や、テキストエディタ等でXMLを編集した場合)は、xmlファイルをアップロードした後で、Web上のてがろぐで「投稿を再カウント」→「すべてを再カウント」を1回実行すると良いです。そう操作すると、iniファイルの中にある各種キャッシュ値もすべて再生成されますので。
🥞Re:4668◆反応ありがとうございます。「そうはいっても、本当に需要あるのか……?」と疑問に思わなくもないので、反応があるとモチベーションの維持に役立ってありがたいです。(^_^;)
🥞Re:4663◆とても有用なスクリプトをどうもありがとうございます! 使っていない画像を探して一括削除する機能ももうできそうな感じですので「tweets_mediaフォルダの中身を全部コピーして、てがろぐ上で無関係画像だけを一括削除する」みたいな操作も可能になりそうです。◆フィードバックもありがとうございます! 問題なく動作しているようで良かったです。(╹◡╹)
🥞Re:4664◆ご要望をありがとうございます。なるほど、確かに2ページ目以降に流れて行ってしまうと、カテゴリ欄から探して押すのは面倒ですし、検索コマンドを覚えておくのも打つのも面倒ですね。冒頭に何か加えるようにします。◆フィードバックもありがとうございます。QUICKPOSTでカテゴリに最初からチェックを入れておく機能は、果たして便利なのかわりと半信半疑な感じ(だったものの簡単だったの)で作ったんですが、役に立つんですね。(笑) 良かったです。^^;
🥞Re:4665◆特に非推奨ということはありません。別にそうして使って頂いても何も問題ありません。てがろぐのデータ形式がXMLベースなのは、ローカルで人間が編集しやすくするためですので、FAQにも少し項目がありますが、ローカルで編集したXMLをアップロードして使って頂くのは想定している範囲内です。私もよくします。
なお、iniファイル(tegalog.ini)には各種キャッシュ情報も保管されていますので、「ローカルで更新したxmlファイル」というのが「ローカルで稼働しているCGI(てがろぐ)上で更新したxmlファイル」という意味でしたら、iniファイルもセットでアップロードする方が良いと思います。ただし、ローカルのてがろぐとWeb上のてがろぐとで、異なる設定値で使っている部分があるなら、iniファイルはアップロードしない方が良いです。その場合(や、テキストエディタ等でXMLを編集した場合)は、xmlファイルをアップロードした後で、Web上のてがろぐで「投稿を再カウント」→「すべてを再カウント」を1回実行すると良いです。そう操作すると、iniファイルの中にある各種キャッシュ値もすべて再生成されますので。
🥞Re:4668◆反応ありがとうございます。「そうはいっても、本当に需要あるのか……?」と疑問に思わなくもないので、反応があるとモチベーションの維持に役立ってありがたいです。(^_^;)
昼食のパスタでおなかいっぱい……。ぐっふぅ。_(┐「ε:)_
🍝Re:4652◆差し出がましいなどということは一切ありません。ご報告はとてもありがたいです!どうもありがとうございます!(╹◡╹)ノ◆No.4646の件はこちらのローカルソースでは解決しましたので、次のバージョン(Ver 4.4.3β)では問題なくなります。配布までもうしばらくお待ち願います。
🍝Re:4654◆何でも簡単入力ボタン機能でコロンを含む文字列を挿入させたい場合は、No.4655さんの通り ラベル:[:hogehoge:] のように、ラベルを加えて下さい。すると、そのラベル文字列がボタン(またはセレクトボックスの1項目)として表示され、それ以降の文字列が実際に挿入されます。
🍝Re:4655◆的確なサポートをどうもありがとうございます! ヘルプドキュメントが役に立っていると分かって嬉しいです。(笑)
🍝Re:4652◆差し出がましいなどということは一切ありません。ご報告はとてもありがたいです!どうもありがとうございます!(╹◡╹)ノ◆No.4646の件はこちらのローカルソースでは解決しましたので、次のバージョン(Ver 4.4.3β)では問題なくなります。配布までもうしばらくお待ち願います。
🍝Re:4654◆何でも簡単入力ボタン機能でコロンを含む文字列を挿入させたい場合は、No.4655さんの通り ラベル:[:hogehoge:] のように、ラベルを加えて下さい。すると、そのラベル文字列がボタン(またはセレクトボックスの1項目)として表示され、それ以降の文字列が実際に挿入されます。
🍝Re:4655◆的確なサポートをどうもありがとうございます! ヘルプドキュメントが役に立っていると分かって嬉しいです。(笑)
アイスと冷蔵ピザの備蓄は滞りなく調達できました。🍨🍕🍨🍕🍨🍕
🍨Re:4650◆ご指摘をどうもありがとうございます! たしかにこちらでも再現しました。原因究明までどうもありがとうございます。m(_ _)m 助かりました。設定値に応じて出力するJavaScriptを変化させる部分の処理に問題がありました。修正版を改めてUPしましたので、ご試用頂ければ幸いです。
🍨Re:4650◆ご指摘をどうもありがとうございます! たしかにこちらでも再現しました。原因究明までどうもありがとうございます。m(_ _)m 助かりました。設定値に応じて出力するJavaScriptを変化させる部分の処理に問題がありました。修正版を改めてUPしましたので、ご試用頂ければ幸いです。
明日はアイスの備蓄を買いに行ってきます。🍨🍨🍨
🍨Re:4646◆実験をどうもありがとうございます。なるほど確かにうまくいっていませんね。^^; いけそうな気がしたんですが。内部事情をよく確認してから(たぶん次のバージョンあたりで)何とかします。◆ヘルプドキュメントは毎回本当に「こんだけ書いて、読む人は居るのか……?」と思いながら書いているので(笑)、役に立っているならとても嬉しいです。
🍨Re:4646◆実験をどうもありがとうございます。なるほど確かにうまくいっていませんね。^^; いけそうな気がしたんですが。内部事情をよく確認してから(たぶん次のバージョンあたりで)何とかします。◆ヘルプドキュメントは毎回本当に「こんだけ書いて、読む人は居るのか……?」と思いながら書いているので(笑)、役に立っているならとても嬉しいです。
夕食は餃子。🥟🥟🥟
書く必要のあるヘルプドキュメントの量が多くて気力が出ない……。_(┐「ε:)_
🥟Re:4642◆任意のスキンで表示するには、要するにURLに skin=スキン格納ディレクトリ名 というパラメータが付けば良いわけですから、リンクを作る際に <a href="[[PERMAURL:PURE]]?skin=skin-hoge" ~ のような感じでリンク先を指定すれば skin-hoge で表示されるページに移動できます。([[PERMAURL:PURE]]で表示スキンを指定するパラメータのない状態のURLになりますから、その末尾に自力で?skin=skin-hogeを付け加えているだけです。)お試し下さい。
🥟Re:4643◆ああ、確かに鍵入力フォームを経ると、直前に表示されていた状況はすべて維持されませんね。^^; 維持する発想がなかったので、何のパラメータも(入力フォームで)送信していませんでした。今後のバージョンで解決します。(たぶん次の次のβ版で。次のβ版はもうプログラムを確定してしまったので。)◆なるほど、セミファイナルは脚を見る必要があったんですね。^^;
🥟Re:4644◆おや、その方法でもダメでしたか。その方法でもいけそうな気もしたのですけども。移動後(=鍵を入力した後)に表示されるページのURL(=ブラウザのアドレス欄に表示されるURL)に「cat=A_novel」というパラメータが含まれていますでしょうか?
書く必要のあるヘルプドキュメントの量が多くて気力が出ない……。_(┐「ε:)_
🥟Re:4642◆任意のスキンで表示するには、要するにURLに skin=スキン格納ディレクトリ名 というパラメータが付けば良いわけですから、リンクを作る際に <a href="[[PERMAURL:PURE]]?skin=skin-hoge" ~ のような感じでリンク先を指定すれば skin-hoge で表示されるページに移動できます。([[PERMAURL:PURE]]で表示スキンを指定するパラメータのない状態のURLになりますから、その末尾に自力で?skin=skin-hogeを付け加えているだけです。)お試し下さい。
🥟Re:4643◆ああ、確かに鍵入力フォームを経ると、直前に表示されていた状況はすべて維持されませんね。^^; 維持する発想がなかったので、何のパラメータも(入力フォームで)送信していませんでした。今後のバージョンで解決します。(たぶん次の次のβ版で。次のβ版はもうプログラムを確定してしまったので。)◆なるほど、セミファイナルは脚を見る必要があったんですね。^^;
🥟Re:4644◆おや、その方法でもダメでしたか。その方法でもいけそうな気もしたのですけども。移動後(=鍵を入力した後)に表示されるページのURL(=ブラウザのアドレス欄に表示されるURL)に「cat=A_novel」というパラメータが含まれていますでしょうか?
ヘルプドキュメントさえ書き上がれば配布するんですけども、問題はヘルプドキュメントがいつ書き終わるのかという点で。_(┐「ε:)_
🍛Re:4635◆ここで稼働している Ver 4.4.2βではその機能を有効に設定してありますので、例えばつぶやきとかつぼやきとかのカテゴリを表示させると、そのQUICKPOSTには最初からそのカテゴリにチェックが入っています。つぼはち・テストのように複数のカテゴリを同時に閲覧している場合は、両方のカテゴリにチェックが入ります。
🍛Re:4638◆テストありがとうございます。何も設定していない初期状態では、😋🎉✅の3つが出る仕様になっています。何か美味いものを食べたときに使って下さい。(笑)
🍛Re:4639◆詳しい説明をありがとうございます。ようやく望みの点は理解できました。何にせよ解決して良かったです。(╹◡╹)
🍛Re:4640◆予約によって掲載された投稿には、管理画面の記事一覧では「予約(掲載済)」と出ますが、その後に1度でも編集すると(内部の仕様的に)通常の投稿と区別が付かなくなるので何も表示されなくなります。その辺の表示については、ヘルプドキュメントの「予約投稿の区別」もご参照下さい。
🍛Re:4635◆ここで稼働している Ver 4.4.2βではその機能を有効に設定してありますので、例えばつぶやきとかつぼやきとかのカテゴリを表示させると、そのQUICKPOSTには最初からそのカテゴリにチェックが入っています。つぼはち・テストのように複数のカテゴリを同時に閲覧している場合は、両方のカテゴリにチェックが入ります。
🍛Re:4638◆テストありがとうございます。何も設定していない初期状態では、😋🎉✅の3つが出る仕様になっています。何か美味いものを食べたときに使って下さい。(笑)
🍛Re:4639◆詳しい説明をありがとうございます。ようやく望みの点は理解できました。何にせよ解決して良かったです。(╹◡╹)
🍛Re:4640◆予約によって掲載された投稿には、管理画面の記事一覧では「予約(掲載済)」と出ますが、その後に1度でも編集すると(内部の仕様的に)通常の投稿と区別が付かなくなるので何も表示されなくなります。その辺の表示については、ヘルプドキュメントの「予約投稿の区別」もご参照下さい。
昼食はカレーライス🍛
🍛Re:4634◆さすがにもっと詳しく状況を説明して頂かないと、「そもそも何に困っているのか?」の時点から分からないです。『このような表示にしたいのだが、今はこうなっている』みたいな。
例えば、
🍛Re:4634◆さすがにもっと詳しく状況を説明して頂かないと、「そもそも何に困っているのか?」の時点から分からないです。『このような表示にしたいのだが、今はこうなっている』みたいな。
例えば、
- 「一部のcssしか適用されなくなってしまいます」→ 「一部」とは具体的には何でしょう?
- 「デフォルトの表示が適用されてしまいます」 → 「デフォルトの表示」とは具体的には何でしょう?
シューアイスの追加備蓄は無事に調達できました。🍨🍨🍨
🍨Re:4629◆店頭で実物を触らないまま通販で選ぶと、ちょっと冒険ですね。^^;
🍨Re:4630,4632◆解決したようで良かったです。(╹◡╹)ノ
🍨Re:4631◆その機能はないのですが、あると便利そうですね。わりと簡単に実装できそうでしたので(私のローカルにある開発環境では)実装しました。次に公開するバージョン Ver 4.4.2β からお使い頂けます。(※設定でON/OFFできる仕様にしました。)
🍨Re:4629◆店頭で実物を触らないまま通販で選ぶと、ちょっと冒険ですね。^^;
🍨Re:4630,4632◆解決したようで良かったです。(╹◡╹)ノ
🍨Re:4631◆その機能はないのですが、あると便利そうですね。わりと簡単に実装できそうでしたので(私のローカルにある開発環境では)実装しました。次に公開するバージョン Ver 4.4.2β からお使い頂けます。(※設定でON/OFFできる仕様にしました。)
明日はシューアイスの追加備蓄を買いに行ってきます。🍨🍨🍨
🍨Re:4623◆頻繁に言いたいことと言ったら……😍
🍨Re:4624◆来週には公開できる予定では居るんですが、実際にどうなるかはヘルプドキュメントをどれくらい早く書けるか次第です。_(:3」∠)_
🍨Re:4625◆ああ、もしかして「本文はナシで、画像だけを新規アップロードに指定」して投稿していたということですかね? その操作は想定から漏れていました。こちらのローカルにある開発版では、アラート表示の条件を『本文が何もなくて、かつ、新規画像も指定されていない場合』という条件に書き換えましたので、次のバージョン(Ver 4.4.2β)からは、本文が空欄でも画像さえ指定されていれば投稿できるようになります。もうしばらくお待ち下さい。
※QUICKPOSTからなら、今でもその操作(本文ナシの画像だけで投稿)は可能だとは思いますけども。
🍨Re:4626◆お使いの tegalog.cssの13~19行目に div に対する装飾がありますよね。そこの先頭(14行目)にある width: 100%; を消してみて下さい(または、17行目の margin: 10px;を消すのでも良いです)。すると、本文の右端が欠けてしまう問題は解決すると思います。
(※divのような、極めて頻繁に登場する要素に対して直接装飾を適用してしまうと影響範囲が広大になってしまうので、class名を使ってもう少し適用先を絞る方が無難だと思います。)
🍨Re:4623◆頻繁に言いたいことと言ったら……😍
🍨Re:4624◆来週には公開できる予定では居るんですが、実際にどうなるかはヘルプドキュメントをどれくらい早く書けるか次第です。_(:3」∠)_
🍨Re:4625◆ああ、もしかして「本文はナシで、画像だけを新規アップロードに指定」して投稿していたということですかね? その操作は想定から漏れていました。こちらのローカルにある開発版では、アラート表示の条件を『本文が何もなくて、かつ、新規画像も指定されていない場合』という条件に書き換えましたので、次のバージョン(Ver 4.4.2β)からは、本文が空欄でも画像さえ指定されていれば投稿できるようになります。もうしばらくお待ち下さい。
※QUICKPOSTからなら、今でもその操作(本文ナシの画像だけで投稿)は可能だとは思いますけども。
🍨Re:4626◆お使いの tegalog.cssの13~19行目に div に対する装飾がありますよね。そこの先頭(14行目)にある width: 100%; を消してみて下さい(または、17行目の margin: 10px;を消すのでも良いです)。すると、本文の右端が欠けてしまう問題は解決すると思います。
(※divのような、極めて頻繁に登場する要素に対して直接装飾を適用してしまうと影響範囲が広大になってしまうので、class名を使ってもう少し適用先を絞る方が無難だと思います。)
先日、米を買いに行ったら、米が売っていなくて驚きました(棚が空っぽでした)。🍙🍙🍙
🍙Re:4616◆ありがとうございます。(╹◡╹) TegUpは、機能的にはほぼ 0.9.0 から変わっていないとはいえ、動作を試して頂けるのはありがたいです。
🍙Re:4617◆昨日の宮崎での震度6弱に加えて、今夜は神奈川で震度5弱とか……。続かないことを祈りたいです。
🍙Re:4618◆実現方法はいくつかありまして、No.4619さんが解説して下さっているのも1つの手です。
とはいえ、そもそも設定で『画像を(原寸画像への)リンクにする』をOFFにできるなら(※下図の緑色矢印部分)、
『画像を(原寸画像への)リンクにする』項目がOFFなら、[[ONEPICT:1]]の出力はリンクにならないので、その外側を自前のa要素で囲めるようになるわけですね。
ただ、「(ギャラリーモードではない)通常モードでは画像をクリックすると拡大させたい」という場合にはこの方法は採れません。
そこで、抜本的な解決策として、『ギャラリーモードで、画像を(原寸画像への)リンクにするかどうか』を個別に設定できる機能を、いま加えました(※下図の黄色矢印部分)。
これらの機能を使って、下図🟢緑色矢印をON・🟡黄色矢印をOFFにすると、

『ページの表示』側の「画像を(原寸画像への)リンクにする」項目(※従来Ver.からある) 
『補助出力』側の「画像を(原寸画像への)リンクにする」項目(Ver 4.4.2β以降)
もっと早くこの機能を実装しておけば良かったな……と思いました(最近、よくそう思うんですが^^;)。
とりあえず、私のローカル開発環境にあるファイルでは実装しましたので、後日公開する次のβ版(Ver 4.4.2)からお使い頂けます。
なので、次のβ版の公開をお待ち頂くのでも良いと思います。もちろん現状でもいろいろ方法はありますので、No.4619さんの解説とかその他の解説を参考になさっても良いと思います。次のβ版は、来週には公開する予定です。(たぶん)
あと、ナイスな参考サイトのご提示をありがとうございました。このフィギュアが極めてお勧めです😍
🍙Re:4619◆解説ありがとうございます!(╹◡╹)ノ
🍙Re:4616◆ありがとうございます。(╹◡╹) TegUpは、機能的にはほぼ 0.9.0 から変わっていないとはいえ、動作を試して頂けるのはありがたいです。
🍙Re:4617◆昨日の宮崎での震度6弱に加えて、今夜は神奈川で震度5弱とか……。続かないことを祈りたいです。
🍙Re:4618◆実現方法はいくつかありまして、No.4619さんが解説して下さっているのも1つの手です。
とはいえ、そもそも設定で『画像を(原寸画像への)リンクにする』をOFFにできるなら(※下図の緑色矢印部分)、
<a href="[[PERMAURL:PURE]]">[[ONEPICT:1]]</a>……という書き方ができます。
『画像を(原寸画像への)リンクにする』項目がOFFなら、[[ONEPICT:1]]の出力はリンクにならないので、その外側を自前のa要素で囲めるようになるわけですね。
ただ、「(ギャラリーモードではない)通常モードでは画像をクリックすると拡大させたい」という場合にはこの方法は採れません。
そこで、抜本的な解決策として、『ギャラリーモードで、画像を(原寸画像への)リンクにするかどうか』を個別に設定できる機能を、いま加えました(※下図の黄色矢印部分)。
これらの機能を使って、下図🟢緑色矢印をON・🟡黄色矢印をOFFにすると、
- 🟢通常モードでは、画像は原寸画像へのリンクになる(=その場で拡大表示される)
- 🟡ギャラリーモードでは、画像はリンクにならない(ので、スキン側に <a href="[[PERMAURL:PURE]]">[[ONEPICT:1]]</a> などと書くことで自由にリンク先を調整できる)


もっと早くこの機能を実装しておけば良かったな……と思いました(最近、よくそう思うんですが^^;)。
とりあえず、私のローカル開発環境にあるファイルでは実装しましたので、後日公開する次のβ版(Ver 4.4.2)からお使い頂けます。
なので、次のβ版の公開をお待ち頂くのでも良いと思います。もちろん現状でもいろいろ方法はありますので、No.4619さんの解説とかその他の解説を参考になさっても良いと思います。次のβ版は、来週には公開する予定です。(たぶん)
あと、ナイスな参考サイトのご提示をありがとうございました。このフィギュアが極めてお勧めです😍
🍙Re:4619◆解説ありがとうございます!(╹◡╹)ノ
夕食でおなかいっぱいです。ぐふぅ。今日はたこ焼きは食べませんでした。
🧀Re:4607◆私もそう思いました。(╹◡╹)
🧀Re:4608◆早速のご試用をどうもありがとうございます!
🧀Re:4609◆たまたま実装が簡単だったのですぐにできました。ご活用頂ければ幸いです。
🧀Re:4610◆美味そう。
🧀Re:4611◆はやい……。
🧀Re:4612◆次のβ版からご使用頂けます。もっと早くにこの手段を気付けたら良かったんですが。^^; でもまあ、「1行目だけは見せる」とか「2行目だけは見せる」という設定は、それはそれで『毎回挿入位置を指示する必要がない』という便利さはあると思いますので、まあ、併用して頂けたら良いかな、と思います。
🧀Re:4613◆そういうアクセスをサーバ側でブロックしてくれる機能があると良いのですけどもね。
🧀Re:4607◆私もそう思いました。(╹◡╹)
🧀Re:4608◆早速のご試用をどうもありがとうございます!
🧀Re:4609◆たまたま実装が簡単だったのですぐにできました。ご活用頂ければ幸いです。
🧀Re:4610◆美味そう。
🧀Re:4611◆はやい……。
🧀Re:4612◆次のβ版からご使用頂けます。もっと早くにこの手段を気付けたら良かったんですが。^^; でもまあ、「1行目だけは見せる」とか「2行目だけは見せる」という設定は、それはそれで『毎回挿入位置を指示する必要がない』という便利さはあると思いますので、まあ、併用して頂けたら良いかな、と思います。
🧀Re:4613◆そういうアクセスをサーバ側でブロックしてくれる機能があると良いのですけどもね。
今日も、たこ焼きを食べました。6個。





🍘Re:4593◆ご回答ありがとうございます。遅くはなっていないようで安心しました。画像管理画面では、表示するたびに「実際に画像保存用ディレクトリに存在する全画像ファイルを走査して、更新日時等の情報を取得して、画像インデックスファイルを更新する」という処理をしているので、画像ファイルが多ければ多いほど作業量も増えるんですけども、1500枚くらいなら現実的に特に問題にはならないと知って安心しました。
◆【追記部分に対する返信】 なお、てがろぐでは、1回の通信で送信する総データサイズが30MBを超えた場合には通信を打ち切る仕様になっています。なので、大量の画像を一括アップロードすると、処理は成功せずにすべて無視されると思います。UPなさっている画像がだいたい「1枚あたり2MB」であれば、15枚くらいを超えると制限を超過しますね。(例えば、ほんの2~300KB程度の小さな画像で試すと、20枚とか30枚とかでも問題なく一括UPできるのではないかと思います。)
仮に、てがろぐ側で制限しなかったとしても、おそらくWebサーバ側でも(負荷軽減目的や悪意あるアップロード等を防ぐために)通信速度か何かの制限が掛かると思います。なので、サイズの大きな画像をたくさんUPする場合には、細かく刻んで下さい。(てがろぐ上で細かく刻むのが面倒な場合は、FTP等の別手段でUPして頂くのが良いと思います。)
🍘Re:4594◆ご回答ありがとうございます!(╹◡╹)ノ 元々、たくさんの画像をUPして管理することを想定していなかったので、ちょっと心配になったのですが、とりあえず千枚のオーダーなら大丈夫だと分かって安心しました。^^;
🍘Re:4595◆doさんから「全てのてがろぐスキンをアップデートしました」というアナウンスが昨日に出ていましたね。とりあえず、最新版を使ってみて下さい。その上で同じ問題が出るようなら、まずは標準添付のスキン等を使って投稿が問題なく表示されることをご確認下さい。そこで問題がないようなら、
特に⑤の「投稿やギャラリーを表すタブをクリックしても」というのはスキン独自の機能でしょうから。なんとなく、JavaScriptが動いてなさそうなケースでそうなりそうに感じますので、何か必須のファイルが読み込めていないのでしょうね。その原因が、INCLUDEエラーなのでしょう。No.4598さんがお書きの通り、それは(スキン側で合成するよう指定されている)ファイルが合成できなかったときに出るエラーメッセージです。
🍘Re:4596,8◆サポートありがとうございます!
🍘Re:4597◆ご要望をどうもありがとうございます~。気長にお待ち頂ければ幸いです。
🍘Re:4599◆ご要望をありがとうございます。たしかに、各種モード用の名称を挿入する記法は特に用意していませんでしたね。簡単でしたので、こちらのローカルにあるソースでは実装しました。次に公開するバージョンからご使用頂けます。以下の3記法を新設しました。
🍘Re:4593◆ご回答ありがとうございます。遅くはなっていないようで安心しました。画像管理画面では、表示するたびに「実際に画像保存用ディレクトリに存在する全画像ファイルを走査して、更新日時等の情報を取得して、画像インデックスファイルを更新する」という処理をしているので、画像ファイルが多ければ多いほど作業量も増えるんですけども、1500枚くらいなら現実的に特に問題にはならないと知って安心しました。
◆【追記部分に対する返信】 なお、てがろぐでは、1回の通信で送信する総データサイズが30MBを超えた場合には通信を打ち切る仕様になっています。なので、大量の画像を一括アップロードすると、処理は成功せずにすべて無視されると思います。UPなさっている画像がだいたい「1枚あたり2MB」であれば、15枚くらいを超えると制限を超過しますね。(例えば、ほんの2~300KB程度の小さな画像で試すと、20枚とか30枚とかでも問題なく一括UPできるのではないかと思います。)
仮に、てがろぐ側で制限しなかったとしても、おそらくWebサーバ側でも(負荷軽減目的や悪意あるアップロード等を防ぐために)通信速度か何かの制限が掛かると思います。なので、サイズの大きな画像をたくさんUPする場合には、細かく刻んで下さい。(てがろぐ上で細かく刻むのが面倒な場合は、FTP等の別手段でUPして頂くのが良いと思います。)
🍘Re:4594◆ご回答ありがとうございます!(╹◡╹)ノ 元々、たくさんの画像をUPして管理することを想定していなかったので、ちょっと心配になったのですが、とりあえず千枚のオーダーなら大丈夫だと分かって安心しました。^^;
🍘Re:4595◆doさんから「全てのてがろぐスキンをアップデートしました」というアナウンスが昨日に出ていましたね。とりあえず、最新版を使ってみて下さい。その上で同じ問題が出るようなら、まずは標準添付のスキン等を使って投稿が問題なく表示されることをご確認下さい。そこで問題がないようなら、
- スキンをどのようにアップロードしたのか
- スキンをどのような操作で適用しているのか
特に⑤の「投稿やギャラリーを表すタブをクリックしても」というのはスキン独自の機能でしょうから。なんとなく、JavaScriptが動いてなさそうなケースでそうなりそうに感じますので、何か必須のファイルが読み込めていないのでしょうね。その原因が、INCLUDEエラーなのでしょう。No.4598さんがお書きの通り、それは(スキン側で合成するよう指定されている)ファイルが合成できなかったときに出るエラーメッセージです。
🍘Re:4596,8◆サポートありがとうございます!
🍘Re:4597◆ご要望をどうもありがとうございます~。気長にお待ち頂ければ幸いです。
🍘Re:4599◆ご要望をありがとうございます。たしかに、各種モード用の名称を挿入する記法は特に用意していませんでしたね。簡単でしたので、こちらのローカルにあるソースでは実装しました。次に公開するバージョンからご使用頂けます。以下の3記法を新設しました。
- [[GALLERY:NAME]] :ギャラリーモードの名称を挿入
- [[PICTS:NAME]] :画像一覧モードの名称を挿入
- [[SITEMAP:NAME]] :サイトマップページモードの名称を挿入
本日の昼食は、そばめし。
Ver 4.4.1(未配布)の動作テスト。
🍵Re:4590◆お役に立っているようで嬉しいです~。(╹◡╹)ノ
Ver 4.4.1(未配布)の動作テスト。
🍵Re:4590◆お役に立っているようで嬉しいです~。(╹◡╹)ノ
たこ焼きを食べました。6個。





🥞Re:4584◆ss1.xrea.com ドメインを使った、お使いのてがろぐのURL(例えば、https://ss1.xrea.com/ ID.SERVER.xrea.com /tegalog/tegalog.cgi 等)にアクセスした状態で、そこに見えているQUICKPOSTから投稿しても、同様のエラーが出ますか?
もしそうなら、お使いの環境では「閲覧者に向けてはhttpsの方を公開しておいて、自分だけはhttpの方を使う」という方法しかなさそうに思います。
---
> FAQの「fumycts.plを書き換える」で解決できるケースでしょうか?
> おすすめではないと書かれている点について、よければ詳しく教えていただけませんか?
お使いの状況では、fumycts.plを書き換える方法で解決してはいけません。(書き換えると、エラーは出なくなりますが。)
これは、フィッシング攻撃や、CSRF(クロスサイト・リクエスト・フォージェリ)攻撃を防ぐ機能の1つだからです。他所のWebサイトに攻撃用のページを作成しておいて、そこに何らかの方法であなた(=てがろぐにログインする権利を持った人物)を誘導した上で、その攻撃用ページから何らかの情報(ログイン情報なり投稿データなり設定変更情報なり)をてがろぐに向けて送信することで、パスワードを盗んだり変更したり、意図しない投稿をさせたり、意図しない設定変更をさせたりする……、というのを防ぐ機能です。
そのために、「そのてがろぐが稼働しているドメイン」ではないドメインから送られてきたリクエストは拒否する仕様になっています。
この機能を無効にしてしまうと、フィッシング攻撃やCSRF攻撃を防げなくなってしまいます。なので、一般のWeb上に公開されているてがろぐでは無効にしてはいけません。無効にする方法を用意しているのは、あくまでも「ローカルで稼働させている」とか「何らかの別のセキュリティで守られた空間で稼働させている」とか、第三者がアクセスすることはないと断言できる場所で稼働させている場合のためです。
なお、「例外のドメインを1つ設定できたら良いのでは?」と思われるかもしれませんが、今回の場合、もし ss1.xrea.com ドメインを例外として許容してしまうと、同じドメインの使用権を持つ他者からの攻撃が防げなくなる問題がありますので、そうはできないのです。
(根本的に解決するには、「自分だけが使えるサブドメイン」でhttpsを使わせてくれるサーバを使う、という手しかないと思います。)
🥞Re:4584◆ss1.xrea.com ドメインを使った、お使いのてがろぐのURL(例えば、https://ss1.xrea.com/ ID.SERVER.xrea.com /tegalog/tegalog.cgi 等)にアクセスした状態で、そこに見えているQUICKPOSTから投稿しても、同様のエラーが出ますか?
もしそうなら、お使いの環境では「閲覧者に向けてはhttpsの方を公開しておいて、自分だけはhttpの方を使う」という方法しかなさそうに思います。
---
> FAQの「fumycts.plを書き換える」で解決できるケースでしょうか?
> おすすめではないと書かれている点について、よければ詳しく教えていただけませんか?
お使いの状況では、fumycts.plを書き換える方法で解決してはいけません。(書き換えると、エラーは出なくなりますが。)
これは、フィッシング攻撃や、CSRF(クロスサイト・リクエスト・フォージェリ)攻撃を防ぐ機能の1つだからです。他所のWebサイトに攻撃用のページを作成しておいて、そこに何らかの方法であなた(=てがろぐにログインする権利を持った人物)を誘導した上で、その攻撃用ページから何らかの情報(ログイン情報なり投稿データなり設定変更情報なり)をてがろぐに向けて送信することで、パスワードを盗んだり変更したり、意図しない投稿をさせたり、意図しない設定変更をさせたりする……、というのを防ぐ機能です。
そのために、「そのてがろぐが稼働しているドメイン」ではないドメインから送られてきたリクエストは拒否する仕様になっています。
この機能を無効にしてしまうと、フィッシング攻撃やCSRF攻撃を防げなくなってしまいます。なので、一般のWeb上に公開されているてがろぐでは無効にしてはいけません。無効にする方法を用意しているのは、あくまでも「ローカルで稼働させている」とか「何らかの別のセキュリティで守られた空間で稼働させている」とか、第三者がアクセスすることはないと断言できる場所で稼働させている場合のためです。
なお、「例外のドメインを1つ設定できたら良いのでは?」と思われるかもしれませんが、今回の場合、もし ss1.xrea.com ドメインを例外として許容してしまうと、同じドメインの使用権を持つ他者からの攻撃が防げなくなる問題がありますので、そうはできないのです。
(根本的に解決するには、「自分だけが使えるサブドメイン」でhttpsを使わせてくれるサーバを使う、という手しかないと思います。)
昼食はピザ🍕
🍕Re:4578◆これは、No.4579さんがご説明下さった通りです。.htaccessファイルに DirectoryIndex tegalog.cgi とだけ書いた場合は、index.html とか index.htm とか index.php とかが同階層にあっても(ファイル名を省略したアクセスでは) tegalog.cgi だけしか表示されません。この場合、その階層から tegalog.cgi を削除しても、(ファイル名を省略したアクセスでは)403 Forbidden エラーになるかファイル一覧が出るかするだけで、(たとえその階層にindex.htmlが存在していても)index.htmlが表示に使われることはありません。
一般的なサーバでは「 index.html があればそれを表示し、なくても index.htm があればそれを表示し、それもなくても index.cgi があればそれを表示し……」みたいな感じになっていますが、それは、
DirectoryIndex index.html index.htm index.cgi index.php
……という感じのデフォルト設定になっているためです。(順序はこうではないかも。他にもindex.shtmlとかもっと多数含まれているかもしれません。)
なのでもし、てがろぐ設置ディレクトリの .htaccess ファイルに、
DirectoryIndex tegalog.cgi index.html
……と2つのファイル名を列挙しておいた場合は、(ファイル名を省略したアクセス時には)「 tegalog.cgi があればそれを表示し、ない場合には、index.html があればそれを表示する」というような動作になります。
ファイルが探される順番は、DirectoryIndex に並べた順番です。左側から順番にファイルを探して、最初に見つかったファイルが表示されるわけです。どれも見つからなかったら、403 Forbidden エラー(またはファイル一覧)が表示されます。
したがって、てがろぐ設置ディレクトリの .htaccess ファイルに、以下の順序で書いた場合は、
DirectoryIndex index.html tegalog.cgi
ファイル名を省略したアクセス時には、もし index.html ファイルがあれば(たとえ同時に tegalog.cgiも存在していても)index.htmlの方が表示されます。
🍕Re:4579◆サポートをどうもありがとうございます!(╹◡╹)ノ
🍕Re:4578◆これは、No.4579さんがご説明下さった通りです。.htaccessファイルに DirectoryIndex tegalog.cgi とだけ書いた場合は、index.html とか index.htm とか index.php とかが同階層にあっても(ファイル名を省略したアクセスでは) tegalog.cgi だけしか表示されません。この場合、その階層から tegalog.cgi を削除しても、(ファイル名を省略したアクセスでは)403 Forbidden エラーになるかファイル一覧が出るかするだけで、(たとえその階層にindex.htmlが存在していても)index.htmlが表示に使われることはありません。
一般的なサーバでは「 index.html があればそれを表示し、なくても index.htm があればそれを表示し、それもなくても index.cgi があればそれを表示し……」みたいな感じになっていますが、それは、
DirectoryIndex index.html index.htm index.cgi index.php
……という感じのデフォルト設定になっているためです。(順序はこうではないかも。他にもindex.shtmlとかもっと多数含まれているかもしれません。)
なのでもし、てがろぐ設置ディレクトリの .htaccess ファイルに、
DirectoryIndex tegalog.cgi index.html
……と2つのファイル名を列挙しておいた場合は、(ファイル名を省略したアクセス時には)「 tegalog.cgi があればそれを表示し、ない場合には、index.html があればそれを表示する」というような動作になります。
ファイルが探される順番は、DirectoryIndex に並べた順番です。左側から順番にファイルを探して、最初に見つかったファイルが表示されるわけです。どれも見つからなかったら、403 Forbidden エラー(またはファイル一覧)が表示されます。
したがって、てがろぐ設置ディレクトリの .htaccess ファイルに、以下の順序で書いた場合は、
DirectoryIndex index.html tegalog.cgi
ファイル名を省略したアクセス時には、もし index.html ファイルがあれば(たとえ同時に tegalog.cgiも存在していても)index.htmlの方が表示されます。
🍕Re:4579◆サポートをどうもありがとうございます!(╹◡╹)ノ
LOVE&PEACHフラペチーノを飲んできました。🍑🍑🍑
🍑Re:4566◆おっと。ご指摘をどうもありがとうございます。確かに、内側スキン(skin-onelog.html)の中でINCLUDE記法を使って挿入するファイルの中にIF文を書いてもIF文だとは認識されないですね。これは不具合でした。内側スキンでは、INCLUDE文を処理するよりも前の段階でIF文の解釈を済ませてしまっていたので、INCLUDEで合成されるファイルの中に書いたIF文が処理されないまま(文字としてそのまま)出力されてしまっていたのでした。
こちらのローカルにあるソースでは修正しましたので、次のバージョンでは解決しています。公開までしばらくお待ち下さい。
🍑Re:4567◆なるほど! 事情の解説をどうもありがとうございます。とても参考になりました。なんとなく「CGIを自力で設置しようと考える人なら、HTML+CSSくらいは読めるし書ける」というような前提で居た感じがあったんですけども(笑)、たしかに最近は(ありがたいことに)HTML+CSSがそんなに分からない状態でも、てがろぐを使おう、と考えて下さる方々も多々いらっしゃるようですね。もし、そういう方々の個人サイト開設の入口になれているならとても嬉しいです。(╹◡╹) (いや、入口になっているかどうかは分かりませんけども。WordPress等のCMSで既にサイト自体はあった可能性もありますしね。^^;)
さて、カテゴリ別の先頭固定機能は、あれば使い処はありそうですから、将来的には実装したいと思います。ただ、実装に掛かる分量が結構多そうなので、直近での実装ができるとは限りませんので、気長にお待ち頂ければ幸いです。
🍑Re:4566◆おっと。ご指摘をどうもありがとうございます。確かに、内側スキン(skin-onelog.html)の中でINCLUDE記法を使って挿入するファイルの中にIF文を書いてもIF文だとは認識されないですね。これは不具合でした。内側スキンでは、INCLUDE文を処理するよりも前の段階でIF文の解釈を済ませてしまっていたので、INCLUDEで合成されるファイルの中に書いたIF文が処理されないまま(文字としてそのまま)出力されてしまっていたのでした。
こちらのローカルにあるソースでは修正しましたので、次のバージョンでは解決しています。公開までしばらくお待ち下さい。
🍑Re:4567◆なるほど! 事情の解説をどうもありがとうございます。とても参考になりました。なんとなく「CGIを自力で設置しようと考える人なら、HTML+CSSくらいは読めるし書ける」というような前提で居た感じがあったんですけども(笑)、たしかに最近は(ありがたいことに)HTML+CSSがそんなに分からない状態でも、てがろぐを使おう、と考えて下さる方々も多々いらっしゃるようですね。もし、そういう方々の個人サイト開設の入口になれているならとても嬉しいです。(╹◡╹) (いや、入口になっているかどうかは分かりませんけども。WordPress等のCMSで既にサイト自体はあった可能性もありますしね。^^;)
さて、カテゴリ別の先頭固定機能は、あれば使い処はありそうですから、将来的には実装したいと思います。ただ、実装に掛かる分量が結構多そうなので、直近での実装ができるとは限りませんので、気長にお待ち頂ければ幸いです。
朝食はピザトースト。おなかいっぱい。ぐふぅ。_(:3」∠)_
🍕Re:4561◆ご要望をどうもありがとうございます。ちなみにですが、カテゴリ向けの注意書き用途なら、フリースペースを複数個用意しておいて、状況に応じて表示/非表示を切り替える方法を使って、『特定のカテゴリ(またはハッシュタグ)限定で表示される場合にだけ、n番のフリースペースを表示する』みたいな方法でも実現できると思いますが(しかもその方がHTMLを自由に書けるメリットもありますが)、それでもなお「カテゴリ別の先頭固定機能」の方が望ましいですか? もしそうなら、参考までに理由も教えて頂けると、今後の開発の参考になって助かりますのでよろしければ教えて下さい。
🍕Re:4562◆カテゴリ管理の概要文の入力欄がtextareaになったら……という点ですが、お望みの仕様は以下Ⓐ・Ⓑのどちらでしょうか?
🍕Re:4561◆ご要望をどうもありがとうございます。ちなみにですが、カテゴリ向けの注意書き用途なら、フリースペースを複数個用意しておいて、状況に応じて表示/非表示を切り替える方法を使って、『特定のカテゴリ(またはハッシュタグ)限定で表示される場合にだけ、n番のフリースペースを表示する』みたいな方法でも実現できると思いますが(しかもその方がHTMLを自由に書けるメリットもありますが)、それでもなお「カテゴリ別の先頭固定機能」の方が望ましいですか? もしそうなら、参考までに理由も教えて頂けると、今後の開発の参考になって助かりますのでよろしければ教えて下さい。
🍕Re:4562◆カテゴリ管理の概要文の入力欄がtextareaになったら……という点ですが、お望みの仕様は以下Ⓐ・Ⓑのどちらでしょうか?
- Ⓐ 入力欄が左右だけでなく上下にも広げられれば充分。
- Ⓑ 入力した改行も維持した状態で保存して欲しい。
今日は、バナナブリュレフラペチーノを飲んできました。🍧🍨🍌
🍨Re:4548◆はい。可能ですよ。画像の掲載記法を単に横に続けて書けば良いだけです。

ただ、キャプション付きで表示する場合は figure要素を使って出力されますので、何のCSSも適用されていない状態だと横には並びません。標準添付の各スキンなら横並びになるよう .embeddedpictbox に装飾を適用してありますが、1から自作するスキンの場合には自力で対処して頂く必要があります。(figure要素をinlineにするよう装飾すれば良いです。)

エアリアル しお味 
エアリアル 濃厚チェダーチーズ味
🍨Re:4548◆はい。可能ですよ。画像の掲載記法を単に横に続けて書けば良いだけです。


ただ、キャプション付きで表示する場合は figure要素を使って出力されますので、何のCSSも適用されていない状態だと横には並びません。標準添付の各スキンなら横並びになるよう .embeddedpictbox に装飾を適用してありますが、1から自作するスキンの場合には自力で対処して頂く必要があります。(figure要素をinlineにするよう装飾すれば良いです。)


今日は、冷凍餃子の備蓄を調達してきました。さらに冷蔵餃子も買ってきたのでそれは夕飯に食べました。🥟🥟🥟
🥟Re:4543◆今のところ、実装上の都合で「SITUATION:CLASS」にログイン有無のキーワードを加えられないのですが、何か良さげな実装方法を思いついた場合には考えます。ただ、おっしゃる通り、ログインしていなければ特に何も操作はできませんので、CSSが適用されなかった場合まで考慮する必要はないのではないかとは思います。
さて、スキンディレクトリ名の話ですが。なるほど、その場合は、
[[INCLUDE:head1.html]]
<link type="text/css" rel="stylesheet" href="スキン固有ファイル名.css">
[[INCLUDE:head2.html]]
……のように、ヘッダ用の共通ファイルを2つに分けて頂いて、CSSを読み込む行だけは各スキンに直接書いて頂くのが最も簡単な気がします。
なお、共通ファイルを2つに分けるのが嫌な場合は、先のJavaScriptでスキンディレクトリ名を変数 skinDirName に得ておいて、
document.write('<link type="text/css" rel="stylesheet" href="[[PATH:SKINDIR]]' + skinDirName + '.css">');
……のようなJavaScriptを使ってCSSファイルを読み込むという方法もあります。
もし、「今時 document.write はないのでは……」と思われる場合には、以下のようなモダンな書き方もできます。
let skincss = document.createElement('link');
skincss.rel = 'stylesheet';
skincss.type = 'text/css';
skincss.href = '[[PATH:SKINDIR]]' + skinDirName + '.css';
document.head.appendChild(skincss);
これで、スキンディレクトリ名のCSSファイルを読み込めます。
※JavaScriptでCSSを動的に読み込む場合は、てがろぐ側でのリンク自動調整機能が働きませんので、読み込むCSSファイルパスにはスキンディレクトリ([[PATH:SKINDIR]])も自力で加える必要があります。
畳む
🥟Re:4543◆今のところ、実装上の都合で「SITUATION:CLASS」にログイン有無のキーワードを加えられないのですが、何か良さげな実装方法を思いついた場合には考えます。ただ、おっしゃる通り、ログインしていなければ特に何も操作はできませんので、CSSが適用されなかった場合まで考慮する必要はないのではないかとは思います。
さて、スキンディレクトリ名の話ですが。なるほど、その場合は、
[[INCLUDE:head1.html]]
<link type="text/css" rel="stylesheet" href="スキン固有ファイル名.css">
[[INCLUDE:head2.html]]
……のように、ヘッダ用の共通ファイルを2つに分けて頂いて、CSSを読み込む行だけは各スキンに直接書いて頂くのが最も簡単な気がします。
なお、共通ファイルを2つに分けるのが嫌な場合は、先のJavaScriptでスキンディレクトリ名を変数 skinDirName に得ておいて、
document.write('<link type="text/css" rel="stylesheet" href="[[PATH:SKINDIR]]' + skinDirName + '.css">');
……のようなJavaScriptを使ってCSSファイルを読み込むという方法もあります。
もし、「今時 document.write はないのでは……」と思われる場合には、以下のようなモダンな書き方もできます。
let skincss = document.createElement('link');
skincss.rel = 'stylesheet';
skincss.type = 'text/css';
skincss.href = '[[PATH:SKINDIR]]' + skinDirName + '.css';
document.head.appendChild(skincss);
これで、スキンディレクトリ名のCSSファイルを読み込めます。
※JavaScriptでCSSを動的に読み込む場合は、てがろぐ側でのリンク自動調整機能が働きませんので、読み込むCSSファイルパスにはスキンディレクトリ([[PATH:SKINDIR]])も自力で加える必要があります。
畳む
ご要望を頂く際には、「それをどんなことに使うのか」も併せてお知らせ頂けると、検討なり方策の提示なりの参考になってありがたいです。
🧇Re:4541◆残念ながら、ログイン状況を示すキーワードはありません。ただ、この2条件が成立している状況なら、JavaScriptを使うことで判別は可能です。要は、CSSの中に .Login-Required という定義が存在するかどうかを調べれば良いので、以下のようなJavaScriptで調べられます。
for(let sheet of document.styleSheets) {
for(let rule of sheet.cssRules) {
if(rule.selectorText === '.Login-Required') {
// 非ログイン状態だと分かる
}
}
}
このJavaScriptを、QUICKPOSTの記述位置よりも後に書くか、もしくはページ読み込み完了後に実行されるように書けば、ログインされているかどうかを判別できます。
また、[[PATH:SKINDIR]]で得られる文字列から、スキンディレクトリ名だけを抜き出すには、以下のJavaScriptでできます。
function getLastPart(path) {
if(path.endsWith('/')) {
path = path.slice(0, -1);
}
const parts = path.split('/');
return parts[parts.length - 1];
}
let path = "[[PATH:SKINDIR]]";
let skinDirName = getLastPart(path));
このJavaScriptを使うと、変数 skinDirName には、スキンディレクトリ名だけが入ります。(もうちょっとスマートな方法があるかもしれませんが。^^;)
例えば、[[PATH:SKINDIR]]が/path/to/directory/なら、変数skinDirName にはdirectoryだけが入ります。
🧇Re:4541◆残念ながら、ログイン状況を示すキーワードはありません。ただ、この2条件が成立している状況なら、JavaScriptを使うことで判別は可能です。要は、CSSの中に .Login-Required という定義が存在するかどうかを調べれば良いので、以下のようなJavaScriptで調べられます。
for(let sheet of document.styleSheets) {
for(let rule of sheet.cssRules) {
if(rule.selectorText === '.Login-Required') {
// 非ログイン状態だと分かる
}
}
}
このJavaScriptを、QUICKPOSTの記述位置よりも後に書くか、もしくはページ読み込み完了後に実行されるように書けば、ログインされているかどうかを判別できます。
また、[[PATH:SKINDIR]]で得られる文字列から、スキンディレクトリ名だけを抜き出すには、以下のJavaScriptでできます。
function getLastPart(path) {
if(path.endsWith('/')) {
path = path.slice(0, -1);
}
const parts = path.split('/');
return parts[parts.length - 1];
}
let path = "[[PATH:SKINDIR]]";
let skinDirName = getLastPart(path));
このJavaScriptを使うと、変数 skinDirName には、スキンディレクトリ名だけが入ります。(もうちょっとスマートな方法があるかもしれませんが。^^;)
例えば、[[PATH:SKINDIR]]が/path/to/directory/なら、変数skinDirName にはdirectoryだけが入ります。
冷凍餃子と冷凍たこ焼きの備蓄が尽きました。また買ってこなくては……。


🥟Re:4532◆ダークモードのご要望もちらほら頂くのでなんとかしたい気はあるのですけども、元々そこまで大きく配色を可変にすることを前提にしないまま製作してきたために、書き換えないといけないCSS量が多いので先送りになっております。とりあえず現時点では、ユーザスタイルシートをご活用頂くか、いい感じにダークモードで表示してくれるアドオンをお使い頂ければ幸いです。関連情報として、No.4488,4489,4490,4493 あたりもご参照下さい。
🥟Re:4532◆ダークモードのご要望もちらほら頂くのでなんとかしたい気はあるのですけども、元々そこまで大きく配色を可変にすることを前提にしないまま製作してきたために、書き換えないといけないCSS量が多いので先送りになっております。とりあえず現時点では、ユーザスタイルシートをご活用頂くか、いい感じにダークモードで表示してくれるアドオンをお使い頂ければ幸いです。関連情報として、No.4488,4489,4490,4493 あたりもご参照下さい。
抹茶小豆棒アイスを補充しました。
🍵Re:4518◆先程に公開した Ver 4.3.2β で解決しましたので、ご試用頂ければ幸いです。(╹◡╹)
🍵Re:4518◆先程に公開した Ver 4.3.2β で解決しましたので、ご試用頂ければ幸いです。(╹◡╹)
今日も暑そう……?🍧🍧🍧
🍧Re:4516◆そういえば、パーセントエンコーディングされた文字列の存在を考慮していなかったようです。IF文として成立する条件の文字列の中に % 記号が含まれていませんでした。^^; ソースを確認したところ、英数字・空白文字・3記号(-_|)しかIF文の中に書けない仕様になっていましたので、これは不具合ですね。次のバージョンで修正しますので、もうしばらくお待ち願います。(今の時点では、パーセントエンコーディングで記述された名称は何でもIF文には使えません。^^;;;)ご報告をありがとうございます。(╹◡╹)ノ
※今のバージョンで今すぐ対処なさりたい場合は、IF文ではなく、CSSを使って表示/非表示を切り替えて下さい。
🍧Re:4516◆そういえば、パーセントエンコーディングされた文字列の存在を考慮していなかったようです。IF文として成立する条件の文字列の中に % 記号が含まれていませんでした。^^; ソースを確認したところ、英数字・空白文字・3記号(-_|)しかIF文の中に書けない仕様になっていましたので、これは不具合ですね。次のバージョンで修正しますので、もうしばらくお待ち願います。(今の時点では、パーセントエンコーディングで記述された名称は何でもIF文には使えません。^^;;;)ご報告をありがとうございます。(╹◡╹)ノ
※今のバージョンで今すぐ対処なさりたい場合は、IF文ではなく、CSSを使って表示/非表示を切り替えて下さい。