てがろぐ
- Fumy Otegaru Memo Logger -
カテゴリ「情報」に属する投稿［41件］
てがろぐベースで開発した、スキン式で自由に装飾できるスケジュール・カレンダー表示フリーCGI「さんごよみ」Ver 2.0.0をリリースしました。
ログインセキュリティ機能、カスタム絵文字機能、リンク・文字装飾記法の仕様拡充など、てがろぐ側にある便利機能をこちらにも実装しました。あと、若干の不具合修正も。
さんごよみをお使いの方は、ぜひバージョンアップして下さい。
設定もデータもすべてそのまま引き継げます。
バージョンアップするには、パッケージZIPから sangoyomi.cgi と fumycts.pl の2ファイルを上書きUPするだけです。
ヘルプドキュメントも増量して、てがろぐサイトと同様に、セットアップ(設置)方法・使い方・設定方法・カスタマイズ方法ページを個別に設けました。
さんごよみは（てがろぐCGIをベースにして作ったので）てがろぐと仕様がかなり共通しています。てがろぐをカスタマイズした経験があれば、さんごよみのスキンカスタマイズも難なくできるだろうと思います。
ログインセキュリティ機能、カスタム絵文字機能、リンク・文字装飾記法の仕様拡充など、てがろぐ側にある便利機能をこちらにも実装しました。あと、若干の不具合修正も。
さんごよみをお使いの方は、ぜひバージョンアップして下さい。
設定もデータもすべてそのまま引き継げます。
バージョンアップするには、パッケージZIPから sangoyomi.cgi と fumycts.pl の2ファイルを上書きUPするだけです。
ヘルプドキュメントも増量して、てがろぐサイトと同様に、セットアップ(設置)方法・使い方・設定方法・カスタマイズ方法ページを個別に設けました。
さんごよみは（てがろぐCGIをベースにして作ったので）てがろぐと仕様がかなり共通しています。てがろぐをカスタマイズした経験があれば、さんごよみのスキンカスタマイズも難なくできるだろうと思います。
スキンのカスタマイズがうまくいかない場合のご質問をしようとするすべての方へのお願いですが、質問する前に、
もし標準スキンではうまくいくなら、お使いのスキンの問題です。
その場合は、「スキンのソース全体」や「稼働しているページ」を一緒に見せて頂かないと何も判断ができない可能性があります。
また、第三者が作成なさったスキン独自の機能に関するご質問は、まずはそのスキンの作者さんへお願いします。（※「○○で配布されているスキンに変えたら、××が適用されなくなった」というような感じのご質問は特に。）
- その「うまくいかない方法」を、標準スキンに書いても同様にうまくいかないのか？
もし標準スキンではうまくいくなら、お使いのスキンの問題です。
その場合は、「スキンのソース全体」や「稼働しているページ」を一緒に見せて頂かないと何も判断ができない可能性があります。
また、第三者が作成なさったスキン独自の機能に関するご質問は、まずはそのスキンの作者さんへお願いします。（※「○○で配布されているスキンに変えたら、××が適用されなくなった」というような感じのご質問は特に。）
あんまり詳しくは検証していないんですが、現在のてがろぐの仕様では、
カテゴリは専用項目で分類できるのに対して、ハッシュタグは本文全体の中身を走査しないと分類できないので、負荷がずいぶん異なります。
ハッシュタグがたくさんある場合に重たくなるのは主に「ハッシュタグを集計するタイミング」なので、たとえハッシュタグを使う場合でも、下図のように集計しない設定にしておけば、重たくなるのを回避できます。（たぶん）
ハッシュタグの集計をしない設定
※この設定をしていても、その下にある『本文中のハッシュタグをリンクにする』項目の方がONなら、ハッシュタグそのものは機能します。（単に個数を数えなくなるだけです。）
- ハッシュタグの数が多いと重たくなりやすい
カテゴリは専用項目で分類できるのに対して、ハッシュタグは本文全体の中身を走査しないと分類できないので、負荷がずいぶん異なります。
ハッシュタグがたくさんある場合に重たくなるのは主に「ハッシュタグを集計するタイミング」なので、たとえハッシュタグを使う場合でも、下図のように集計しない設定にしておけば、重たくなるのを回避できます。（たぶん）
※この設定をしていても、その下にある『本文中のハッシュタグをリンクにする』項目の方がONなら、ハッシュタグそのものは機能します。（単に個数を数えなくなるだけです。）
てがろぐCGIの画像保存用ディレクトリに、画像ファイルを凄まじく大量に（数万ファイルとか）入れると動作が極端に重たくなる可能性があるんですが、その原因と回避方法を紹介してみました。
➡ てがろぐ上で多量の画像を扱う際に、重たくなるのを防ぐ方法
Twitterアーカイブの移行とかで重たくなった場合に確認してみて下さい。
➡ てがろぐ上で多量の画像を扱う際に、重たくなるのを防ぐ方法
Twitterアーカイブの移行とかで重たくなった場合に確認してみて下さい。
てがろぐ上に数百ページを超えるページがあるとき、ページ番号リンクを（省略せずに）全量出力する設定にしているととても動作が遅くなる問題がありましたが、こちらのローカルにあるソースでは解決しましたので、次のバージョン(β版)からは（たとえ数百ページを超えるページがあっても）遅くならなくなります。
※現状でその問題に直面している場合は、とりあえず [ページの表示]→【ナビゲーションリンクの表示】→[▼ページ番号リンク]→「総ページ数が多ければ途中のページ番号リンクを省略する」をONにして頂けば遅くならずに済みます。
※現状でその問題に直面している場合は、とりあえず [ページの表示]→【ナビゲーションリンクの表示】→[▼ページ番号リンク]→「総ページ数が多ければ途中のページ番号リンクを省略する」をONにして頂けば遅くならずに済みます。
これはめちゃくちゃ便利！
Twitter側の出力機能でダウンロードしたTwitter過去ログを、全部てがろぐ形式に変換してくれるスクリプト。
2022年出力のTwitterログでも問題なく変換できました。
元データに3.6万ツイート含まれていて、リツイートを除いた2.5万ツイートでも、1秒掛からずに変換できた感じです。tweets_mediaフォルダをコピー（して images フォルダにリネームすると）ツイート本文中の画像もちゃんと表示できました。すごい。
ぜひ試してみて下さい。
※ツイート数が多い場合は、てがろぐ側で事前に以下のどちらかの設定をしておく方が良さそうです。
なお、私が試してみた感じでは、
ただ、その辺は、生成された twitega.xml をテキストエディタで一括処理することで調整可能ですけども。
Twitter側の出力機能でダウンロードしたTwitter過去ログを、全部てがろぐ形式に変換してくれるスクリプト。
（ツイート埋め込み処理中...）Twitterで見る
2022年出力のTwitterログでも問題なく変換できました。
元データに3.6万ツイート含まれていて、リツイートを除いた2.5万ツイートでも、1秒掛からずに変換できた感じです。tweets_mediaフォルダをコピー（して images フォルダにリネームすると）ツイート本文中の画像もちゃんと表示できました。すごい。
ぜひ試してみて下さい。
※ツイート数が多い場合は、てがろぐ側で事前に以下のどちらかの設定をしておく方が良さそうです。
- [ページの表示]→【ナビゲーションリンクの表示】→[▼ページ番号リンク]→「総ページ数が多ければ途中のページ番号リンクを省略する」をONにしておく。
- [ページの表示]→【ページの表示／全体】→「▼1ページあたりの表示投稿数」を200とか400とか多めにして、総ページ数が莫大にならないような値にする。
なお、私が試してみた感じでは、
- てがろぐのハッシュタグの仕様は、 # 記号の直前の文字が「英数字・&記号・スラッシュ記号・セミコロン記号」だとハッシュタグだとは認識されないので、本文末尾に自動付加されるハッシュタグの直前には空白文字を1つ入れてくれると望ましいかも。
- 投稿末尾に挿入される画像が行内にあるので、画像の直前に改行を入れてくれると見やすくなって嬉しいかも。
ただ、その辺は、生成された twitega.xml をテキストエディタで一括処理することで調整可能ですけども。
てがろぐ本体を1クリックでバージョンアップできるツール「TegUp」の専用ページを（ようやく）作りまして、機能をちょっとだけ増やしたのを先程 Ver 1.0.0 として公開しました。
➡ TegUp ：てがろぐ本体を《1クリック》だけでバージョンアップできるPHPスクリプト
従来のpixivFanbox上の公開ページからはダウンロードできませんので、今後は上記の専用ページからダウンロードして下さい。（というか、次のてがろぐ正式版からは、tegup.phpも同梱する予定ですが。）
※Ver 0.9.0からは、『作業ログをファイルに出力できるオプション』機能だけが加わっていますが、既に Ver 0.9.0 が問題なく使えているなら作業ログをファイルに出力する必要性はありませんから、TegUp自体を更新する必要性は特にありません。^^;（そのまま Ver 0.9.0 を引き続きお使い頂いても問題なく（てがろぐを）バージョンアップできます。）
以前に TegUp を使おうとして、何らかのエラーが出て使えなかった場合は、『作業ログをファイルに出力できるオプション』をONにした上で動作を試してみて下さい。もちろん以前と同様に動かないでしょうけども、作業ログがファイルに出力されていますので、それを見ると、どこの作業が失敗しているのかが把握できると思います。
詳しい設定方法は、「作業ログをファイルにも出力したい場合」をご覧下さい。
なんか「専用ページを作ろう」と思ったらいろいろ書かないといけない気になってしまったのでそこそこな分量がありますけども、ほぼ何も読まなくても使えます。
要は、tegup.php を tegalog.cgi と同じディレクトリにアップロードすれば良いだけです。
➡ TegUp ：てがろぐ本体を《1クリック》だけでバージョンアップできるPHPスクリプト
従来のpixivFanbox上の公開ページからはダウンロードできませんので、今後は上記の専用ページからダウンロードして下さい。（というか、次のてがろぐ正式版からは、tegup.phpも同梱する予定ですが。）
※Ver 0.9.0からは、『作業ログをファイルに出力できるオプション』機能だけが加わっていますが、既に Ver 0.9.0 が問題なく使えているなら作業ログをファイルに出力する必要性はありませんから、TegUp自体を更新する必要性は特にありません。^^;（そのまま Ver 0.9.0 を引き続きお使い頂いても問題なく（てがろぐを）バージョンアップできます。）
以前に TegUp を使おうとして、何らかのエラーが出て使えなかった場合は、『作業ログをファイルに出力できるオプション』をONにした上で動作を試してみて下さい。もちろん以前と同様に動かないでしょうけども、作業ログがファイルに出力されていますので、それを見ると、どこの作業が失敗しているのかが把握できると思います。
詳しい設定方法は、「作業ログをファイルにも出力したい場合」をご覧下さい。
なんか「専用ページを作ろう」と思ったらいろいろ書かないといけない気になってしまったのでそこそこな分量がありますけども、ほぼ何も読まなくても使えます。
要は、tegup.php を tegalog.cgi と同じディレクトリにアップロードすれば良いだけです。
押し入れから扇風機を出してきました。
🍨Re:4471◆隠された範囲をSmooth展開するのは、現状のてがろぐの仕様で可能でしょうかね……？（どなたか実現なさっている方がいらっしゃったら教えて下さい！）なんとなく難しそうな気がします。デフォルト設定では、隠された範囲(のspan要素)は表示時に display:inline; のスタイルが付加されますしね（その値は設定で変更可能ですが）。
◆現状のような「JavaScriptで表示/非表示を切り替える」方法で隠す手段以外に、現在で(たぶん)主流な <details><summary>見せる部分</summary>折りたたむ部分</details> のようにHTMLだけで実現できる折り畳み機能で出力される記法も追加した方が良いかな……という気はなんとなくしています。今のところそのような要望は来ていないので、まだ「なんとなく思っているだけ」の状態ですけども。そちらの方がCSS（やJavaScript）で装飾しやすいだろうな、という気はします。
◆SNSシェアボタンで「特定のスキンを適用したURL」がシェアされるようにするには、[[PERMAURL]]系の記法の直後に（空白を挟まずに）&skin=skin-nameのような感じでパラメータを加えれば良いだけです。具体的にどのように書けば良いかは、お使いの「シェアボタン」の仕様次第ですので、（具体的な記述も知りたい場合は）まず現状の記述がどうなっているのかをお知らせ頂く必要があります。
🍨Re:4472◆てがろぐをご活用下さってありがとうございます。(╹◡╹)ﾉ
少なくとも（私が直接使っている範囲では）5千件や1万件程度の投稿総数では特に体感できるほどの変化は出ていません。
なお、今ご覧になっているこの動作試験場では、現状で4,350件近くの投稿数がありますので、実際に「5千件近くの投稿がある状態の動作」をご体感頂けています。(╹◡╹)
下記のⒶとⒷは私(だけ)が書いているページ（てがろぐ）で、Ⓒはここです。それぞれの大まかな総投稿数とデータサイズを調べてみました。
実際に生成ページにアクセスしてみると、投稿総数が1万2千件を超えているⒶよりも、わずか43件しかないⒷの方が、むしろ表示までにかかる動作は比較的もっさりしている気がしませんか？ これは、Ⓑでは文字装飾記法が山ほど使われているために（てがろぐ内部で）独自記法をHTMLに展開する処理がたくさん発生するためだろうな……という気がしています。まあ、Ⓑはさすがに『1投稿に2万文字近くある』ような長文投稿ばかりなので、かなり極端な例ですが。(笑)
なお、管理画面の応答速度は、ⒶⒷⒸどれも同じ感じです。（ミリ秒単位で計測したら何らかの差はあるかもしれませんが、体感できるほどの差はありません。）
ただ、CGIなので、動作の重たさは『アクセスがどれくらい集中するか』の方が影響すると思います。
Botからの大量アクセスを受けると、あっという間に重たくなるケースはありました。
てがろぐは、ページを生成する際に(毎回)データファイルを全部読み込みますので、毎秒数十件みたいな極めて高い頻度でのアクセスが続いてしまうと、サーバ自体がかなり重たくなりますね。（その辺は、サーバ側の性能にも影響するとは思いますが。）
なので、アクセス数が多いサイトの場合は特にWAF（Web Application Firewall）を併用して、悪質なBotは（CGIに届く前にサーバ側で）排除される環境にしておく方が望ましいです。
というわけで、てがろぐは（データベースを使っていないシステムなので、極端にデータサイズが大きくなればそれに比例して重たくなるだろうと予想はしているのですけども）、1万2千件程度の投稿数なら特に気にならない、とは言えそうです。10万件だとどうなるのかはまだ分かりませんが。^^;（上記で述べたとおり、投稿の内容次第でもあります。）
投稿総数が莫大になる予想があるのであれば、その「即メモ」と「ライフログ」は、1つのてがろぐで運営するのではなく、最初から複数個のてがろぐに分散させておくと、なお安心かもしれません。
（とはいえ、1つのてがろぐで運営していた内容を、後から複数のてがろぐに分割するのは、テキストエディタでデータファイルを直接分離すれば簡単ですが。どの投稿をどこに分けるのかを判断しやすくするために、カテゴリ等を使って事前に分類されていると望ましいですね。）
🍨Re:4471◆隠された範囲をSmooth展開するのは、現状のてがろぐの仕様で可能でしょうかね……？（どなたか実現なさっている方がいらっしゃったら教えて下さい！）なんとなく難しそうな気がします。デフォルト設定では、隠された範囲(のspan要素)は表示時に display:inline; のスタイルが付加されますしね（その値は設定で変更可能ですが）。
◆現状のような「JavaScriptで表示/非表示を切り替える」方法で隠す手段以外に、現在で(たぶん)主流な <details><summary>見せる部分</summary>折りたたむ部分</details> のようにHTMLだけで実現できる折り畳み機能で出力される記法も追加した方が良いかな……という気はなんとなくしています。今のところそのような要望は来ていないので、まだ「なんとなく思っているだけ」の状態ですけども。そちらの方がCSS（やJavaScript）で装飾しやすいだろうな、という気はします。
◆SNSシェアボタンで「特定のスキンを適用したURL」がシェアされるようにするには、[[PERMAURL]]系の記法の直後に（空白を挟まずに）&skin=skin-nameのような感じでパラメータを加えれば良いだけです。具体的にどのように書けば良いかは、お使いの「シェアボタン」の仕様次第ですので、（具体的な記述も知りたい場合は）まず現状の記述がどうなっているのかをお知らせ頂く必要があります。
🍨Re:4472◆てがろぐをご活用下さってありがとうございます。(╹◡╹)ﾉ
少なくとも（私が直接使っている範囲では）5千件や1万件程度の投稿総数では特に体感できるほどの変化は出ていません。
なお、今ご覧になっているこの動作試験場では、現状で4,350件近くの投稿数がありますので、実際に「5千件近くの投稿がある状態の動作」をご体感頂けています。(╹◡╹)
下記のⒶとⒷは私(だけ)が書いているページ（てがろぐ）で、Ⓒはここです。それぞれの大まかな総投稿数とデータサイズを調べてみました。
- Ⓐ 今日のひとことログ ：総投稿数 12,200件超 データファイル 6.27MB
- Ⓑ てがろぐリリースノート ：総投稿数 43件 データファイル 0.61MB
- Ⓒ 動作試験場（ここ） ：総投稿数 4,300件超 データファイル 2.94MB
実際に生成ページにアクセスしてみると、投稿総数が1万2千件を超えているⒶよりも、わずか43件しかないⒷの方が、むしろ表示までにかかる動作は比較的もっさりしている気がしませんか？ これは、Ⓑでは文字装飾記法が山ほど使われているために（てがろぐ内部で）独自記法をHTMLに展開する処理がたくさん発生するためだろうな……という気がしています。まあ、Ⓑはさすがに『1投稿に2万文字近くある』ような長文投稿ばかりなので、かなり極端な例ですが。(笑)
なお、管理画面の応答速度は、ⒶⒷⒸどれも同じ感じです。（ミリ秒単位で計測したら何らかの差はあるかもしれませんが、体感できるほどの差はありません。）
ただ、CGIなので、動作の重たさは『アクセスがどれくらい集中するか』の方が影響すると思います。
Botからの大量アクセスを受けると、あっという間に重たくなるケースはありました。
てがろぐは、ページを生成する際に(毎回)データファイルを全部読み込みますので、毎秒数十件みたいな極めて高い頻度でのアクセスが続いてしまうと、サーバ自体がかなり重たくなりますね。（その辺は、サーバ側の性能にも影響するとは思いますが。）
なので、アクセス数が多いサイトの場合は特にWAF（Web Application Firewall）を併用して、悪質なBotは（CGIに届く前にサーバ側で）排除される環境にしておく方が望ましいです。
というわけで、てがろぐは（データベースを使っていないシステムなので、極端にデータサイズが大きくなればそれに比例して重たくなるだろうと予想はしているのですけども）、1万2千件程度の投稿数なら特に気にならない、とは言えそうです。10万件だとどうなるのかはまだ分かりませんが。^^;（上記で述べたとおり、投稿の内容次第でもあります。）
投稿総数が莫大になる予想があるのであれば、その「即メモ」と「ライフログ」は、1つのてがろぐで運営するのではなく、最初から複数個のてがろぐに分散させておくと、なお安心かもしれません。
（とはいえ、1つのてがろぐで運営していた内容を、後から複数のてがろぐに分割するのは、テキストエディタでデータファイルを直接分離すれば簡単ですが。どの投稿をどこに分けるのかを判断しやすくするために、カテゴリ等を使って事前に分類されていると望ましいですね。）
てがろぐCGIにちょいとバグがありましたので、詳細や回避方法をブログに書きました。
➡『てがろぐに「簡易適用スキン」の設定が勝手に切り替わるバグがあった話』
簡単に述べると、以下の2条件を同時に満たしている場合にだけ、表示上の問題が発生します。
なので、予約投稿機能をOFFにしているなら（※デフォルトでOFFです）全く問題は生じません。
次のバージョンで修正しますが、上記の2条件に現状で該当する場合には、一時的に予約投稿機能をOFFにしておくことをお勧め致します。
詳しくは上記の記事本文をご覧下さい。
ただ、Ver 4.0.0（※β版も含めると、Ver 3.9.3β）以降で発生していたバグですので、昨年の4月の時点で既に存在していたバグですから、『今まで問題がなかったなら、たぶん問題ない』と考えても良いとは思います。（1年間も問題が生じなかったわけですから。）
畳む
とりあえず、バグを解消した次のバージョン（4.3.1）は、おそらく今月末までには公開できると思っています。（今のところ）
➡『てがろぐに「簡易適用スキン」の設定が勝手に切り替わるバグがあった話』
簡単に述べると、以下の2条件を同時に満たしている場合にだけ、表示上の問題が発生します。
- 【条件①】未来の日時を『予約投稿として扱う』よう設定されている。（＝予約投稿機能をONに設定している）
- 【条件②】メインで使うスキン以外のスキンに、新着投稿リストを表示するための記法 [[LATESTLIST]] が記述されている。（＝メインで使うスキン以外のスキンで生成されるページ上に、新着投稿リストが表示されている）
なので、予約投稿機能をOFFにしているなら（※デフォルトでOFFです）全く問題は生じません。
次のバージョンで修正しますが、上記の2条件に現状で該当する場合には、一時的に予約投稿機能をOFFにしておくことをお勧め致します。
詳しくは上記の記事本文をご覧下さい。
ただ、Ver 4.0.0（※β版も含めると、Ver 3.9.3β）以降で発生していたバグですので、昨年の4月の時点で既に存在していたバグですから、『今まで問題がなかったなら、たぶん問題ない』と考えても良いとは思います。（1年間も問題が生じなかったわけですから。）
畳む
とりあえず、バグを解消した次のバージョン（4.3.1）は、おそらく今月末までには公開できると思っています。（今のところ）
てがろぐセットアップ方法のレンタルサーバ別解説リストに、「ConoHa WING」を追加しました。
追加しました、と言っても特別なことはなく、単に全ファイルをUPして、指定のパーミッションに設定するだけですけども。（要するに、ノーマルな設置方法で済む、という話です。^^;）
追加しました、と言っても特別なことはなく、単に全ファイルをUPして、指定のパーミッションに設定するだけですけども。（要するに、ノーマルな設置方法で済む、という話です。^^;）
フリースペース機能を使えば、ページ上の好きな位置に好きな内容を（てがろぐ管理画面上から再編集できる形で）掲載できます。#🌱豆知識
先頭固定機能だと掲載位置は先頭しかあり得ませんが、フリースペースなら上端でも下端でもサイドバーの形でもどこにでも表示できますので、掲載位置の自由度は（先頭固定よりも）高いです。その上、（スキンを直接編集しなくても）てがろぐ上から中身を更新できます。また、フリースペースの内部にはHTMLタグを何でも使えますから、掲載内容の自由度も高いです。
最近はサードパーティー製スキンをベースにしてお使いの方々も多そうですので、もしかすると（フリースペースが使われていないスキンをお使いだと）フリースペース機能の存在に気付きにくいかもしれませんが。
「何かをずっと表示しておきたい」という場合には、先頭固定機能以外にもフリースペース機能もありますので、それを使えないか検討してみて下さい。
例えば、「ある特定のカテゴリに限定されている状況でのみ、フリースペースを表示させたい」という場合には、IF文での出力条件分け記法を使ってフリースペースの表示場面を限定すると良いでしょう。フリースペースの入力欄は1つしかありませんが、専用の区切り文字を使うことで、複数のフリースペースを用意することもできます。詳しくは『フリースペースの書き方（複数のフリースペースを設ける方法）』で解説しています。
この「IF文」と「フリースペース」を併用すれば、
※IF文を使わなくても、単純にCSSで表示分けすることもできます。掲載分量が少ない場合には、（IF文を列挙してどうにかするよりも）CSSで表示分けする方がシンプルで楽かもしれません。
先頭固定機能だと掲載位置は先頭しかあり得ませんが、フリースペースなら上端でも下端でもサイドバーの形でもどこにでも表示できますので、掲載位置の自由度は（先頭固定よりも）高いです。その上、（スキンを直接編集しなくても）てがろぐ上から中身を更新できます。また、フリースペースの内部にはHTMLタグを何でも使えますから、掲載内容の自由度も高いです。
最近はサードパーティー製スキンをベースにしてお使いの方々も多そうですので、もしかすると（フリースペースが使われていないスキンをお使いだと）フリースペース機能の存在に気付きにくいかもしれませんが。
「何かをずっと表示しておきたい」という場合には、先頭固定機能以外にもフリースペース機能もありますので、それを使えないか検討してみて下さい。
例えば、「ある特定のカテゴリに限定されている状況でのみ、フリースペースを表示させたい」という場合には、IF文での出力条件分け記法を使ってフリースペースの表示場面を限定すると良いでしょう。フリースペースの入力欄は1つしかありませんが、専用の区切り文字を使うことで、複数のフリースペースを用意することもできます。詳しくは『フリースペースの書き方（複数のフリースペースを設ける方法）』で解説しています。
この「IF文」と「フリースペース」を併用すれば、
- カテゴリ info でのみ表示されるフリースペースⒶ
- カテゴリ diary でのみ表示されるフリースペースⒷ
- HOMEでのみ表示されるフリースペースⒸ
※IF文を使わなくても、単純にCSSで表示分けすることもできます。掲載分量が少ない場合には、（IF文を列挙してどうにかするよりも）CSSで表示分けする方がシンプルで楽かもしれません。
てがろぐCGIをリトルサーバーで動かす際には、tegalog.cgiのパーミッションは 704 にすると良い話を、リトルサーバーでのセットアップ手順ページに追記しておきました。
パーミッション 700 でも動作に支障はないんですが、700だと mod_mime_magic: can't read ～tegalog.cgi というエラーが毎回エラーログに記録されてしまいますので。（余計なログは出力されないに越したことはありませんから。）
パーミッション 700 でも動作に支障はないんですが、700だと mod_mime_magic: can't read ～tegalog.cgi というエラーが毎回エラーログに記録されてしまいますので。（余計なログは出力されないに越したことはありませんから。）
Ver 4.1.4βで実装したIF文の用途で、（あまりそうする需要はないんじゃないかな、とは思うのですけども）気付いたので一応解説しておきます。
IF文の条件指定は（全文検索機能と同様に）「完全一致」ではなく「部分一致」で解釈されますので、
「1件以上が表示される場合」に限定しようとして [[IF(hit):～～～ のように書いたとしても、 「1件もヒットしなかった場合」の nohit にも同時に該当してしまうために意味がありません。^^;
なので、もし「1件以上が表示される場合」に限定したい場合は、[[IF(hit -nohit):～～～ のように、マイナス記号を付けて「-nohit」として除外する条件を同時に加える必要があります。
……という話を、一応ヘルプドキュメントにも加えておきました。
➡そのときの表示状況に応じてページ出力を、IF文で切り替える方法
IF文の条件指定は（全文検索機能と同様に）「完全一致」ではなく「部分一致」で解釈されますので、
「1件以上が表示される場合」に限定しようとして [[IF(hit):～～～ のように書いたとしても、 「1件もヒットしなかった場合」の nohit にも同時に該当してしまうために意味がありません。^^;
なので、もし「1件以上が表示される場合」に限定したい場合は、[[IF(hit -nohit):～～～ のように、マイナス記号を付けて「-nohit」として除外する条件を同時に加える必要があります。
……という話を、一応ヘルプドキュメントにも加えておきました。
➡そのときの表示状況に応じてページ出力を、IF文で切り替える方法
（これまで問題なく稼働していた）てがろぐにアクセスしたときに、503 Service Unavailable エラーに遭遇した場合は、サーバのコントロールパネル等からアクセスログを見て、Botからの大量アクセスを受けていないか確認してみて下さい。（てがろぐに限りませんが）CGIに毎秒毎秒アクセスされるような高頻度なアクセスがあるとサーバ負荷が高まってしまって、過負荷で 503エラーになることがあります。もしBotからの大量アクセスがあるようなら、.htaccessファイルを使って、そのBotからのアクセスを弾くとか、（robots.txtを読んでくれる紳士的なBotなら）robots.txtでクロール頻度を下げたりブロックしたりするなどの対処をする方が望ましいでしょう。（ずっと503エラーが続くなら対処が必要です。）
先日、うちのサイトでも複数のBotから莫大なアクセスがあって（※てがろぐだけにあったわけではなくてサイト全体にあったんですが）、CGIにも高い頻度でのアクセスがあったためかサーバの負荷が高まって、てがろぐの管理画面を表示するだけでも20秒とか掛かるようになってしまったことがありました。（503エラーになるほどではなかったのですが。ただ、どのくらいの負荷まで許容してくれるかはサーバや契約コースに依ると思います。） その話は改めてブログに書こうかと思っているのですが。.htaccessやrobots.txtを併用してBotのアクセス頻度を低下させたことで、普通の状態に戻りましたけども、何もしなかったら過負荷なままだったのではないかと思います。
先日、うちのサイトでも複数のBotから莫大なアクセスがあって（※てがろぐだけにあったわけではなくてサイト全体にあったんですが）、CGIにも高い頻度でのアクセスがあったためかサーバの負荷が高まって、てがろぐの管理画面を表示するだけでも20秒とか掛かるようになってしまったことがありました。（503エラーになるほどではなかったのですが。ただ、どのくらいの負荷まで許容してくれるかはサーバや契約コースに依ると思います。） その話は改めてブログに書こうかと思っているのですが。.htaccessやrobots.txtを併用してBotのアクセス頻度を低下させたことで、普通の状態に戻りましたけども、何もしなかったら過負荷なままだったのではないかと思います。
てがろぐ本体を1クリックでバージョンUPできるPHPスクリプト「TegUp」Ver 0.9.0 ができたので配布しました。
➡ TegUp：てがろぐ本体を1クリックでバージョンUpできるPHPスクリプト
てがろぐと同じディレクトリに置いてブラウザでアクセスするだけで、新バージョンが存在するかどうかを調べて、あればボタンクリックだけで自動バージョンアップされます。
まだ最小限の機能だけなので、とりあえず Ver 0.9.0 ということで公開しました。もうちょっと機能増強したいとは思っています。
最新版をお使いでない方々は、ご活用頂ければ幸いです。
アナウンス：Twitter、Pawoo(Mastodon)
➡ TegUp：てがろぐ本体を1クリックでバージョンUpできるPHPスクリプト
てがろぐと同じディレクトリに置いてブラウザでアクセスするだけで、新バージョンが存在するかどうかを調べて、あればボタンクリックだけで自動バージョンアップされます。
まだ最小限の機能だけなので、とりあえず Ver 0.9.0 ということで公開しました。もうちょっと機能増強したいとは思っています。
最新版をお使いでない方々は、ご活用頂ければ幸いです。
アナウンス：Twitter、Pawoo(Mastodon)
リンク先を別タブで開く [ラベル:NEW]URL の記法を使った場合に、リンクテキストにそのまま :NEW の文字が出てしまう問題を今すぐ解決するには、以下の手順で tegalog.cgi を編集して下さい。
1. Ver 4.1.1βの tegalog.cgi をテキストエディタで開きます。
2. 4409～4410行目に移動します。すると、以下のような記述が見えるハズです。（見えない場合は、バージョンが違います。）
3. ここに1行追加して、以下のような3行になるようにします。
4. 上書き保存して、サーバにUPして下さい。
すると、リンクテキストに :NEW が出ないようになります。
この機能を今すぐ使う場合には、お手数ですが上記の手順をお試し下さい。この機能を使わないか、次のバージョンまで待てる場合には、何もしなくて大丈夫です。
1. Ver 4.1.1βの tegalog.cgi をテキストエディタで開きます。
2. 4409～4410行目に移動します。すると、以下のような記述が見えるハズです。（見えない場合は、バージョンが違います。）
# 新規ウインドウ
$addatt .= ' target="_blank"';
3. ここに1行追加して、以下のような3行になるようにします。
# 新規ウインドウ
$linklabel =~ s/(.+):NEW/$1/;
$addatt .= ' target="_blank"';
4. 上書き保存して、サーバにUPして下さい。
すると、リンクテキストに :NEW が出ないようになります。
この機能を今すぐ使う場合には、お手数ですが上記の手順をお試し下さい。この機能を使わないか、次のバージョンまで待てる場合には、何もしなくて大丈夫です。
2週間ほど実施してきました「てがろぐ機能追加検討リストの投票」はさきほど締め切らせて頂きました。たいへんありがたいことに147件の回答が得られまして、わりと需要の傾向が把握できました。投票頂いた回答は、今後の開発機能の優先度を判断する参考等に活用させて頂きます。ご協力下さった方々、誠にありがとうございました。また、作者宛にメッセージをお書き添え下さった方々もどうもありがとうございました。すべてありがたく読ませて頂きました。
てがろぐ追加機能の検討候補がたくさん増えてきましたので、次に何の機能を追加開発しようかな……と迷いつつあります。
で、最近はユーザさんも増えてきたような気配がしていますので、望みの機能(検討候補)に投票して頂いて、その得票数を参考に検討したら良いかな……と思いまして、追加検討機能リストと投票フォームを用意してみました。
お望みの機能への投票にご協力頂ければ、開発検討の参考になってたいへんありがたいです。
ぜひ、よろしくお願い致しますです。(╹◡╹)ﾉ
で、最近はユーザさんも増えてきたような気配がしていますので、望みの機能(検討候補)に投票して頂いて、その得票数を参考に検討したら良いかな……と思いまして、追加検討機能リストと投票フォームを用意してみました。
お望みの機能への投票にご協力頂ければ、開発検討の参考になってたいへんありがたいです。
（ツイート埋め込み処理中...）Twitterで見る
ぜひ、よろしくお願い致しますです。(╹◡╹)ﾉ
Ver 4.0.0リリースの寸前に加えたのでリリースノートとかには書いていないんですが、（標準添付の各スキンでは）ツイートの埋め込みサイズが小さくなるようにCSSを加えました。スマートフォンで見ると従来と何も変わらないと思いますが、タブレットやPCのような比較的広いディスプレイで見ると、埋め込みツイートの横幅が狭くなっていて、文字も小さく見えると思います。
↓表示例
これは、CSSに以下の4行を加えただけです。（4行というか、中身は3行ですし、そもそも1行で書ける分量ですけども。^^;）
/* ▼埋め込みツイートの横幅を強制的に制限 */
div.twitter-tweet {
max-width: 350px !important;
}
埋め込みツイートは、横幅が350pxあたりを下回ると小さな文字で表示されるっぽいですので、とりあえず350pxにしてみました。!importantが付いているのは、これがないと、Twitter側が埋め込んでくる要素に直接書かれたスタイルを上書きできないからです。サイズはお好みに調節して頂ければ良いと思います。 #🌱豆知識
↓表示例
（ツイート埋め込み処理中...）Twitterで見る
これは、CSSに以下の4行を加えただけです。（4行というか、中身は3行ですし、そもそも1行で書ける分量ですけども。^^;）
/* ▼埋め込みツイートの横幅を強制的に制限 */
div.twitter-tweet {
max-width: 350px !important;
}
埋め込みツイートは、横幅が350pxあたりを下回ると小さな文字で表示されるっぽいですので、とりあえず350pxにしてみました。!importantが付いているのは、これがないと、Twitter側が埋め込んでくる要素に直接書かれたスタイルを上書きできないからです。サイズはお好みに調節して頂ければ良いと思います。 #🌱豆知識
ロリポップのWAF対策について
.htaccessを使用して除外設定する事が出来たので報告させて頂きます。
※頭に「spd」と「ent」がつくサーバだと、この対策はできないようです。
参考サイト
PHPやCGIでプログラムの記述変更をしたところ403errorが表示されます – ロリポップ！レンタルサーバー
https://support.lolipop.jp/hc/ja/articles/360048375814
シグネチャで除外設定する
コードの確認は、WAF設定のログ参照から確認する必要があります。
また私の環境ではてがろぐで投稿しWAFでエラーが出た場合、
1つ目のコードを除外設定した後にもエラーが発生しましたが、
ログ参照し、2つ目のコードも除外設定する事で回避出来ました。
なので、複数のコードを除外する必要があるようです。
コード例
# AAA-11,BBB-12を確認したコードに変更
SiteGuard_User_ExcludeSig AAA-11
SiteGuard_User_ExcludeSig BBB-12
IPアドレスで除外設定する
IPアドレスが固定なら、この方法が楽かもしれません。
コード例
# カッコ内のxxx.xxx.xxx.xxxをご自身のIPアドレスに変更
SiteGuard_User_ExcludeSig ip(xxx.xxx.xxx.xxx)
この2つのどちらかを.htaccessに記述すれば、
/etc/abcdのような文字列でも問題なく投稿できました。
ロリポップをお使いで403エラーにお困りの場合は、お試しください。
.htaccessを使用して除外設定する事が出来たので報告させて頂きます。
※頭に「spd」と「ent」がつくサーバだと、この対策はできないようです。
参考サイト
PHPやCGIでプログラムの記述変更をしたところ403errorが表示されます – ロリポップ！レンタルサーバー
https://support.lolipop.jp/hc/ja/articles/360048375814
シグネチャで除外設定する
コードの確認は、WAF設定のログ参照から確認する必要があります。
また私の環境ではてがろぐで投稿しWAFでエラーが出た場合、
1つ目のコードを除外設定した後にもエラーが発生しましたが、
ログ参照し、2つ目のコードも除外設定する事で回避出来ました。
なので、複数のコードを除外する必要があるようです。
コード例
# AAA-11,BBB-12を確認したコードに変更
SiteGuard_User_ExcludeSig AAA-11
SiteGuard_User_ExcludeSig BBB-12
IPアドレスで除外設定する
IPアドレスが固定なら、この方法が楽かもしれません。
コード例
# カッコ内のxxx.xxx.xxx.xxxをご自身のIPアドレスに変更
SiteGuard_User_ExcludeSig ip(xxx.xxx.xxx.xxx)
この2つのどちらかを.htaccessに記述すれば、
/etc/abcdのような文字列でも問題なく投稿できました。
ロリポップをお使いで403エラーにお困りの場合は、お試しください。
隠れハッシュタグを非表示にすることで「見えないフラグ」のように活用するのは良いアイデアだな、と思ったのでヘルプドキュメントに書き加えておきました。➡見えないハッシュタグを作ってフラグのように活用する方法
ネタの提供をありがとうございます！(╹◡╹)ﾉ
ネタの提供をありがとうございます！(╹◡╹)ﾉ
Ver 3.9.3βで、ギャラリーモードやサイトマップページモードでの「状況に応じた見出し」部分が <span class="situation-mode">ギャラリー</span> みたいなマークアップで出力される仕様に改善されたのですが、意図しない副作用で、ギャラリーモードでもサイトマップモードでもない状況でも <span class="situation-mode"></span> という「中身のない要素」が出力されてしまっていました。(^_^;;;
全体としては <p class="situation"><span class="situation-mode"></span></p> という出力になります。表示されるテキストがないことに違いはないのですが、外側のp要素 <p class="situation">～</p> には中身があることになります（emptyではなくなります）。すると、CSSで .situation に適用しているスタイルによっては、「状況に応じた見出し」部分が（見出しとしての文字列は何も出力されていなくても）意図しない装飾になってしまう可能性があります。
もし、「Ver 3.9.3βにバージョンアップしたことによって、状況に応じた見出しの位置に何か余計な装飾が現れた」という場合は、次のβバージョンで解消しますので、そのままお待ち下さい。m(_ _)m
標準添付スキンだと、ブログタイプスキンで下図のように余計なバーが出ます。ブログタイプスキンをそのままお使いの場合はもちろん、ブログタイプスキンをベースにしてカスタマイズしたり独自スキンを作ったりしている場合に同様の問題が出る可能性があります。今の段階でスキンを修正したりせず、次のβ版をお待ちください。（気になる場合は、3.9.2にバージョンダウンしても良いと思います。）
全体としては <p class="situation"><span class="situation-mode"></span></p> という出力になります。表示されるテキストがないことに違いはないのですが、外側のp要素 <p class="situation">～</p> には中身があることになります（emptyではなくなります）。すると、CSSで .situation に適用しているスタイルによっては、「状況に応じた見出し」部分が（見出しとしての文字列は何も出力されていなくても）意図しない装飾になってしまう可能性があります。
もし、「Ver 3.9.3βにバージョンアップしたことによって、状況に応じた見出しの位置に何か余計な装飾が現れた」という場合は、次のβバージョンで解消しますので、そのままお待ち下さい。m(_ _)m
標準添付スキンだと、ブログタイプスキンで下図のように余計なバーが出ます。ブログタイプスキンをそのままお使いの場合はもちろん、ブログタイプスキンをベースにしてカスタマイズしたり独自スキンを作ったりしている場合に同様の問題が出る可能性があります。今の段階でスキンを修正したりせず、次のβ版をお待ちください。（気になる場合は、3.9.2にバージョンダウンしても良いと思います。）
🍘作らないものの話：
ありがたいことに最近はユーザさんも増えてきましたので、「何を作らないか」についても語っておく方が良いのかなという気もしまして、ちょっと長くなりますが語ってみます。そのうちFAQにまとめようと思いますが、とりあえずここに。
長々と書くほどの話ではなくて、要するに『利便性と手軽さの両立はなかなか難しいよね……』というだけの話なんですが。
■スキンが増えて欲しい
今のところ、てがろぐのパッケージに含んでいる標準添付スキンは9種類（モード別も合わせれば12種類）あるわけですが、私個人でこれ以上増やすのは（管理の面で）なかなか難しいかな、と感じているのですよね。
なので、できるだけたくさんの方々がスキンを作って配布して下さると（その他のユーザさんへの選択肢が増えるので）嬉しいな……と思っています。
で、そのためには、『スキンを作るハードルは低い方が望ましい』と考えています。（WordPressのテーマとか作るのめちゃくちゃ大変ですよね。）畳む
■スキン側の仕様が複雑にならないようにしたい
WordPressのように管理画面上からいろいろカスタマイズできれば確かに便利かもしれないのですが、そういう仕組みを用意すればするほど、スキン側の仕様が複雑になってしまって、スキン製作の手間が増えてしまう問題があります(たぶん)。
何でも至れり尽くせりなWordPress等CMSのテーマを作るのが大変な理由は、テーマ側に配慮しないといけない要素が莫大だからですよね。（いや、まあ、もちろんツールそのものの規模も全然違うわけですから、今のてがろぐがどれだけ機能を増やしたところで、スキンがあそこまで複雑・大規模になることはありませんけども。）畳む
■管理画面で何でもしようと思うと(たぶん)際限がなく、スキンが複雑になる
仮に、掲載要素の「表示/非表示」が管理画面上で選べるようになったとしても、それだけでは掲載位置や掲載順序は変化しませんし、もちろんレイアウトも変わらなければ配色も変わらないので、ほとんど自由度は上がりません。
そうすると、次には「掲載順序も管理画面から選べるようになって欲しい」、「配色も管理画面上で指定できるようになって欲しい」……というような要望が出てくると思うんですよね。
そうなると、だんだんWordPress的になってきて、管理画面そのものも複雑になる上に、その設定を反映できるスキンを製作する手間も跳ね上がると思います。（管理画面で指定された順序や配色が表示に反映されるようスキンを作るのはたぶん大変になるでしょう。）畳む
■スキン製作の手間を低く抑えたい（同時にカスタマイズの手間も低くなります）
てがろぐは利用者総数も多くないツールなので、あえて莫大な手間を掛けてまでスキンを作って配布しようとはあまり思われないでしょう。
今、てがろぐのスキンを作って配布して下さっている方々も、「作るのが簡単だから作ってみた」というケースも多々あるのではないかと思っています。
なので、（管理画面上の設定をスキンに反映する仕組みが複雑になるなどして）スキン製作の手間が増えれば増えるほど、第三者がスキンを作ってくれにくくなるだろうという懸念があります。
なので、「スキン製作の手間は低く抑え続けたい」と考えています。
※もちろんそれは、（配布を前提にしたスキンでなくても）多くのユーザさんにとって「自分用のスキンのカスタマイズも楽にできる」というメリットにもなります。畳む
■できるだけシンプルに留めたい
もちろん機能の増加はしたいと思っているのですが、しかし、できるだけシンプルにも留めておきたいと思っています。（まあ、現状を「シンプル」と言えるかどうかはよく分かりませんが。^^; 少なくとも大規模なCMSに比べれば、よっぽどシンプルなことは間違いないでしょう。ファイル数も少ないですし。）
なので、管理画面上から表示/非表示を切り替えたり、掲載順序を入れ替えたり、配色を指定したり、といった大規模CMS的な機能は用意しない方針でいます。
※とはいえ、スキンに書きようがないものについては、管理画面上から出力仕様やON/OFFを切り替えられるようにはなっていますが。
■HTMLから不要部分を削除する程度のスキルはあることが前提
てがろぐに限らずフリーCGIはたいていそうだと思いますが、HTMLを編集する程度のスキルはあることが前提のツールです。そこはたぶん、今後も変わらないです。
「機能を増やしたい」とは思っていますが、「WordPressのようにしたい」とは思っていないので。設計思想の違いと言っても良いのかもしれませんが。（まあ、規模も全然違いますけども。）
せっかく独特の有用さがあったのにFacebookに似せすぎてユーザ離れを起こしたmixiのようにはなりたくないと思っています。(^_^;)畳む
■スキンHTMLから要らない部分を消すのは本当に簡単
スキンHTMLから不要な部分を削除したり順序を入れ替えたりするのは、本当に大したスキルは要らず簡単ですから、そこはなんとか頑張ってHTMLを編集できるようになって頂くのが一番だと思っています。（どうしてもそれを避けたい場合は、WordPressのような至れり尽くせりのツールを選択する方が幸せになれると思います。）
要らない部分は、ただ消せばいいだけ、なんです。ほとんどスキルは要りません。
少なくとも標準添付の各スキンには、わりと詳しめにHTMLソース内にコメントを加えて「ここが何々の部分ですよ、ここは何々の部分ですよ」と示してありますから、消すのにスキルはそれほど要らないと思います。（必要なのは、せいぜい削除範囲を見極める能力くらいでしょうか。それもインデントで示してありますから、把握は難しくないと思います。）
標準添付の各スキンを、あえて「機能全部盛り」な状態で作ってあるのは、そのためなんです。
なので、カスタマイズといっても「消すだけ」なら簡単なハズですから。まずは試してみて下さい。畳む
■CGIの設置ができるなら、HTMLの編集も絶対にできる！^^;
というか、CGIの設置ができるスキルがあるなら、それくらいのHTML編集は絶対にできます！
だって、HTMLを「書け」と言っているわけではなくて、「消すだけ」ですから。
しかも、標準添付スキンのHTMLソース内にはコメントが日本語で書いてありますから！
ここまで書いてあって、しかも、自分で用意した個人サイトにCGIの設置すらもできているのに、スキンHTMLから不要部分の削除だけはできない、……という人が居るとはあまり思えないんですよね。^^;
なので、もし「自分はスキルがないのでスキン編集は難しいはずだ」と思って（思い込んで）いるなら、まずはスキンHTMLをテキストエディタで読み込んでみて、中を見てみて下さい。
CGIが設置できたのなら、それくらいは難なくできるでしょう。
すると、スキンHTMLの編集も、意外と簡単だと分かるのではないかと思います。
だって、それでもどうしても「消すことすらもできない」と言われる場合、その人はそもそも個人サイトを作れていないと思うんですよね……。^^;
「個人サイトを用意する」という最初のハードルを越えられている人なら、スキンHTMLから不要な部分を消すくらい、絶対できると思うんですよ。(^_^;;;
※いや、本当にそのスキルが今はなかったとしても、「個人サイトを用意する」という気力がある時点で、HTMLから不要な部分を消せるようになるスキルくらい、あっという間に身につけられると思うんですよね。^^;畳む
■利便性と手軽さの両立が難しい場合は、手軽さを取る
結局、「管理画面上で何でもできる」ことと「スキン(HTML＋CSS)ソースがカスタマイズしやすい」こととは、トレードオフの関係になるのではないかな……と思っています。全部が全部そうだとは限りませんから、スキン側のシンプルさを維持したまま管理画面でいろいろできるようにできるなら、そうしたい気はあるのですけども。（ただ、あれもこれも試す余裕があるとは限りませんので、「それは複雑になるのではないかな？」くらいの疑念を持った段階で、詳しい検討を保留にすることもありますが。）畳む
管理画面に設定を増やしたがためにスキンが作りにくく(カスタマイズしにくく)なった、ということにはならないようにする方針で居ます。
なので、管理画面上から装飾やレイアウトに手を出すような仕組みは、(よほど何かシンプルさを保てるうまい方法を思いつかない限りは)作らない方針だと解釈して頂いておくと良いのではないかと思います。
畳む
ありがたいことに最近はユーザさんも増えてきましたので、「何を作らないか」についても語っておく方が良いのかなという気もしまして、ちょっと長くなりますが語ってみます。そのうちFAQにまとめようと思いますが、とりあえずここに。
長々と書くほどの話ではなくて、要するに『利便性と手軽さの両立はなかなか難しいよね……』というだけの話なんですが。
■スキンが増えて欲しい
今のところ、てがろぐのパッケージに含んでいる標準添付スキンは9種類（モード別も合わせれば12種類）あるわけですが、私個人でこれ以上増やすのは（管理の面で）なかなか難しいかな、と感じているのですよね。
なので、できるだけたくさんの方々がスキンを作って配布して下さると（その他のユーザさんへの選択肢が増えるので）嬉しいな……と思っています。
で、そのためには、『スキンを作るハードルは低い方が望ましい』と考えています。（WordPressのテーマとか作るのめちゃくちゃ大変ですよね。）畳む
■スキン側の仕様が複雑にならないようにしたい
WordPressのように管理画面上からいろいろカスタマイズできれば確かに便利かもしれないのですが、そういう仕組みを用意すればするほど、スキン側の仕様が複雑になってしまって、スキン製作の手間が増えてしまう問題があります(たぶん)。
何でも至れり尽くせりなWordPress等CMSのテーマを作るのが大変な理由は、テーマ側に配慮しないといけない要素が莫大だからですよね。（いや、まあ、もちろんツールそのものの規模も全然違うわけですから、今のてがろぐがどれだけ機能を増やしたところで、スキンがあそこまで複雑・大規模になることはありませんけども。）畳む
■管理画面で何でもしようと思うと(たぶん)際限がなく、スキンが複雑になる
仮に、掲載要素の「表示/非表示」が管理画面上で選べるようになったとしても、それだけでは掲載位置や掲載順序は変化しませんし、もちろんレイアウトも変わらなければ配色も変わらないので、ほとんど自由度は上がりません。
そうすると、次には「掲載順序も管理画面から選べるようになって欲しい」、「配色も管理画面上で指定できるようになって欲しい」……というような要望が出てくると思うんですよね。
そうなると、だんだんWordPress的になってきて、管理画面そのものも複雑になる上に、その設定を反映できるスキンを製作する手間も跳ね上がると思います。（管理画面で指定された順序や配色が表示に反映されるようスキンを作るのはたぶん大変になるでしょう。）畳む
■スキン製作の手間を低く抑えたい（同時にカスタマイズの手間も低くなります）
てがろぐは利用者総数も多くないツールなので、あえて莫大な手間を掛けてまでスキンを作って配布しようとはあまり思われないでしょう。
今、てがろぐのスキンを作って配布して下さっている方々も、「作るのが簡単だから作ってみた」というケースも多々あるのではないかと思っています。
なので、（管理画面上の設定をスキンに反映する仕組みが複雑になるなどして）スキン製作の手間が増えれば増えるほど、第三者がスキンを作ってくれにくくなるだろうという懸念があります。
なので、「スキン製作の手間は低く抑え続けたい」と考えています。
※もちろんそれは、（配布を前提にしたスキンでなくても）多くのユーザさんにとって「自分用のスキンのカスタマイズも楽にできる」というメリットにもなります。畳む
■できるだけシンプルに留めたい
もちろん機能の増加はしたいと思っているのですが、しかし、できるだけシンプルにも留めておきたいと思っています。（まあ、現状を「シンプル」と言えるかどうかはよく分かりませんが。^^; 少なくとも大規模なCMSに比べれば、よっぽどシンプルなことは間違いないでしょう。ファイル数も少ないですし。）
なので、管理画面上から表示/非表示を切り替えたり、掲載順序を入れ替えたり、配色を指定したり、といった大規模CMS的な機能は用意しない方針でいます。
※とはいえ、スキンに書きようがないものについては、管理画面上から出力仕様やON/OFFを切り替えられるようにはなっていますが。
- 例えば、「日付境界バー」は日付の境目に出てくるので、スキン側で「ここ」とは位置を指定できません。
- ナビゲーションリンクは、（てがろぐでは一覧表示も単独表示も共通のスキンなので）スキン側で状況を判別しての出力調整ができません。（※今はCSSで見えなくできますが、昔の仕様はそうではなかったので。）
■HTMLから不要部分を削除する程度のスキルはあることが前提
てがろぐに限らずフリーCGIはたいていそうだと思いますが、HTMLを編集する程度のスキルはあることが前提のツールです。そこはたぶん、今後も変わらないです。
「機能を増やしたい」とは思っていますが、「WordPressのようにしたい」とは思っていないので。設計思想の違いと言っても良いのかもしれませんが。（まあ、規模も全然違いますけども。）
せっかく独特の有用さがあったのにFacebookに似せすぎてユーザ離れを起こしたmixiのようにはなりたくないと思っています。(^_^;)畳む
■スキンHTMLから要らない部分を消すのは本当に簡単
スキンHTMLから不要な部分を削除したり順序を入れ替えたりするのは、本当に大したスキルは要らず簡単ですから、そこはなんとか頑張ってHTMLを編集できるようになって頂くのが一番だと思っています。（どうしてもそれを避けたい場合は、WordPressのような至れり尽くせりのツールを選択する方が幸せになれると思います。）
要らない部分は、ただ消せばいいだけ、なんです。ほとんどスキルは要りません。
少なくとも標準添付の各スキンには、わりと詳しめにHTMLソース内にコメントを加えて「ここが何々の部分ですよ、ここは何々の部分ですよ」と示してありますから、消すのにスキルはそれほど要らないと思います。（必要なのは、せいぜい削除範囲を見極める能力くらいでしょうか。それもインデントで示してありますから、把握は難しくないと思います。）
標準添付の各スキンを、あえて「機能全部盛り」な状態で作ってあるのは、そのためなんです。
- 白紙に近い状態から「必要なものを加えていく」タイプだと、最初に「何をどうやって書き足せば良いのか？」を調べる必要があるのでハードルが高いですよね。（そもそも、「何を付け加えられるのか？」の選択肢も最初には全然分からないわけで。）
- でも、逆に「全部盛りの中から不要な物を消していく」タイプだと「ただ消せば良いだけ」なので話が簡単です。
なので、カスタマイズといっても「消すだけ」なら簡単なハズですから。まずは試してみて下さい。畳む
■CGIの設置ができるなら、HTMLの編集も絶対にできる！^^;
というか、CGIの設置ができるスキルがあるなら、それくらいのHTML編集は絶対にできます！
だって、HTMLを「書け」と言っているわけではなくて、「消すだけ」ですから。
しかも、標準添付スキンのHTMLソース内にはコメントが日本語で書いてありますから！
ここまで書いてあって、しかも、自分で用意した個人サイトにCGIの設置すらもできているのに、スキンHTMLから不要部分の削除だけはできない、……という人が居るとはあまり思えないんですよね。^^;
なので、もし「自分はスキルがないのでスキン編集は難しいはずだ」と思って（思い込んで）いるなら、まずはスキンHTMLをテキストエディタで読み込んでみて、中を見てみて下さい。
CGIが設置できたのなら、それくらいは難なくできるでしょう。
すると、スキンHTMLの編集も、意外と簡単だと分かるのではないかと思います。
だって、それでもどうしても「消すことすらもできない」と言われる場合、その人はそもそも個人サイトを作れていないと思うんですよね……。^^;
「個人サイトを用意する」という最初のハードルを越えられている人なら、スキンHTMLから不要な部分を消すくらい、絶対できると思うんですよ。(^_^;;;
※いや、本当にそのスキルが今はなかったとしても、「個人サイトを用意する」という気力がある時点で、HTMLから不要な部分を消せるようになるスキルくらい、あっという間に身につけられると思うんですよね。^^;畳む
■利便性と手軽さの両立が難しい場合は、手軽さを取る
結局、「管理画面上で何でもできる」ことと「スキン(HTML＋CSS)ソースがカスタマイズしやすい」こととは、トレードオフの関係になるのではないかな……と思っています。全部が全部そうだとは限りませんから、スキン側のシンプルさを維持したまま管理画面でいろいろできるようにできるなら、そうしたい気はあるのですけども。（ただ、あれもこれも試す余裕があるとは限りませんので、「それは複雑になるのではないかな？」くらいの疑念を持った段階で、詳しい検討を保留にすることもありますが。）畳む
管理画面に設定を増やしたがためにスキンが作りにくく(カスタマイズしにくく)なった、ということにはならないようにする方針で居ます。
なので、管理画面上から装飾やレイアウトに手を出すような仕組みは、(よほど何かシンプルさを保てるうまい方法を思いつかない限りは)作らない方針だと解釈して頂いておくと良いのではないかと思います。
畳む
てがろぐでは、投稿内に含まれる1つ目の画像をOGPの og:image に出力する機能がありまして、デフォルトで有効になっています。
この機能では、投稿内にある1つ目の画像を問答無用で採用するので、1つ目の画像が「Twitter側がCardに求める様式」に該当していない場合は、Twitter Cardには画像が表示されないことになります。#🌱豆知識
一番よくありそうなケースは、SVGな気がします。Twitter CardはSVG形式の画像をサポートしていないので、SVG画像が1枚目にあるとTwitter Cardに画像は出ません。WebPは使えます。
あと、Twitter側が指定している条件は下記の通りです。
▼summary(小画像の場合)：Twitterのドキュメント
▼summary_large_image(大画像の場合)：Twitterのドキュメント
この機能では、投稿内にある1つ目の画像を問答無用で採用するので、1つ目の画像が「Twitter側がCardに求める様式」に該当していない場合は、Twitter Cardには画像が表示されないことになります。#🌱豆知識
一番よくありそうなケースは、SVGな気がします。Twitter CardはSVG形式の画像をサポートしていないので、SVG画像が1枚目にあるとTwitter Cardに画像は出ません。WebPは使えます。
JPG, PNG, WEBP and GIF formats are supported. Only the first frame of an animated GIF will be used. SVG is not supported.
https://developer.twitter.com/en/docs/twitter-for-webs...
あと、Twitter側が指定している条件は下記の通りです。
▼summary(小画像の場合)：Twitterのドキュメント
Images for this Card support an aspect ratio of 1:1 with minimum dimensions of 144x144 or maximum of 4096x4096 pixels. Images must be less than 5MB in size. The image will be cropped to a square on all platforms.
➡ 縦横比 1:1、最小サイズ 144x144、最大サイズ 4096x4096 ピクセル。画像サイズは 5MB まで。画像は正方形にトリミングされる。
▼summary_large_image(大画像の場合)：Twitterのドキュメント
Images for this Card support an aspect ratio of 2:1 with minimum dimensions of 300x157 or maximum of 4096x4096 pixels. Images must be less than 5MB in size.
➡ 縦横比 2:1、最小サイズ 300x157、最大サイズ 4096x4096 ピクセル。画像サイズは 5MB まで。
てがろぐ一式をサーバにUPした後、「どんなURLでアクセスできるのか分からん」とか「404エラーになったり500エラーになったりする」という場合は、とりあえず tegalog.cgi ではなく skin-cover.html を表示してみると良いかもしれません。
https://なんとなく想像するパス/tegalog.cgi ではなく
https://なんとなく想像するパス/skin-cover.html のように。
それで、
「404エラーになったり500エラーになったりする」という場合、可能性としては「そもそもアクセスするURLが間違っている」場合と、「URLは合っているが動作していない」場合とがありますので、まずは「そのどちらなのか」を先に確定させる方が望ましいと思います。（アクセスできない原因が1つとは限りませんから、一気に解決させようとせずに、1つずつ可能性を潰していって特定する方が近道だと思います。）
https://なんとなく想像するパス/tegalog.cgi ではなく
https://なんとなく想像するパス/skin-cover.html のように。
それで、
- skin-cover.html すらも 404 Not Found エラーになるなら、間違いなくURLが違います。
- その場合は、なんとかして正しいURLを探る必要があります。
- skin-cover.html は表示されるなら、URL自体は正しいです。
- URLが正しいなら、あとは、500エラーを解消する方策を探れば良いだけです。
「404エラーになったり500エラーになったりする」という場合、可能性としては「そもそもアクセスするURLが間違っている」場合と、「URLは合っているが動作していない」場合とがありますので、まずは「そのどちらなのか」を先に確定させる方が望ましいと思います。（アクセスできない原因が1つとは限りませんから、一気に解決させようとせずに、1つずつ可能性を潰していって特定する方が近道だと思います。）
ご報告に感謝致します。
🧀Re:3438◆なるほど、スペースが2つ入っていましたか……。もしかして『画像リンクに独自のclass属性値を追加』にチェックが入っていて、なおかつ直下の「class=" "」の入力欄は空っぽになっていたりしないでしょうか？（下図の緑色矢印の先です。その条件だと、こちらでも不具合が再現しました。）その場合、『画像リンクに独自のclass属性値を追加』のチェックをOFFにすると解決すると思います。
緑色矢印の先が空欄で、その直上のチェックボックスがONのとき
画像をリンクにするa要素部分は、正確には <a class="● ▲ ■" ～> のように3種類のclass名が出力されるようになっています。●はimagelink固定で必ず含まれます。▲は『画像リンクに独自のclass属性値を追加』のチェックがONの時に限って直下のテキスト入力欄に設定された文字列が出力されます。■には画像に付加されたフラグがある場合に限ってフラグに対応する文字列(nsfwやnolisted)が出力されます。なので、●は必ず出力されますが、▲と■は状況によって出力されたりされなかったりします。
このとき、『画像リンクに独自のclass属性値を追加』にチェックが入っている状態で、直下のテキスト入力欄が空っぽだと、● ▲ ■ の「▲」が0文字になるため、たしかに空白が2つ連続で挿入されてしまいます。通常のHTMLならそうなっても問題ありませんが、別の設定項目『空白の連続を再現 (半角空白文字の連続をそのまま見せる)』がONの場合（※デフォルトでONです）には、連続する2つ以上の空白が という文字実体参照に変換される機能が働いてしまって（本当は働いてはいけないのですが）、それが悪影響を及ぼしてしまうのだと分かりました。(^_^;;;
ううーん、そんな問題があったとは……。今までは（画像フラグの実装前までは）ここに2種類のclassしか入らなかったので、空白が2つ以上連続する状況があり得なかったから問題なかったのでしょうね。次のバージョンで仕様を修正します。畳む
とりあえず今のバージョンでは、
🍩解決策1：『画像リンクに独自のclass属性値を追加』のチェックをOFFにする。
🍩解決策2：『画像リンクに独自のclass属性値を追加』直下のテキスト入力欄に半角英数字を1文字以上書く。
🍩解決策3：『空白の連続を再現 (半角空白文字の連続をそのまま見せる)』のチェックをOFFにする。
……のどれかで解決はできます。（どれか1つだけで大丈夫です。）
ご報告をどうもありがとうございました！
これも絶対に誰かから報告されないと気付かなかったでしょうね……。(^_^;;; 「スペースが2つ入っていた」という情報が重要なヒントになりました。ありがとうございます。
🧀Re:3438◆なるほど、スペースが2つ入っていましたか……。もしかして『画像リンクに独自のclass属性値を追加』にチェックが入っていて、なおかつ直下の「class=" "」の入力欄は空っぽになっていたりしないでしょうか？（下図の緑色矢印の先です。その条件だと、こちらでも不具合が再現しました。）その場合、『画像リンクに独自のclass属性値を追加』のチェックをOFFにすると解決すると思います。
画像をリンクにするa要素部分は、正確には <a class="● ▲ ■" ～> のように3種類のclass名が出力されるようになっています。●はimagelink固定で必ず含まれます。▲は『画像リンクに独自のclass属性値を追加』のチェックがONの時に限って直下のテキスト入力欄に設定された文字列が出力されます。■には画像に付加されたフラグがある場合に限ってフラグに対応する文字列(nsfwやnolisted)が出力されます。なので、●は必ず出力されますが、▲と■は状況によって出力されたりされなかったりします。
このとき、『画像リンクに独自のclass属性値を追加』にチェックが入っている状態で、直下のテキスト入力欄が空っぽだと、● ▲ ■ の「▲」が0文字になるため、たしかに空白が2つ連続で挿入されてしまいます。通常のHTMLならそうなっても問題ありませんが、別の設定項目『空白の連続を再現 (半角空白文字の連続をそのまま見せる)』がONの場合（※デフォルトでONです）には、連続する2つ以上の空白が という文字実体参照に変換される機能が働いてしまって（本当は働いてはいけないのですが）、それが悪影響を及ぼしてしまうのだと分かりました。(^_^;;;
ううーん、そんな問題があったとは……。今までは（画像フラグの実装前までは）ここに2種類のclassしか入らなかったので、空白が2つ以上連続する状況があり得なかったから問題なかったのでしょうね。次のバージョンで仕様を修正します。畳む
とりあえず今のバージョンでは、
🍩解決策1：『画像リンクに独自のclass属性値を追加』のチェックをOFFにする。
🍩解決策2：『画像リンクに独自のclass属性値を追加』直下のテキスト入力欄に半角英数字を1文字以上書く。
🍩解決策3：『空白の連続を再現 (半角空白文字の連続をそのまま見せる)』のチェックをOFFにする。
……のどれかで解決はできます。（どれか1つだけで大丈夫です。）
ご報告をどうもありがとうございました！
これも絶対に誰かから報告されないと気付かなかったでしょうね……。(^_^;;; 「スペースが2つ入っていた」という情報が重要なヒントになりました。ありがとうございます。
ご質問を頂きましたので、カスタマイズ方法ページにも回答を書いておきました。#🌱豆知識
➡『先頭固定機能を使いつつ、最新の1件を別ページに埋め込みたい場合の方法』（『あるスキンの出力結果を別のページに埋め込む方法』の補足）
SSIやPHP等を使って「最新の1件」を別ページに埋め込んでいるとき、先頭固定機能も同時に使うと、そのままでは「先頭固定された投稿」だけがずっと固定的に埋め込まれてしまって役に立ちません。^^; そんなときには、「表示条件が限定されているときには先頭固定機能は働かない」という仕様を利用するとうまくいきます。……という解説を加えました。
➡『先頭固定機能を使いつつ、最新の1件を別ページに埋め込みたい場合の方法』（『あるスキンの出力結果を別のページに埋め込む方法』の補足）
SSIやPHP等を使って「最新の1件」を別ページに埋め込んでいるとき、先頭固定機能も同時に使うと、そのままでは「先頭固定された投稿」だけがずっと固定的に埋め込まれてしまって役に立ちません。^^; そんなときには、「表示条件が限定されているときには先頭固定機能は働かない」という仕様を利用するとうまくいきます。……という解説を加えました。
先月から実施中の「てがろぐユーザアンケート」について、今月10日に回答数67件の時点で一旦集計してブログ記事で紹介しました。
その『稼働サーバ』集計のアップデート版を掲載します。回答総数は78件（※レンタルサーバ名の記述がない回答を除く）です。
ご協力下さった方々、どうもありがとうございます。これらのデータを元に、昨日レンタルサーバ別のセットアップ方法各ページを公式サイトに加えました。
（アンケート自体は今後も継続して受け付けております。）
各レンタルサーバの内訳は以下の通りでした。
※ブログ記事中で紹介した集計結果から減っているのがあります（ロリポップとスターサーバーが1ずつ減っています）が、集計がミスっていたようです。^^;
その『稼働サーバ』集計のアップデート版を掲載します。回答総数は78件（※レンタルサーバ名の記述がない回答を除く）です。
ご協力下さった方々、どうもありがとうございます。これらのデータを元に、昨日レンタルサーバ別のセットアップ方法各ページを公式サイトに加えました。
（アンケート自体は今後も継続して受け付けております。）
各レンタルサーバの内訳は以下の通りでした。
- さくらインターネット：ライト11、スタンダード7
- リトルサーバー：ミニ5、ワード4、リトル2、ビッグ1、不明1
- ロリポップ：エコノミー3、ライト8、ハイスピード1
- スターサーバー：フリー4、エコノミー2、ライト1、ハイスピード2
- XREA：全員Free
- mixhost：スタンダード2、プレミアム1
- Just-Size.Networks：サブドメイン2、エコノミー1
※ブログ記事中で紹介した集計結果から減っているのがあります（ロリポップとスターサーバーが1ずつ減っています）が、集計がミスっていたようです。^^;
てがろぐ設置方法の解説ページを拡充して、レンタルサーバ別のセットアップ方法(15件)を加えました。これからセットアップされる方は参考にして下さい。
➡ https://www.nishishi.com/cgi/tegalog/setup/#howtoset
➡ https://www.nishishi.com/cgi/tegalog/setup/#howtoset
