お手軽マイクロブログCGI「てがろぐ」のトラブルシューティングや活用上の豆知識です。てがろぐCGIを活用する際に知っておくと便利なテクニック等を解説しています。
そのほか、てがろぐCGIに関してよくある質問と回答も掲載しています。
《最終更新： 2024年10月05日 》
投稿画像を蓄積するための「images」サブディレクトリのパーミッション設定が誤っていないかどうかを確認してみて下さい。
画像の投稿はエラーなく完了するのに、表示だけがされないという場合は、ほぼ間違いなく、imagesディレクトリのパーミッションの設定を 707 (777) や 706 (766) にしてしまっていることが原因です。705 や 755 などに変更して下さい。
「suEXEC」という安全な仕組みが有効のサーバでは、ディレクトリのパーミッションを誤って「一般の場合」の値に設定してしまうと、「画像投稿は完了するのに、画像が一切表示されない」という動作上の不具合が起こることがあります。 ディレクトリのパーミッションを正しく設定し直せば解決します。
suEXECという安全な仕組みが有効なサーバでは、サブディレクトリのパーミッションはデフォルトのまま（755など）で構いません。
ここで（全員に書き込み権限を付加する意味の）777 や 766 等にしてしまうと、そのサブディレクトリに格納されたあらゆるファイルは（安全のために）表示されなくなります。
その場合は、サブディレクトリのパーミッションを 705 や 755 に変更すると表示されるようになります。（さくらインターネットやロリポップでは 705 にして下さい。）
※お使いのサーバでどのような値に設定する必要があるのかは、レンタルサーバ別のセットアップ方法を用意していますのでそちらをご参照下さい。
※その一覧に存在しないレンタルサーバをお使いの場合、各ファイルのパーミッションの値については「設置方法3：パーミッションの設定」をご参照下さい。
構成ファイル群をアップロードしたハズなのに、ブラウザでアクセスすると「404 Not Found」や「403 Forbidden」のエラーが出てしまう場合は、tegalog.cgi にアクセスしているかどうかを確認して下さい。
「アップロード先のディレクトリ」と「URL」との関係を再度ご確認頂き、アップロードした場所を指し示すURLにアクセスできているかどうかをご確認下さい。
てがろぐ自身が「404 Not Found」エラーを出すことはありませんので、もし 404 Not Found エラーが見えたなら、それは100％ アクセスするURLが間違っている のが原因です。
※例えば、tegalog.cgi と同じ位置に dummy.html などのファイル名で適当なHTMLを置いてみて下さい。そのファイルにアクセスできないのなら、URLが間違っています。
自身で何らかの工夫をしない限り、「ディレクトリ名までのURL」にアクセスしても表示されません。
例えば https://ドメイン/tsubuyaki/ のディレクトリにアップロードした場合は、https://ドメイン/tsubuyaki/tegalog.cgi にアクセスする必要があります。
もし「ディレクトリ名までのURL」で動くようにしたい場合は、さらに『ファイル名「tegalog.cgi」を省略してアクセス可能にする方法』で説明している方法等を使う必要があります。 （この方法が使えない場合は、 tegalog.cgi を index.cgi に改名して使う手もあります。）
ロリポップのサーバ上で稼働させた場合で、（普段は普通に使えるのに）ある特定の種類の投稿後にだけ「403 Forbidden」になってしまう場合は、『ロリポップのサーバで投稿後に「403 Forbidden」になる場合の対策』をご覧下さい。
閲覧は問題ないのに、投稿や設定変更後にだけ「404 Not Found」になってしまう場合は、『投稿や設定変更操作をすると「404 Not Found」エラーになる場合』をご覧下さい。
CGIをアップロードした際に、「500 Internal Server Error」が表示されるだけで動作しない場合には、下記の点をチェックしてみて下さい。
なお、可能ならウェブサーバ側のエラーログファイルに何が記録されているかを参照すると、原因究明の参考になります。
バージョンアップ時には、tegalog.cgi と fumycts.pl の2つのファイルを必ずセットで上書きアップロードして下さい。
どちらか片方だけしか上書きしなかった場合は、Internal Server Error になる可能性があります。
そのほか、初回セットアップ時に必要だった各種操作（1行目の書き換えや、CGI本体に直接記述する系統の設定など）を忘れていないか、下記の「最初からInternal Server Errorになってしまう場合」項目を参考にしてみて下さい。
どうしてもエラーが解消しない場合は、試しに別のディレクトリに新規セットアップを試してみて下さい。それで動作するなら、バージョンアップの過程に何か問題があります。
FFFTP等の一部のFTPソフトには、ファイルの転送モードを選択する機能があります。（ファイルの改行コードを自動変換してくれる機能です。） 以下の条件によって転送モードを明示的に指定してアップロードしてみて下さい。
CGIソースを編集せずに、ZIPに含まれていた状態のままでアップロードする場合は、「バイナリモード」に設定してアップロードしてみて下さい。 ZIPに含まれているCGIソースは、改行コードが [LF] で作られています。多くのサーバでは、改行コードが [LF] である必要がありますから、バイナリモードでアップロードすれば確実です。
CGIソースを編集した場合は、さらに下記の条件によって転送モードを選んでみて下さい。
CGIソースの改行コードが、ウェブサーバ側の求める改行コード（＝たいていは [LF] です）と異なる場合には、実行すると Internal Server Error になります。
Windows環境で編集すると、改行コードは [CR]＋[LF] になる場合があります。なので、Windows環境で編集する場合は、保存時に改行コードを明示的に指定できるEmEditor等のテキストエディタを使う方が無難です。
要するに、
……という判断基準で試してみて下さい。
CGI本体ファイルである tegalog.cgi の1行目は、#! /usr/bin/env perl のように記述されています。
これは、たいていのサーバでは（書き換えることなく）このままで動作しますが、お使いのサーバによっては正確なPerlパスに書き換えないと動かない（＝「500 Internal Server Error」になる）場合があります。
もし書き換える必要があるサーバをお使いの場合は、
例えば、#! /usr/bin/perl や #! /usr/local/bin/perl などに書き換える必要がないか、お使いのサーバのヘルプを確認してみて下さい。
※Ver 3.7.0未満をお使いの場合は、一部サーバ等で書き換える必要があります。てがろぐCGIの最新版をお使い下さい。
※お使いのサーバでどのような値に設定する必要があるのかは、レンタルサーバ別のセットアップ方法を用意していますのでそちらをご参照下さい。
CGI本体ファイルである tegalog.cgi の77行目付近には、my $howtogetpath = 2; という記述があります。
極々稀に、この値を 0、1、9 のどれかに書き換えないと正常に動作しないサーバがあります。（※ほとんどのサーバでは書き換える必要はありません。）
現在のところ、書き換える必要があると報告を受けているレンタルサーバは、mixhost と カラフルボックス だけです。
※お使いのサーバでどのような値に設定する必要があるのかは、レンタルサーバ別のセットアップ方法を用意していますのでそちらをご参照下さい。
ウェブサーバ側で指定されているパーミッションの設定方法が「一般の場合」か「suEXECの場合」かを確認して下さい。
suEXECという安全な仕組みが採用されているサーバでは、「suEXECの場合」に示したパーミッションを設定しないと動作しないことがあります。
（特に、ディレクトリに対してGroupやOtherへ書き込み権限を付与すると動作しません。） 設定値は、パーミッションの設定をご覧下さい。
※お使いのサーバでどのような値に設定する必要があるのかは、レンタルサーバ別のセットアップ方法を用意していますのでそちらをご参照下さい。
※その一覧に存在しないレンタルサーバをお使いの場合、各ファイルのパーミッションの値については「設置方法3：パーミッションの設定」をご参照下さい。
※suEXECの方がセキュリティ面で安全な仕組みなので、suEXECを採用しているサーバは多数あります。 さくらインターネット、ロリポップ、リトルサーバー、スターサーバー、WitchServer等々多々あります。
ローカル環境や自力でセットアップしたサーバ等で稼働させる場合には、必須のPerlモジュールがサーバにインストールされていない可能性があります。 CGIの設置環境要件の記述をご確認頂き、不足していればインストールして下さい。
※特に、レンタルサーバの mixhost の新サーバでは、必須モジュールがインストールされていません。 mixhostには、コントロールパネルからPerlモジュールをインストールする機能が提供されていますので、それを使ってインストールするして下さい。 詳しくは、「mixhostでの、てがろぐセットアップ手順」ページをご覧下さい。
権限の問題でサーバにモジュールをインストールできなくても、CGI本体と同じディレクトリにモジュールの構成ファイルを（ディレクトリ構造を維持したまま）設置する方法でも使えます。
その際には、tegalog.cgi の冒頭付近にある #use lib '.'; という記述行の先頭にある「#」記号を削除しないと読み込まれないので注意して下さい。
詳しい書き方は、CGI本体ファイルに直接記述する高度な設定群の「その他」項目もご参照下さい。
お使いのWebサーバにセットアップされているPerlのバージョンに問題がある場合もあります。 Perl 5でも、マイナーバージョン番号が古すぎる場合や新しすぎる場合には、何らかの原因で動作しないことがあります。 てがろぐCGIを動作させるには、Perl 5.6以上のバージョンが必要です。 もし、サーバのコントロールパネルからPerlのバージョンを選択可能なら、他のバージョンに変更してみて下さい。（ただし、Perlのバージョンを変更すると、Perlで動作する他のCGI等にも影響しますので充分ご注意下さい。）
動作確認に使っているPerlの詳細なバージョンは、配布パッケージ(ZIPファイル)に含まれている README.TXT ファイルの冒頭付近に記してあります。
どのような状況でエラーになるのか、直前の操作内容をお知らせ頂けると助かります。
可能ならウェブサーバ側のエラーログファイルに記録されている内容も参照してみて下さい。
新規にセットアップすると問題なく動作するのに、それと同じファイルを使ってアップデートしてもエラーが解消しない場合は、「500 Internal Server Error」エラーメッセージを、独自に用意したページに置き換えていないかどうかを確認して下さい。
お使いのWebサーバで「500 Internal Server Error」エラーメッセージを独自に用意したページに置き換えている場合に、URLが変わる形で転送してしまっていると、エラーが解消しないように見えることがあります。（その場合は、ブラウザのキャッシュをクリアしたり、別のブラウザを使ったりすれば、正しく見えます。）
これは、.htaccessファイルの記述が望ましくない形になっているためです。
独自エラーページへ(301で)転送すると、転送先URLをブラウザが記憶するため、次回以降のアクセス時には「直接エラーページを見に行く」ようになってしまい、エラーが解消されてもエラーページしか見えなくなります。
この現象を解消するには、独自エラーページへの転送を止めるのが最も簡単です。ただし、設定を削除してもブラウザのキャッシュは消えないため、ブラウザのキャッシュをクリアする作業も必要です。（あなた自身だけでなく、一度でもエラーページを見てしまった閲覧者は全員キャッシュをクリアしない限り、エラーページしか見えない状態になります。）
エラーページを独自に用意する場合は、転送せずに内容だけを置き換えるように（＝エラーページが見えている場合でもURLは元のまま変わらないように）するのが無難です。
てがろぐCGIをロリポップのサーバ上で稼働させた場合にエラーになる場合は、下記の点もご確認下さい。
まずは、てがろぐ Ver 3.7.0 以降のバージョンをお試し下さい。
もしそれでも解決しない場合や、どうしても Ver 3.6.x 以下のバージョンを使う必要がある場合は、
てがろぐ本体（tegalog.cgi）をテキストエディタで開いて、1行目にある記述を
#! /usr/local/bin/perl のように修正する必要があります。
ロリポップのサーバ上で稼働させている場合に、投稿本文の中に /etc/abcd のような半角9文字を含めて送信(投稿)すると、サーバに拒否されて「403 Forbidden」エラーが出る問題が分かっています。
abcdの部分は英字4文字以上なら何でもエラーになるようです。（そのほかにも何らかのNGワードがあるかもしれません。）
この謎仕様はロリポップ側の問題なので、てがろぐCGI側で直接どうにかすることはできません。
対処方法として、Ⓐサーバ側の設定でどうにかする方法と、Ⓑてがろぐ側でNGワードを避ける方法とを以下に紹介しておきます。
ロリポップのサーバのうち、先頭が「spd」か「ent」ではないサーバをお使いの場合は、.htaccessファイルを使ってWAFの設定を加えることで対処できるようです。対象サーバをご使用なら、以下の方法を試してみて下さい。 下記は、ロリポップをご利用のユーザさんからご提供頂いた情報です。
シグネチャで除外設定する
コードの確認は、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エラーにお困りの場合は、お試しください。
また、ロリポップ公式ヘルプの「PHPやCGIでプログラムの記述変更をしたところ403errorが表示されます」ページも併せてご参照下さい。
上記の方法が採れないサーバをご使用の場合等は、てがろぐ側でNGワードを避ける以下のような方法もありますのでお試し下さい。
/etc/abcd という連続した9文字の投稿が無理でも、先頭1文字を太字装飾にして [B:/]etc/abcd のようにするとNG判定に引っかからなくなるので投稿できます。
この方法だと先頭のスラッシュ記号が太字になってしまいますが、例えば自由装飾記法を使って [F:hogehoge:/]etc/abcd のようにすると、
意味のないHTMLタグで囲まれるだけなので、表示上は「 /etc/abcd 」という何も装飾されていない文字として見えます。
https://www.example.com/etc/image.png のように、Web上に存在するetcディレクトリの中にあるファイルを参照したい場合などでも、そのまま投稿すると403エラーになってしまいます。
これを避けるには、例えば以下の方法があります。
/sonota/filename というパスを書けば、実際には /etc/filename を参照できることになります。
UNIX系OSでは /etcディレクトリに各種設定ファイルがありますから、そのようなファイルがWebフォームから参照されてしまわないようにするための対策なのでしょう。 おそらく、WAF（Web Application Firewall）の機能だと思うのですが、WAFをOFFに設定しても回避はできないという報告も受けています。（※何にしても、WAFはOFFにはしない方が望ましいです。） そのほかに解決する方法を発見された場合は、ぜひお知らせ下さい。
投稿時や設定変更時に「CGIの設置ドメインとは異なる場所からデータが送信されました」というエラーが表示されてしまう場合は、以下の方法をお試し下さい。
その上でも同様のエラーが表示される場合には、そのときエラー画面に表示されている内容をコピーして、CGI作者までメールでお知らせ下さい。
fumycts.pl ファイルの20行目付近に、my $rcheck = 1; という記述があります。
ここを my $rcheck = 0; のように書き換えると、このエラーを強制的に無効化できます。
ただし、この方法での無効化は、セキュリティ面からあまりお勧めはできません。（ローカル環境やセキュリティで保護された環境下など、第三者がアクセスしない場所で稼働している場合には、この方法の対処でも問題ありません。）
CGIにアクセスしても何も表示されなかったり、 「ページは正しく生成されているのに管理画面だけは見えない」場合や、「管理画面は見えるがページが見えない」場合など、一部の画面だけがうまく表示されていなかったりする場合には、 CGI本体ファイルに直接記述する高度な設定群の「その他」項目にある「$howtogetpath」の値を0、1、9などに変更してみて下さい。
もし、0でも1でもダメな場合で、tegalog.cgi のファイル名を別名に変更して使おうとしている場合は、ファイル名を tegalog.cgi に戻した上で、値を「9」に設定してみて下さい。
ページも管理画面も正しく表示されるのに、投稿操作や設定変更操作をした場合にだけ「404 Not Found」エラーが出てしまう場合は、てがろぐCGI側が自身の所在を正しく認識できていないことが原因です。 その場合は、CGI本体ファイルに直接記述する高度な設定群の「その他」項目にある「$howtogetpath」の値を0、1、9などに変更してみて下さい。
レンタルサーバの「カラフルボックス」では、この値を「0」にしないと正しく動作しないと報告を受けています。
ログインしているハズなのに、管理画面TOPを再度表示しようとするとログインフォームが見えてしまう場合や、ログインしたハズなのに再度ログイン画面が見えてしまう場合は、キャッシュが効き過ぎている可能性があります。 管理画面TOPのURLと、「非ログイン状態から管理画面のTOPにアクセスしようとしたときのログイン画面」のURLが同じなので、ログイン画面が表示された時点でキャッシュされてしまうと、管理画面TOPが見えなくなります。
この場合には、ブラウザやサーバのキャッシュ設定を見直してみて下さい。サーバによってはデフォルトで強力なキャッシュが設定されているかもしれません。
Ver 3.5.0以降では、管理画面の表示時にはキャッシュが効き過ぎないようにするヘッダ「cache-control: no-cache」を出力するようになりました。古いバージョンを使っている場合は、Ver 3.5.0以降にバージョンアップしてみて下さい。
普段お使いのブラウザ以外のブラウザでもログインを試してみて下さい。それでうまくいくなら、お使いのブラウザのキャッシュ設定が強すぎる可能性があります。 他のブラウザでも同様の問題が発生する場合は、サーバ側のキャッシュ設定が強すぎる可能性があります。
レンタルサーバのロリポップでこの問題が発生する場合は、ロリポップアクセラレータを無効に設定してみて下さい。
最新版の tegalog.cgi と fumycts.pl をアップロードしたのに、Web上のてがろぐがバージョンアップされておらず旧バージョンのままに見える場合は、下記の4点をご確認下さい。
なお、tegalog.cgi は index.cgi に改名しても動作しますが、そうしなくても、.htaccessファイルに1行書いておくだけで、ファイル名は tegalog.cgi のままで「 / 」で終わる短いURLでアクセス可能にできます。 詳しくは、わざわざファイル名を index.cgi に変更しなくても、「/」で終わるURLでアクセスできるようにする方法をご覧下さい。
もし、tegalog.cgi と間違えて psif.cgi ファイルを上書きしてしまった場合は、以下のような動作になってしまいます。
➡ てがろぐのバージョンは変わらないままで、ログインパスワードだけが無効になる。
こうなってしまった場合、採れる対処は下記の2点です。
もし、tegalog.cgi と間違えて tegalog.xml ファイルを上書きしてしまうと、投稿データが消えます。
もし、tegalog.cgi と間違えて tegalog.ini ファイルを上書きしてしまうと、設定データが消えます。
これらの場合は、バックアップから復元することで対処できます。
投稿データ(tegalog.xml)は、自動バックアップ機能を有効に設定しているなら backup ディレクトリにバックアップされていますから、そこにあるファイルを使って復元できます。
設定データは、自力でバックアップファイルをローカルに保管していればそれを使って復元できます。
復元方法は、使い方・設定方法ページの「バックアップから復元する方法」をご覧下さい。
てがろぐCGIをバージョンアップする方法は、「CGIの更新方法」で説明していますのでご参照下さい。
てがろぐのバージョン番号は tegalog.cgi ファイル(だけ)によって決定されます。なので、tegalog.cgi ファイルを上書きすれば、絶対にバージョン表記の数値は上がります。 「上書きしたハズなのにバージョンが上がらない」という場合は、このファイルが実際には上書きできていない（＝操作者の勘違い）か、またはキャッシュが効き過ぎている（＝過去の状態が見えたまま）か、上書き用に用意したファイル自体が古いか、のどれかです。
埋め込み合成用のスキンを使った表示結果を、SSIやPHPなどを使って他ページに合成している場合では、画像やハッシュタグリンクなどのリンク先が(相対パスで出力されるために)リンク切れになってしまう可能性があります。 その際は、下記の設定項目（黄色矢印部分と水色矢印の部分）にチェックを入れておくと、それぞれが絶対URIで出力されるようになるため、リンク切れにならずに済みます。
出力結果を別ページに埋め込む際の設定方法（注意点）には他にも少々ありますので、詳しくは、あるスキンの出力結果を別のページに埋め込む方法をご覧下さい。
※複数のスキンを併用しているなど、『一時適用中のスキンを維持できるリンクを出力する』のチェックを外す方法を避けたいなら、JavaScriptを使ってリンク先URLを動的に編集する方法もあります。詳しくは上記ページをご覧下さい。
てがろぐCGIは、HTTPS環境でも問題なく動作します。 もし、SSL証明書を導入してHTTPS化したにもかかわらず、ブラウザのアドレス欄に緑色の錠前アイコン(🔒)ではなく黄色の警告アイコン(⚠)が表示されてしまう場合は、表示ページ内のどこかでHTTP決め打ち（ http://～ のURL）の画像などが読み込まれている可能性があります。 特に、『ユーザアイコンのURLが「http://～」で書かれている』というケースが散見されますので、ぜひご確認下さい。
HTTPSアクセス時に黄色の警告アイコンが出る場合は、たいてい以下の理由です。
ページに埋め込む画像をURLで指定する場合に、https://～ ではなく http://～ で書いてしまうケースはよくあります。 てがろぐの場合、特にユーザアイコンの設定は見落とされがちな気がします。 ユーザアイコンは、管理画面の「ユーザIDを管理」からユーザ別に設定できます。
ユーザアイコンのURLは https:// から書かなくても、「/」で始まる絶対パスで書くこともできますし、CGI本体の設置場所を基準にした相対パスで書くこともできます。
また、CGI本体と同じディレクトリに画像ファイルを置いているなら、単に画像ファイル名を書くだけでも表示可能です。
※ユーザアイコンは、CGIの存在する位置からの相対パスで指定するか、サーバルートからの絶対パスで指定するのがお勧めです。
パスワードを忘れてしまった場合は、以下の2通りの対処方法があります。
管理者権限を持つIDが他にある場合は、そのIDでログインしてから、管理画面の「ユーザIDを管理」にアクセスして、目的のユーザIDの設定画面を表示させて下さい。
すると「パスワードリセット」枠が見えますので、そこから新しいパスワードに強制変更できます。
※管理者でも既存のパスワードを知ることはできませんが、任意のパスワードへの強制変更はいつでもできます。
※パスワードを忘れたIDが管理者権限を持つIDでも、それ以外に管理者権限を持つ別のIDがあれば、そのIDでログインしてから目的のIDのパスワードを変更できます。
管理者権限を持つIDのパスワードを忘れてしまった場合は、サーバ上にある「パスワード・セッションID格納ファイル」（＝デフォルトでは psif.cgi ファイル）の中身を空にして上書きアップロードして下さい。
すると、無条件ログインができるようになります。（その際のログイン画面には、図のように無条件ログインが可能なことを示すメッセージ枠が表示されます。(※Ver 4.2.4以降)）
その後、管理画面の「ユーザIDを管理」からパスワードを再設定して下さい。
この場合、全ユーザのパスワードが未設定状態に戻りますのでご注意下さい。
一時的に誰でも無条件ログインができる状態になりますから、ディレクトリ全体に一時的にBASIC認証を加えるなどの安全策を施してから作業することをお勧め致します。
※パスワードが消えるだけで、それ以外のユーザ情報は消えません。正確には、以下の3種類の情報だけが消えます。
※パスワードはハッシュ化されて保存されているため、ファイルの中身を覗いてもパスワードは分かりません。（※だからといって第三者に開示して良いわけではありません。
特に、このファイルにはセッションIDも記録されていますので、常に外部から閲覧されないようにしておく必要があります。）
※ファイルの中身を空にする操作ができない場合は、てがろぐのパッケージ（ZIP）内に含まれている、初期状態の psif.cgi ファイルを上書きアップロードする方法でも構いません。
他に管理者が存在しない状態では、既存の管理者IDを削除することはできない（＝管理者権限を持つIDの数を0個にはできない）ような仕様にしているつもりですが、何らかのトラブルで管理者権限を持つIDが1つもなくなってしまった場合は、下記の手順で既存IDに管理者権限を付与することができます。
userids= という文字列で始まる行の存在が見えるハズです。この行を探して下さい。
このファイル内はアルファベット順にソートされていますので、一旦ファイルの一番下までスクロールしてから上へ向かって探す方が早いです。（もちろん、テキストエディタの検索機能をお使い頂くのでも良いです。）userids= で始まる行の存在は1つだけです。）
userids=skaura<>1<>さくら<>.........
userids=skaura<>9<>さくら<>.........
上記の手順でご操作頂くと、再度管理画面にアクセスしたときには、ユーザ「さくら(sakura)」の権限が管理者権限(Lv.9)になっているはずです。
ユーザIDの権限を変更したり、ユーザIDそのものを削除したりしても、そのユーザIDを使って過去に投稿された投稿はすべてそのまま残っています。 てがろぐでは、IDを消しても投稿は消えません。（名無しの投稿として扱われるようになるだけです。その場合、元のID名でIDを新規作成すれば、元通りの紐付けに戻ります。）
上記の手順で管理者権限は付与できるはずですが、編集箇所を誤ってしまったり、前後の記号を削除してしまったりした場合は、ユーザIDが正しく認識されなくなる可能性があります。 どうしても解決できない場合は、次の手順でユーザIDすべてをリセットし、「管理者権限を持つID『admin』1つだけが存在する初期状態」に戻すことができます。
※この場合でも、既存の投稿はすべて残ったままですのでご安心下さい。（IDを消したりリセットしたりしても、過去の投稿が消えることはありません。）
userids= という文字列で始まる行の存在が見えるハズですので、その行を探して下さい。userids=の部分も含めて1行全部を消し去って下さい。）上記の手順でご操作頂くと、再度管理画面にアクセスしたときには、管理者権限を持つユーザID「名無し(admin)」だけが存在する初期状態に戻っています。
もし、adminにパスワードが掛けられている場合は、ご自身で初回にセットアップした際に admin に対して設定したパスワードでログインできます。 そのパスワードが分からない場合は、さらにパスワードを忘れてしまった場合の対処方法も併せて使って下さい。
既存のユーザIDをすべて消してしまっても、過去の投稿はすべて残っています。 投稿者名は一時的に「名無し」等のデフォルト名での表示に変わりますが、あくまでも一時的なものです。 各投稿とIDとの紐付け情報は残ったままですので、 過去に使っていたID名と同じID名で新しくIDを作れば、元通りの表示・元通りの紐付け状態に戻せます。
にっちもさっちもいかなくなった場合は、作者までお問い合わせ下さい。 その際は、発生している問題の詳細、設置場所(URL)、お使いのサーバ会社名など、できるだけ詳しい情報をお知らせ頂けると、話が早く進みます。 サーバのエラーログがあるととても望ましいです。
てがろぐCGIをバージョンアップするには、最新版のZIPから2ファイル（tegalog.cgiとfumycts.pl）を抜き出して上書きアップロードすれば良いだけです。
詳しくは、セットアップ方法ページの「CGIの更新方法」区画で説明していますのでご参照下さい。
その方法でバージョンアップ作業をしたにもかかわらず、バージョンがアップされていない！という場合は、 トラブルシューティング区画の「最新版を上書きしたのに、バージョンアップできない！ なぜだ!? という場合の確認点4つ」項目をご参照下さい。
そのうち標準添付しようと思っていますが、1クリックで最新版にバージョンアップできる「TegUp」というPHPを配布しています。 これを、tegalog.cgiのあるディレクトリに置いて頂くと、（いま稼働しているバージョンよりも新しい正式版がリリースされている場合に限って）ボタンを1回クリックするだけで、全自動でバージョンアップできます。（※ソース中に直接記述する設定値もすべて抽出して引き継ぐ形でバージョンアップできます。）
てがろぐ本体を置いたディレクトリに「.htaccess」ファイルを用意して以下の1行を書いておけば、わざわざ「tegalog.cgi」のファイル名を「index.cgi」に修正しなくても、「/」で終わるURLでアクセスできます。
DirectoryIndex tegalog.cgi
この場合、実体の位置は https://www.example.com/memo/tegalog.cgi でも、 https://www.example.com/memo/ という「/」で終わるURLだけで表示できます。
その場合、管理画面には https://www.example.com/memo/tegalog.cgi?mode=admin というURLだけでなく、 https://www.example.com/memo/?mode=admin というURLでもアクセスできます。
てがろぐ動作試験版では、CGIの実体は https://www.nishishi.org/testground/tegalog/tegalog.cgi にありますが、
上記の方法を使って https://www.nishishi.org/testground/tegalog/ というURLでもアクセスできるようになっています。
大丈夫です。お好きなファイル名に変更しても動作します。
しかし、もし index.cgi に変更しようとしているなら、 上記の『ファイル名をわざわざ index.cgi に変更しなくても、「tegalog.cgi」を省略して「/」で終わるURLでアクセスできるようにする方法』 もご参照下さい。ファイル名を変更しなくても望みのURLになります。もちろん、index.cgiに変更しても動作に支障はありません。
ファイル名を変更した場合は、アップデートする際にも同様に変更するのを忘れないようご注意下さい。 でないと、「最新版をUPしたのに、てがろぐがアップデートされない!? なぜだ!?」となるかもしれません。
てがろぐCGIには、ユーザごとに個別のアイコンを指定する機能があります。 もし、CGI本体（＝tegalog.cgiファイル）と同じディレクトリにアイコン画像ファイルを置いているなら、設定には画像ファイル名だけを書いても表示可能です。
ユーザアイコンのURLは「 https:// 」などのプロトコル名から書かなくても、「/」で始まる絶対パスで書くこともできますし、CGI本体の設置場所を基準にした相対パスで書くこともできます。 相対パスで書けるということは、つまり（同一ディレクトリにあるファイルなら）ファイル名だけを書くことでも指定できるということです。
SSIやPHP等を使って、出力結果を他のページに埋め込みたい場合は、絶対URIで出力する必要が（ある可能性が）ありますので、「 https:// 」等から書くか、または「/」で始まる絶対パスで書いて下さい。
てがろぐCGIのログイン状態は、「最後に管理画面にアクセスした日から指定日間(デフォルトなら31日)は維持される」という仕様なので、指定日数よりも短い間隔で管理画面にアクセスを続けていれば、永久にログアウトすることはありません。 「最初にログインした時点から指定日数後に自動ログアウトされる」というわけではありません。
QUICKPOSTから投稿した場合は、一見すると管理画面にはアクセスしていないように感じられますが、内部では(投稿処理する瞬間に)アクセスしています。
なので、管理画面を一切見ていなくても、投稿するだけでログイン情報（セッション期限）は更新されています。ですから、ログイン状態を維持する期限よりも短い頻度で投稿を続けていれば、永久にログアウトすることはありません。
全員を強制ログアウトさせる機能が使われたり、CGIの識別文字列が変更された場合には、サーバ側で保持している認証情報が無効化されるため、各ユーザのセッション期限に関係なくその時点で全員がログアウトされます。
なお、ログアウトされる（ログアウト状態になる）には、ユーザが自らログアウトボタンを押す以外にも、➊ブラウザがCookieを破棄する、➋サーバ側の認証記録が消える、➌CGIが利用するCookie名が変更される、➍設置場所のドメイン名が変わる、➎管理者権限でパスワードが強制変更される……などの要因があります。
サーバを移転する際には、基本的には tegalog.cgi の存在する場所にあるすべてのフォルダとファイルをまとめて移動すれば良いです。
ただし、管理画面の［設定］→［システム設定］→【フルパス設定】や【サーバパス設定】の各項目で、サーバ上のフルパスを手動設定していた場合は、移転先のサーバでも全く同じフルパスにならない限り、正しく動作しない可能性があります。 その場合は、それぞれの設定を一旦「自動取得」・「環境変数から自動取得」の方に切り替えてから保存し、全ファイルをDLして移行してから、移行先の管理画面で改めて正しいフルパスを設定しなおすとうまくいく可能性があります。
サーバによってはパスワードの再設定が必要になる可能性があります（絶対に再設定が必要だとは限りません。むしろたいていは再設定不要です）。
ここでの「パスワード」とは、ユーザIDに対するログインパスワードのほか、鍵付き投稿機能で使うパスワード「共通鍵」も含みます。
もし、移転先で（パスワードが異なるというエラーで）ログインできない場合は、psif.cgiファイルの中身を空っぽにして上書きUPし、パスワードを再設定して下さい。
もし、CGI本体は移転先に最新版をアップロード済みであるとか、移動するファイル数を最小限にしたい何らかの事情があるなどの場合には、 tegalog.xml、tegalog.ini、psif.cgi（＝パスワード・セッションID格納ファイル）の各ファイルと、imagesフォルダを丸ごと移動すれば良いです。
※psif.cgiファイルをコピーしないと、全ユーザのパスワードが未設定に戻った状態で稼働してしまいますのでご注意下さい。
※基本的には、
……の3ファイルと、imagesフォルダの中身さえ移転先で上書きすれば、全データを再現(復元)できます。
psif.cgiファイルには、全ユーザのパスワードがハッシュ化されて保存されています。 ハッシュ化というのは「元には戻せない暗号化」のような仕組みなので、ファイルの中身を覗いてもパスワード自体は分かりません。 しかし、パスワードの正誤判定には必要です。(※直接パスワードが分かるわけではないとはいえ、このファイルの中身は第三者に見られないようにする必要があります。そのために、デフォルトではファイル拡張子を .cgi にしてありますが、第三者に見られないようにできるなら他の方法でも構いません。)
なお、psif.cgiファイルにはセッション情報（＝ログイン状態）も保存されているのですが、ログイン状態は「ドメインに対するCookie」で維持されていますので、別ドメインに移動させるとログイン状態は解除されます。 （※サーバを移動してもドメインが変わらなければセッションは維持できます。） その際、管理画面の下部に灰色で小さく表示されている「現在のログイン件数」は、（psif.cgiファイルで管理されているため）仮に『前のサーバで3件のログインがある状態』で新サーバに移行すると、『本来は誰もログインしていないのに、ログイン件数が3件ある』と認識されてしまいます。その状態でも動作に支障はありませんが、その表示に不都合を感じられるようでしたら、一度『全員を強制ログアウト』を実行して、ログイン件数を0にリセットしてからお使い頂くと良いです。
てがろぐ上でアップロードした画像は、画像保存用ディレクトリ（デフォルト設定では images ディレクトリ）に保存されます。 したがって、この images ディレクトリの中に存在する全ファイルをバックアップしておけば、すべての画像のバックアップになります(※)。
※画像1つ1つに付加されたフラグやキャプション等の情報は、imagesディレクトリ内に自動生成される index.xml ファイル内に記録されます。 したがって、フラグやキャプションの情報が失われないようにするには、必ずこの index.xml ファイルも同時にバックアップ・復元して下さい。
てがろぐの「画像管理画面」では、images ディレクトリ内に存在する画像がタイムスタンプの新しい順に並ぶ仕様です。
したがって、images ディレクトリの中身をバックアップする際には、画像ファイルのタイムスタンプが失われない方法でコピーするのが理想的です。 そうしないと、復元しても（画像ファイルのタイムスタンプが変わってしまうと）画像管理画面内での画像の並び順がバラバラになってしまいますから。
画像を復元する必要が出てきた場合や、他のサーバに移転させるために再アップロードが必要になった際には、タイムスタンプを維持して（＝元のタイムスタンプのままで）アップロードできる方法を使うと、画像管理画面内での並び順を再現できます。
例えば、Windows用の代表的なFTPソフトであるFFFTPには、下図のように「アップロード/ダウンロードするファイルのタイムスタンプを維持」という設定項目があります。 ここにチェックを入れておけば、
要するに、転送した実際の日時に関係なく、元々のファイルのタイムスタンプが常に維持されます。
上図の設定項目は、各ホストの設定とは別の場所にあります。バージョンによって異なるかもしれませんが、FFFTPウインドウのメニューから「オプション」→「環境設定」をクリックし、表示されたオプションウインドウから「転送1」タブを選択すると見えます。
もし、お使いのサーバにSSH等でシェルにログインできるなら、zipコマンドとunzipコマンドを使うことで、「imagesディレクトリ内の全ファイル」をZIPに圧縮したり展開したりできます。 シェルで使えるzipコマンドは、各ファイルのタイムスタンプを維持した状態で圧縮してくれますし、unzipコマンドはタイムスタンプを維持した状態で展開してくれます。
zip IMAGESBACK.zip *.* のようなコマンドを打てば、ディレクトリ内の全ファイルが IMAGESBACK.zip ファイルに圧縮されます。
タイムスタンプは維持されます。（※フラグやキャプション等の情報が記録された index.xml も一緒に圧縮しないといけないので、拡張子を制限せずに全ファイルをまとめて圧縮することをお勧め致します。）
※このコマンドだと、圧縮対象にサブディレクトリは含まれません。
もしサムネイル用のminiディレクトリを用意している場合などでサブディレクトリもすべて含めて圧縮したい場合は、zip -r IMAGESBACK.zip *.* のように -r オプションを付けると良いです。すると、サブディレクトリもすべて含めて圧縮できます。
unzip IMAGESBACK.zip のようにコマンドを打てば、そこにZIP内の全ファイルが展開されます。各ファイルのタイムスタンプは、元の日時が維持されます。この方法だと、imagesディレクトリ内に画像ファイルがものすごくたくさんある場合でも、ダウンロード／アップロードするファイルはZIPファイル1つだけで済む点でも便利です。
てがろぐの設置サーバ自体を移転することが目的なら、imagesディレクトリだけではなく、「てがろぐ設置ディレクトリ」全体をこの方法で1つのZIPに圧縮してしまえば、とても楽に移転できるでしょう。 （その方法だと、タイムスタンプだけでなく、パーミッションの値も維持されます。たぶん。）
画像に関するメタデータを記録した index.xml ファイルについては、「大量の画像キャプションを一括設定(編集)したい場合は、XMLデータを直接編集すると楽かもしれない」項目もご参照下さい。 移転の際などにこのファイルを復元しなかった場合でも画像そのものは正しく表示できます。しかし、フラグ設定は失われ、キャプションは（再登録しない限り）表示できなくなります。
てがろぐCGIの動作に必要なファイルの1つに、「パスワード・セッションID格納ファイル」と呼んでいる psif.cgi というファイルがあります。 拡張子は .cgi ですが、中身はプログラムではなくデータファイルです。 このファイルには、全ユーザのパスワードがハッシュ化されて保存されているほか、現在ログイン中のセッション情報が保存されています。 このファイルの中身を覗いてもパスワード自体は分かりませんが、セッション情報が漏れると困りますので、（何らかの方法で）他者が自由に閲覧できないようにする必要があります。
デフォルトでは、このファイルの拡張子を .cgi にすることで、中身を閲覧できないようにしています。（拡張子が .cgi だと、たいていのサーバでは中身は見えず、直接アクセスしても 500 Internal Server Errorになるため。）
もし、.cgi 以外の拡張子にしたい場合（や、より安全を期したい場合）には、.htaccessファイルを使うなどして、このファイルに対してアクセス制限を施して下さい。
例えば、psif.dat というファイル名のファイルを誰からもアクセス不能にするには、.htaccessファイルに以下の3行を書けば良いです。
<FilesMatch "psif\.dat"> deny from all </FilesMatch>
ファイル名が psif である必要は特にありませんので、変更したければ何でも別の名称に変更して下さい。
ただし、このファイル名を変更すると、てがろぐCGIのバージョンアップ時に毎回ソース内の設定箇所を書き換えなければなりませんので忘れないようご注意下さい。
psif.cgi ファイル以外にも、Webからアクセスする必要の無い各種ファイルへのアクセスはすべて防いでおく方が望ましいです。 そのための .htaccess ファイルの書き方は、「推奨する .htaccess ファイル」項目で紹介していますので、そちらもご覧下さい。
ファイル名の「psif」は、Password, Session Id File の略です。
てがろぐCGIで生成したコンテンツにアクセスできる人物を制限したい場合には、Basic認証等でのアクセス制限が施されている場所に設置してご使用下さい。そのような環境で動作させても問題ありません。
そうではなく、「アクセス制限するほどではないが、おおっぴらに運営するわけでもなく、ひっそりと運営している」というようなウェブサイトで使いたい場合で、 絶対にどこの外部サイトにも1歩たりとも足跡を残したくない！というような極めて強いご希望がある場合には、ご留意頂きたい点が4点あります。 また、それらへの軽い対策も最後にまとめてご紹介しておきます。（※そこまで気にする必要はないと思いますが、以下はそこまで気になる方々に向けた解説です。）
てがろぐCGIでは、画像をその場で拡大する機能のためにLightboxスクリプトを使用しています。このスクリプト一式（＝JavaScriptファイルとCSSファイル）はCDNサーバから読み込まれます。 したがって、てがろぐCGI上で画像を含むページが表示される度にCDNサーバ（※ cloudflare.com と jquery.com の2カ所）からファイルが読み込まれるため、これらのサーバのアクセスログにリファラ情報が記録される可能性があります。 各CDNサーバがリファラ情報をどうするかは分かりませんが（おそらく何もしないでしょうが）、外部サーバに足跡を残すことにはなります。
てがろぐCGIには、画像拡大スクリプトとしてLightbox以外のスクリプトを使うように変更できる機能があります。 この機能を使って「自サイト内に直接設置したスクリプトファイル」を読み込むよう設定すれば、一般のアクセス者がページを閲覧した際にCDNサーバから何かが読み込まれるのは避けられます。 しかし、そう設定しても管理画面の「画像の管理」ページではCDNからLightboxが読み込まれて使用されます。したがって、CDNサーバに足跡を残さずに使うのは少々面倒です。（後述の方法で対処はできます。）
画像以外にも、ツイートを埋め込めばTwitter社提供の埋め込み用スクリプトが読み込まれますので、platform.twitter.com のサーバにアクセスログが残る可能性があります。 そのほか、YouTubeの埋め込みやSpotifyの埋め込みでも同様です。（これらは、「それらの埋め込み機能を使わない」とすることで対処はできます。）
ライセンスをご取得頂かずにお使い頂く場合、「Powered by てがろぐ」の文言とリンクの掲載が必須です。
閲覧者がこのリンクをクリックして移動した場合、てがろぐ公式サイト（＝当サイト）のWebサーバのアクセスログにリファラ情報等が記録される可能性があります。
比較的新しいバージョンでは rel="noreferrer" 等を出力する仕様になっていますからリファラ情報は送信されませんが、すべてのブラウザがその指示に従うとは限りません。
仮に記録されたとしても私が普段その情報を何かに使うことはありませんが、外部サーバに足跡を残すことにはなります。
また、当サイト内の多くのページでは、Google Analyticsによるアクセス解析機能が動作しています。これは、あなたを特定するためのものではなく、サイト全体の閲覧数や平均的な閲覧環境をざっくり知るために設置しています。 しかしながら、Google側がリファラ情報等を把握することに違いはありません（検索用クローラーとは別なので、それだけでGoogleの検索ロボットがリファラ情報にあるURLをクロールしに行くわけではないと思いますが）。 これらの情報の取り扱いについては、当サイトの「このサイトについて」ページ内にある「プライバシーポリシー、免責、閲覧者への注意喚起」項目もご覧下さい。
リンクをクリックしなければ良いだけの話なのですが、 運営者であるあなたがリンクをクリックしないよう気をつけていても、その他のアクセス者がリンクをクリックする可能性があります。 また、検索サイトのクローラーなどのbotがクリックする可能性もありますし、閲覧者が直接クリックしていなくても、ブラウザ側に先読み機能がある場合はその機能が（内部機能で）リンクをクリックする可能性もあります。
※有償ライセンスをご取得頂くと、「Powered by てがろぐ」のリンクを削除してご使用頂けますので、第三者がクリックする可能性をなくせます。
てがろぐCGIの管理画面内には、てがろぐ公式サイト（＝当サイト）に繋がるいくつかのリンクがあります。 例えば設定画面内にあるカスタマイズ方法ページへのリンクなどです。それらをクリックした場合には、先の「留意点2」と同じ状況になります。 この点は、管理画面を使う場合だけの話なので一般のアクセス者は関係ありませんから、あなたが例えば「リンクは別のブラウザで開くようにする」や、「リファラ情報を送信しないように設定したブラウザを使う」等の方法を使えば対策が可能です。
てがろぐCGIの管理画面TOPには、バージョンアップ版の存在をお知らせする「このCGIについて」という区画があります。バージョンアップ版が存在しない場合は「最新版をお使いです」という文言が表示されています。 このお知らせ機能は、最新版をお知らせする小さな画像を読み込むことで実現されています。 この機能の詳しい背景(実現方法)は「今動作しているCGIが最新版なのかどうかを動作画面内でユーザに知らせる方法」(ブログ記事)で紹介していますのでご参照下さい。 てがろぐCGI自体が何らかの情報をどこかへ送信することはありませんが、バージョンアップ案内用の画像を読み込むために、その画像が置いてあるWebサーバのアクセスログには記録を残すことになります。
※有償ライセンスをご取得頂くと、管理画面TOPにある「このCGIについて」枠を非表示に設定することもできます。そうすると、バージョンアップ版の案内も非表示にできます。
最近のブラウザは、利用者のプライバシーを保護する目的で、リファラ情報には「完全なURL」を含めずに「ドメイン名だけ」を送ります。 例えば、てがろぐCGIが https://www.example.com/diary/tegalog.cgi に設置されているとき、リファラ情報にはこのURLそのものではなく「 https://www.example.com/ 」というドメイン名までの情報だけが含まれます。
この仕様を利用すると、以下のような運営方法（設置場所）にすることで、リファラ情報が他サイトへ伝わったとしても、てがろぐCGIの存在を直接的には示さずに済みます。
上記のようにすると、リファラ情報が漏れたとしても、『 https://www.example.com/ ドメイン内のどこかに存在する』ということが分かるだけで、具体的にどこにあるのかは分かりません。 https://www.example.com/ にアクセスしてもブランクページが見えるだけなら、本来のHOMEページである https://www.example.com/website/ には到達できません。
もちろん、アクセス制限が施されていないのなら絶対に到達できないわけではありません。しかし、少なくともリファラ情報にあるURLを見るだけでは発見できません。
先の「留意点1」はCDNサーバを使わなければ対処できます。 「留意点2・4」は有償ライセンスをご取得頂いた上で非表示に設定すれば表示されなくなります。 「留意点3」は利用者がリンクをクリックしないよう気をつけることで対処できます。
CDNサーバを使わないようにするには、以下の2点のカスタマイズが両方必要です。
有償ライセンスについては、CGI使用条件（ライセンス）項目もご参照下さい。
管理画面の[設定]→[補助出力]の『OGP＋Twitter Cardを出力する』項目にチェックが入っている場合で、「共通画像のURL」欄が空欄の場合は、OGPやTwitter Card用の画像としてデフォルトの共通画像が使われます。 ただ、OGP画像は普通、SNS等の外部サイトから呼び出されるので、このリファラ情報からCGIの設置位置が漏れることはなさそうに思います。 とはいえ、気になるようなら「共通画像のURL」欄に自サイト内にある画像のURLを記載しておくか、もしくは『OGP＋Twitter Cardを出力する』項目をOFFにしてOGPを無効にしてお使い下さい。
他のツールやサービスで投稿していた大量の過去データを引き継がせたい場合は、てがろぐCGI上で1から投稿するよりも、データファイルであるXMLファイルをテキストエディタで編集する方が楽かもしれません。
てがろぐCGIのデータファイル（デフォルトでは tegalog.xml ）は、XMLベースのテキストファイルですから、テキストエディタで編集できます。
1件1行で記述し、投稿本文は <comment>～</comment> 内に含めるだけです。1件1行で記述する必要があるため、改行は <br /> を使う必要がありますが、それ以外は概ねそのまま転記すれば問題ありません。
😎や🍔などの絵文字もそのままXMLファイル中に記述できます。
データファイルでは、各行の先頭に投稿日付がありますので、（お使いのテキストエディタにソート機能が搭載されていれば）全体を辞書順にソートすることで日付順に並び替えられます。適当な順序で入力しても、最後にテキストエディタの機能を使って辞書順(の降順)にソートすれば、CGI上でも日付順に並べられます。 その際、複数の投稿で投稿ID番号を重複させないようご注意下さい。 なお、投稿IDは連番である必要はありません。投稿IDは、大きい順に並んでいなくても動作はしますが、大きい順に並べておく方が無難です。
直接編集したデータファイルを上書きアップロードした後は、管理画面から「投稿を再カウント」を実行して下さい。
XMLベースのテータファイルですが、完全な仕様のXMLというわけではないので、XMLとして許可されているあらゆる書き方ができるわけではありません。 特に「1件1行」で書かなければ認識されない仕様ですのでご注意下さい。既存の tegalog.xml ファイルの中身を参考にして(ベースにして)編集されると良いでしょう。
XMLの文法チェックができるエディタを使って編集しようとすると、XMLの文法違反が指摘されることがあります。しかし、エディタの指示に従って文法違反部分を修正してしまうと、逆に表示がおかしくなる可能性がありますのでご注意下さい。 エディタ側が指摘してくる文法違反の指摘は無視して、必要な箇所だけを編集することをお勧め致します。 これは、てがろぐCGI側が出力するXMLが、XMLの細かな文法規則に正確には従っていないためです。（仕様だとご解釈下さい。）
カテゴリ <cat></cat> や、フラグ <flag></flag> は（それらが何もない場合は）省略可能です。
※投稿日付 <date>～</date>、投稿番号(投稿ID) <id>～</id>、投稿者ID <user>～</user>、本文 <comment>～</comment> は必須です。
投稿ID番号については、「投稿ID（投稿番号）に上限はある？」項目もご参照下さい。
投稿の削除は、管理画面の『投稿の削除/編集』からもできますが、デフォルト設定では1画面の100件ずつしか表示されません(※)。 もっと大量の投稿を一気に削除したい場合には、データファイル（tegalog.xml）をテキストエディタで編集する方が楽です。 データファイルの直接編集に関しては、「他サービスから大量の過去データを引き継ぎたい場合は、XMLデータを直接編集すると楽かもしれない」項目をご覧下さい。
また、1つの「てがろぐ」で運営していた内容を、投稿内容別に分離して2つの「てがろぐ」で運営するように変更したい場合にも、データファイルを直接テキストエディタで編集すれば簡単です。 以下の手順で操作すると良いでしょう。
データファイルを2つに分離できたら、てがろぐCGIを1つ新たにセットアップし、そこにⒷのファイルを移動させて使って下さい。
※Ver 3.6.0以降なら、管理画面の[設定]→[システム設定]→【管理画面内の表示】→「管理画面内のUI」→『投稿一覧画面で1ページに表示する投稿数』項目で表示件数を自由に変更できます。
どのカテゴリにも属していない投稿（＝「カテゴリなし」の投稿）を一括して任意のカテゴリに属させるには、データファイルを直接編集すると楽です。
データファイルでは、それぞれの投稿が属しているカテゴリを <cat>カテゴリID</cat> の形式で記録しています。
どのカテゴリにも属していない投稿では、そこが <cat></cat> になっています。
したがって、どのカテゴリにも属していない投稿を一括して任意のカテゴリに属させるには、以下の手順で操作すれば簡単です。
<cat></cat> を一括して <cat>sonota</cat> に置き換える。
上記のようにすると、「カテゴリなし」だった投稿を一括して「カテゴリsonota」に属させることができます。
複数のカテゴリに属させるには、カテゴリIDを半角カンマ記号で区切ります。例えば、<cat>info,diary,sonota</cat> のようにです。空白を入れてはいけません。
データファイルを直接テキストエディタで編集した場合は、その後に管理画面から「投稿を再カウント」を実行して下さい。 そうしないと、総件数や日付別件数、ハッシュタグの存在、新着リストなどが更新されません。（閲覧時の動作速度を向上させる目的で、それらのカウント値は（毎回はカウントせず）キャッシュしておく仕様になっているからです。）
データファイルを直接編集した後に、何かを新規投稿するか既存投稿を（てがろぐ上で）再編集すれば、その時点で各種カウント値は更新されますので、「投稿を再カウント」を実行する必要はありません。
ありません。
投稿は、自ら削除しない限り、無限に蓄積される仕様です。
もちろん、ディスクスペース（サーバ容量）には限りがありますので実際に無限ではありませんが、仕様上の上限はありません。
次の「投稿ID（投稿番号）に上限はある？」項目もご参照下さい。
投稿ID(＝投稿1つ1つに割り振られる番号)に、仕様上の上限はありません。 No.100000(十万)でも No.1000000(百万)でも取り扱いは可能です。ただ、そこまで莫大な個数になるとデータファイルが大きくなりすぎて動作が重たくなっている可能性はありそうですが。 投稿件数がそこまで大量になる場合は、エクスポート機能(※)を利用して静的なHTMLファイルとして出力した分を「過去ログ」として掲載しておき、CGIが取り扱うデータファイル自体は小さくした方が望ましいと思います。
※管理画面の「条件を指定して出力」機能（＝エクスポート機能）を使うと、任意のスキンを適用した状態で、全データ（または指定条件に該当するデータ）を静的なHTMLファイル1つに一括出力ができます。
投稿IDは連番である必要はありませんが、重複してはいけません。 同じ投稿IDが複数あっても表示ができなくなることはありませんが、（同じIDが割り振られた投稿のうち1つを除いて）再編集ができなくなります。投稿IDを元にして再編集データを読み込む仕様だからです。
投稿IDの下限は「1」です。 投稿IDに「0」やマイナスの値は使えません。 また、値には整数だけが有効です。小数点を加えることはできません。
仕様上は、文字数の上限はありません。何文字でも投稿可能です。
実際には、1度に莫大な文字数を投稿しようとすれば（CGIではなく）ウェブサーバ側が受付を拒否することはありそうですが。 あくまでもローカル環境での実験ですが、改行を含む日本語文章100万文字は余裕で投稿可能でした。 ただ、改行も空白も含まない英数字だけの羅列数万文字だと（ブラウザ側が表示を拒否してしまって）当該部分だけ空白で表示されるようなケースはありました（そのようなケースは悪戯以外ではあり得ないと思いますが）。 とはいえ、その場合でもCGIの動作継続は問題なく可能でしたので、当該データを削除すれば何も問題はありませんでしたし、データファイルが壊れるというようなこともありませんでした。 というわけで、現実的な使用では「上限は気にする必要はない」とは言えると思います。
すべての画像について、画像ごとにキャプション等の情報を保持する必要があるため、画像保存用ディレクトリ内に index.xml というファイル名で「画像インデックスファイル」を自動生成する仕様になりました。(※Ver 3.9.0以降)
大量に存在する既存画像に対してキャプションやフラグを一括設定(編集)したい場合は、てがろぐCGI上で操作するよりも、この専用XMLファイル（画像インデックスファイル）をテキストエディタで編集する方が楽かもしれません。 中身は（てがろぐ自身のデータファイル tegalog.xml と同様に）XMLっぽいテキストファイルで、1画像に関する情報が1行でタイムスタンプの新しい順に記述されています。テキストエディタで中を見てみると簡単に構造は把握できるでしょう。
基本的には、1つの画像の情報が <image>～</image> の中に記録されています。
先頭にだけは、全画像データをまとめた <total>～</total> という情報行がありますが（※上図の赤枠・緑色矢印の先部分）、ここは実データから計算して自動生成されますので、手動で index.xml を編集する際に触る必要はありません（たとえ書き換えても、てがろぐ側が最新の情報で上書きしますので、書き換える意味がありません。）
<cap>テキスト</cap> の形式で書けば良いだけです。
（※キャプションにはプレーンテキストだけが使えます。特に改行は含められませんのでご注意下さい。
データファイル内は1件1行で登録する仕様なので、途中で改行するとデータとして正しく認識されなくなります。）
<flag>～</flag> の中にカンマ区切りで指定します。<flag>nolisted</flag> とするとONにできます。<flag>nsfw</flag> とするとONにできます。<flag>nolisted,nsfw</flag> と書きます。（順不同）この画像インデックスファイルが存在しないときは、画像に関する情報が必要になった時点で自動生成されます。（画像保存用ディレクトリが存在しない場合には生成されません。）
また、このファイルの中身は適宜更新されますが、自動更新されるタイミングは、
です。
FTP等の別手段で画像をUPしたり削除したりした場合は、その時点では画像インデックスファイルに反映されないので、画像総数の表示等が（一時的に）正しくなくなります。その場合でも、画像管理画面を1度表示するなどすれば正しい情報に更新されます。
※てがろぐ上の操作で画像を削除すれば、その画像に関する情報は画像インデックスファイルからも削除されます。 しかし、FTP等の別手段で画像を削除した場合は、削除された事実を（てがろぐ側が）認識した後でも画像インデックスファイル内に情報は残り続けます。 これは、再度同じファイル名で画像をUPしたときに、以前の登録情報を引き継ぐようにするため（＝画像を差し替えようと思ってFTPで一旦削除したときに、画像インデックスからデータが消えてしまわないようにするため）です。
iPhoneなどのiOS版ブラウザは、テキスト入力欄内の文字サイズが16px未満で表示されている際は、テキスト入力欄にカーソルが入ると画面全体が自動的にズームする仕様です。
その結果、ページ全体が微妙に横スクロールするようになったり、ページ内の文字が全体的に拡大されて見えたりする弊害があります。
そのような自動ズームを防ぐには、テキスト入力欄の文字サイズを16px以上にすれば良いので、例えば textarea { font-size: 16px; } のようにCSSを書いて入力文字サイズを16pxにしておく方法があります。
Ver 2.6.0以降のパッケージに含まれている各標準添付スキンでは、テキスト入力欄内の文字サイズを16pxにするようCSSを記述してあります。 スキンを1から自作する場合には参考にして下さい。
ページ内に埋め込める投稿欄「QUICKPOST」は、外側スキンに [[QUICKPOST]] と書くことで掲載できますが、これは1つのスキンの中で複数回使っても構わない仕様です。
したがって、ページの上端と下端とサイドバーに1つずつ計3つのQUICKPOSTを掲載することもできます。ページ内のどこを見ていてもすぐに投稿できるようにしたい際などにご活用頂けるかもしれません。(笑)
この仕様を実現しつつ、投稿本文内の文字列をJavaScriptで制御できるようにするために、QUICKPOSTには毎回の生成時に1つ1つユニークなid属性値が指定されています。 そのため、投稿欄に指定されているid属性値を装飾目的にCSSで使うことはできませんのでご注意下さい。投稿欄に対して何らかの装飾を施したい場合は、class名の方を使って下さい。 （投稿欄のtextarea要素には「tegalogpost」というclass名が付加してあります。）
QUICKPOST（ページに埋め込む投稿欄）のデザインならスキンHTMLから読み込まれるCSSやJavaScriptを使って自由にカスタマイズできますが、編集時などに使われる「管理画面上の投稿欄」は（デフォルトでは）CGI内部のデザインで固定されています。 しかし、あらかじめ設定をしておけば、この管理画面上の投稿欄(新規投稿/編集画面)で edit.css と edit.js の2つのファイルを読み込ませることができます。この2ファイルを自力で用意しておけば、管理画面上の投稿欄を自由にカスタマイズできます。
詳しい方法は、カスタマイズ方法ページの「新規投稿/編集画面に自由なCSSやJavaScriptを加える方法」項目をご覧下さい。
てがろぐCGIは、JavaScriptが無効な環境でも概ね使用可能です。投稿・編集操作もJavaScriptが使えなくても可能です。 しかし、投稿欄の入力支援機能（文字装飾やリンク挿入など）はJavaScriptで実装されているため、JavaScriptが無効な環境だとそれらの機能は使えません。日付の手動入力欄の動作にもJavaScriptが必要です。 とはいえ、画像の投稿は、JavaScriptが無効でも使用可能です。
アクセス者（閲覧者）のブラウザでJavaScriptが無効になっている場合でも、ページの表示そのものに問題はありません。 ただ、「指定範囲を隠す機能」は使えずに最初から全文が見えます（※それでも本文が読めなくなることはありません）。 また、Lightbox等を使った画像の拡大表示機能は動作しません（※しかし、画像をクリックすれば画像へのリンクとして機能します）。
管理画面の配色(カラーテーマ)を切り替える機能があります。 複数のてがろぐCGIを併用する際に、どれを使っているのか迷わないよう色分けする用途にもご活用頂けます。
Ver 3.5.0以降では、下記の7テーマから選択できます。（Ver 2.7.0～3.4.0では、最初の4テーマのみから選択できます。）
ここで設定したカラーテーマは、ログアウト状態でも適用されます。（WordPressのようにログインユーザごとに適用されるわけではなく、ログインしているかどうかに関係なく全員共通の配色として表示されます。）
あくまでも管理画面のUI配色を選択するだけであって、ページの表示（スキン）には一切影響しません。
投稿欄内にカーソルが入っている状態なら、[Ctrl]＋[Enter]キーで投稿できます。ただし、このショートカットキーは設定で無効にすることもできます。また、JavaScriptが無効な環境では機能しません。 このショートカットキーの有効/無効は、管理画面の[設定]→[投稿欄の表示]→【投稿コントロール枠内の設定】で設定できます。
または、投稿欄内にカーソルが入っている状態で [Tab]→[Enter] の順にキーを押す（同時に押すのではなく、[TAB]キーを押した後で[Enter]キーを続けて押す）ことでも投稿ボタンを押せます。 最初の[Tab]キーでフォーカスが「投稿する」ボタンへ移動し、次の[Enter]キーでボタンを押下できるためです。 この方法は、ショートカットキーではないのでどんな場合でも有効です。スクリプトを使う方法ではないので、JavaScriptが無効な環境でも有効です。
投稿欄内にカーソルが入っていない状態では、上記のどちらの方法も使えません。
しかし、投稿欄にカーソルを移動するためのショートカットキーは、管理画面の[設定]→[ページの表示]→【移動用ショートカットキー】で設定できます。
とても長い文章を投稿したい場合など、「投稿欄の高さを一時的にもっと広げたい」ことがあります。そのような場合に、一時的に投稿欄の高さを拡張する操作方法が2通りあります。
投稿欄内にカーソルが入っているなら、[Ctrl]＋[↓] キーで投稿入力欄の高さを拡張できます。(このショートカットキーは設定で無効にすることもできます。デフォルトでは有効です。)
入力欄内にカーソルがあるときに、[Ctrl]＋[↓]キーを押すたびに入力欄の高さが2倍に拡張されます。
無限に大きくなるわけではなく、最大でブラウザの高さまで広がったら止まります。
なので、最大サイズにまで拡張したいなら、[Ctrl]＋[↓]キーを数回連打すれば良いでしょう。
逆に、[Ctrl]＋[↑]キーだと半分の高さに縮小されます。
投稿欄の右下端をマウスでドラッグすれば、投稿欄の縦横サイズを一時的に好きなように変えられます。（これはブラウザ側がサポートしている機能なので、環境によっては使えない可能性もあります。）
投稿欄の高さを恒久的に変更したいなら、管理画面の[設定]→[投稿欄の表示]→【投稿入力欄の表示と動作】→「入力欄の高さ(編集領域の表示行数)と動作」で指定できます。
QUICKPOSTの高さと、新規/編集画面での高さの両方を個別に設定できます。
なお、投稿欄の横幅はスキンの作り方次第で変わりますので、てがろぐ側から設定・変更する方法はありません。
事前に範囲選択していなくても、ボタンを押したときに装飾記法が挿入されるように設定もできます。 詳しくは、使い方・設定方法ページの「事前に範囲選択していなくても各種記法が挿入されるように設定する方法」項目をご覧下さい。
Ver 3.4.0以降では、端末の画面幅が1024px以下なら、設定にかかわらず常に「先に装飾対象を範囲選択して下さい」というダイアログは表示されない仕様になりました。 大型タブレットを使う場合や、PCでもこのダイアログを表示されないようにしたい場合には、上記の設定項目で設定して下さい。
Windows10をお使いなら、[Windows]キー＋[.]キーで絵文字入力ウインドウが現れます。そこからお好きな絵文字を探してクリックすると入力できます。🍘🧀🍔
それ以外のOSをお使いの場合は、Wikipediaの絵文字一覧ページから探してコピー＆ペーストする方法もあります。
絵文字の見た目をTwitterと揃えたい場合は、絵文字としてTwemoji（Twitter絵文字ライブラリ）を使う方法もご覧下さい。
画像をアップロードする際には、（設定で禁止していない限りは）複数枚の画像をまとめて同時に投稿できます。 同時に選択できる枚数に仕様上の上限はありません。
PCで操作する場合は、
iOSやAndroidなどのモバイルOSで操作する場合は、たいていは何もしなくてもただ複数の画像をタップしていけば複数の画像ファイルを同時に選択できます。 その他、環境によっては操作方法が異なる可能性がありますので、詳しくはその環境のヘルプをご参照下さい。
あまりにも重たい画像ファイルを多数同時にアップロードしようとすると、サーバ側で拒否される可能性があります。
複数の画像を同時にアップロードする機能は無効にも設定できます。無効に設定されている場合は、1枚ずつしかアップロードできなくなります。（そう設定する必要性はあまりないと思いますが。） 管理画面の[設定]→[システム設定]→【画像投稿機能】→『複数枚の画像を同時に投稿可能にする』項目にチェックを入れると複数枚を同時に投稿可能になり、チェックを外すと1枚単位でしか投稿できなくなります。
てがろぐでは装飾記法やリンク等の特殊記法として半角角括弧記号「 [ 」と「 ] 」を使うため、半角角括弧そのものを書きたいときに少々困ることがあります。 そのための対処方法として、プログラミング言語でよくある「\」記号を使ったエスケープ記法が使えます。（Ver 3.2.0以降のみ）
具体的には、投稿本文中に、
これらの記法を使う限りは、特殊記法とは認識されることなく各記号を表示できます。
※コロン記号「:」は、装飾の対象範囲外に書く場合は、そのまま「:」だけを書いて問題ありません。 装飾の範囲内に書く場合は、色指定やオプション指定記法だと解釈されるのを防ぐために、「\:」のように書く方が無難です。（絶対にそう書かないとおかしくなるわけではありません。）
本文中に半角角括弧を書く場合でも、装飾記法やリンク記法等として誤認識されない位置なら、そのまま書いても問題なく表示されます。
また、装飾範囲内に半角角括弧そのものを書きたい場合でも、角括弧の「開き」と「閉じ」の個数が1対1で正しく対応している限りは（エスケープしなくても）問題なく表示できます。
試しに投稿してみて表示がおかしい場合には、上記の書き方でエスケープしてみて下さい。
※装飾範囲内に半角角括弧そのものを書くとき、開き角括弧と閉じ角括弧の対応がおかしい場合には、おかしい位置で装飾が終わる可能性があります。特に閉じ角括弧「 ] 」だけを含めると、そこが装飾の終了位置を示す記号だと解釈されてしまいます。
URLの自動リンク機能を有効にしている場合は、「http://」または「https://」で始まる文字列は自動でリンクになります。 この機能を有効にしたままで、自動でリンクにならないURLを本文中に書きたい場合は、コロン記号「 : 」を「 \: 」のように書くと、リンクにならずにURL文字列だけを表示できます。
上記のどちらの書き方でも、実際にページ上に表示されるのは「 https://www.nishishi.com/ 」です。
これは、「文字装飾の内部等にテキストとして [ 半角角括弧 ] を書きたい場合の書き方」で解説したエスケープ記法を応用した方法です。（Ver 3.2.0以降でのみ使用可能）
てがろぐには、過去に使ったハッシュタグを簡単に挿入できる機能があります。この機能が使えない場合は、下記の点をご確認下さい。
この機能はJavaScriptを使いますので、JavaScriptが実行できない環境では動きません。
詳しくは、使い方・設定方法ページの「ハッシュタグの書き方・仕様」をご覧下さい。
以下に、ポイントだけ紹介しておきます。
てがろぐでは、半角空白文字のほかに、全角/半角の切り替わりもハッシュタグの終了ポイントだと認識します。
しかし、半角角括弧 [～]で囲めば、文字種の混在や空白も含む様々な文字をまとめてハッシュタグにできます。
絵文字は全角文字の扱いです。
#漢🍔字burger と書くと「漢🍔字」の3文字がハッシュタグになります。#Alpha🍔bet と書くと「Alpha」だけがハッシュタグになります。#[複合文字🍔 in Hashtag] のように書けば、空白や絵文字や半角/全角文字も含めたすべてがハッシュタグに含められます。
➡ 他にも細かな仕様がありますので、詳しくは、使い方・設定方法ページの「ハッシュタグの書き方・仕様」をご覧下さい。
全角文字がハッシュタグになり得る状態のとき、全角の空白文字を書いても、ハッシュタグの終わりだとは認識されません。（全角空白文字はそのままハッシュタグの一部として認識されます。） この仕様を変更して、全角空白文字もハッシュタグの区切りとして認識されるようにしようと考えたこともあったのですが、既にこの仕様を利用してハッシュタグをたくさん書いている方々がいらっしゃる可能性を考えて、そのまま放置してあります。(^_^;)
CSSの配色 #ccffcc のような「#」記号から始まる文字列をハッシュタグだと認識されずに書きたい場合には、「#」記号の代わりに数値文字参照で # と書くと良いです。
すると、画面上では「#」と表示されるものの、ソース(実データ)ではあくまでも「#」になるので、ハッシュタグだとは認識されずに済みます。
直前の文字種によっては、「#」記号をそのまま書いてもハッシュタグだとは認識されない場合もあります。 詳しくは、使い方・設定方法ページの「ハッシュタグの書き方・仕様」をご覧下さい。
投稿日時（投稿に表示される日付）は、手動で指定することもできます。その際には、「13月42日」のような存在しない日付を許容することもできます。 ただし、デフォルト設定では投稿日時の編集欄は表示されませんので、設定で投稿日時の編集欄を表示する必要があります。
管理画面の[設定]→[投稿欄の表示]→【日時ボタンの表示設定】→[投稿日時ボタンの表示と動作]欄にある、『投稿日時の自由入力ボタン「日付」を表示する』チェックボックスをONにして下さい。 すると、投稿入力欄の下部に「日付」ボタンが表示され、押すと自由に投稿日付を入力(編集)できるようになります。なお、ボタンのラベル「日付」は自由に変更できます。
ただし、この機能を使っただけでは日付順に自動で並び替わるわけではありません。表示される順序は投稿順のままです。（その結果、日付境界バーの表示が煩雑になることがあります。）
日付順に並び替えたい場合や、未来の日付を予約投稿として扱いたい場合は、下記の解説をご参照下さい。
次の2通りの実現方法があります。
文字サイズを大きくするclassをあらかじめCSSに用意しておき、指定範囲に自由なclass名を付加できる自由装飾機能を使って指定する方法です。
Ver 3.2.0以降には、本文中に直接class名を指定してマークアップできる装飾記法があります。 例えば、以下のⒶように記述すると、Ⓑのように出力されます。
[F:scream:あいうえお]<span class="deco-scream">あいうえお</span>
Ver 3.2.0以降に付属している標準添付スキンでは、 [F:scream:×××] の記述で「×××」の文字サイズが大きくなるCSSがサンプルとして最初から含まれていますから、それを流用すれば簡単に作れるでしょう。
詳しくは、「class名を自由に指定できる装飾記法」をご覧下さい。
てがろぐには最初から「強調」・「太字」・「斜体」等の各装飾機能が用意されていますが、これらに対するCSSはご自身でどのようにでもカスタマイズできます。 したがって、例えば『強調装飾では文字を大きく掲載する』というCSSを書いておけば、「強調」ボタンを押して装飾するだけで文字を大きく掲載できます。
『強調』に対する装飾は .decorationE { ～装飾内容～ } というCSSで指定できますので、
例えば .decorationE { font-size: 1.25em; } のようにCSSを書いておくと、『強調』を指定した対象の文字は1.25倍の大きさで表示されます。
『強調』と『太字』は、ほぼ同じような用途の機能として重複していますから、片方を「大きくする」用途に変えても不都合は少なそうに感じます。 装飾ボタンのラベルは、管理画面の[設定]→[投稿欄の表示]→【装飾ボタンの表示設定】の『ラベル』欄から自由に変更できますので、例えば「強」を「大」のように変更しておけば、分かりやすい「文字を大きくするボタン」になるでしょう。
拡大画像が表示される際に、ぐいーんと枠が広がるアニメーションが嫌で「Lightbox以外のスクリプトを使いたい」と思われる方もいらっしゃるかも知れませんが、わざわざ別のスクリプトに変更しなくても、Lightboxのオプションを以下のように指定するだけで、ぐいーんと広がったり、ふわっと切り替わったりするアニメーション効果をOFFにして、一瞬で拡大画像を表示することもできます。
Lightbox以外の画像拡大スクリプトを使いたい場合は、管理画面の[設定]→[システム設定]で他のスクリプトを指定することもできます。 詳しくは、カスタマイズ方法ページの「Lightbox以外の画像拡大スクリプトを読み込んで使う方法」項目をご覧下さい。
具体的には、外側スキン(skin-cover.html)内の末尾に記述してある [[JS:LIGHTBOX:JQ]] の記述よりも下側に(重要)、以下のHTMLソース(JavaScript)を書きます。
<script>
lightbox.option({
'fadeDuration': 0, /* 描画枠の描画アニメーション時間を0ミリ秒にする(デフォルトは600) */
'imageFadeDuration': 0, /* 画像の読み込み時のアニメーション時間を0ミリ秒にする(デフォルトは600) */
'resizeDuration': 0 /* 描画枠のサイズ変更時のアニメーション時間を0ミリ秒にする(デフォルトは700) */
})
</script>
上記では、fadeDuration、imageFadeDuration、resizeDurationの3項目の値をすべて0にしています。これはアニメーションにかける時間をミリ秒で指定するオプションなので、0を指定するとアニメーション効果をOFFにできます。「アニメーション効果は欲しいが、もっと素早く動いて欲しい」という場合には、デフォルト秒数よりも短い時間を指定すれば良いでしょう。 なお、複数のオプションを記述する際は、上記のように半角カンマ記号「,」で区切ります。このとき、最後の項目の後にはカンマ記号を打たないように注意して下さい。
ちなみに、ナビゲーション関連のオプションには例えば以下のような項目もあります。
<script>
lightbox.option({
'alwaysShowNavOnTouchDevices': true, /* モバイル端末では左右の移動矢印を常時表示する */
'showImageNumberLabel': false /* 画像の番号を表示しない */
})
</script>
Lightboxは、PC上では画像の上にマウスを載せると、次の画像や前の画像へ移動するための矢印アイコンが画像の左右に表示されます。しかし、マウスのないモバイル端末では表示されません。このalwaysShowNavOnTouchDevicesオプションの値を「true」にすると、モバイル端末(タッチデバイス)では、左右の矢印が常時表示されるようになります。(複数の画像がある場合のみ)
また、Lightboxでは拡大画像の左下に「Image 1 of 20」のような感じで、いま何番目の画像を表示しているのかが案内されます。showImageNumberLabelオプションの値をfalseにすれば、これを非表示にできます。
上記のような書式で指定できるLightboxのオプションは、Lightbox公式サイトに表形式で書かれています。
ギャラリーモード内でも、特定ユーザに限定して表示したり、特定ハッシュタグに限定して表示したりできます。 バリエーションの例は以下のような感じです。
tegalog.cgi?mode=gallerytegalog.cgi?mode=gallery&userid=ユーザIDtegalog.cgi?mode=gallery&tag=ハッシュタグtegalog.cgi?mode=gallery&cat=カテゴリIDtegalog.cgi?mode=gallery&date=日付tegalog.cgi?mode=gallery&q=検索語
上記では1つずつ限定する例しか書きませんでしたが、&記号で区切ることで複数の条件を使って絞り込めます。
tegalog.cgi?mode=gallery&cat=カテゴリID&date=日付 のように書けば、指定のカテゴリIDに属する投稿のうち、指定の日付に合致する投稿だけがギャラリーモードで表示されます。
RSSフィードを出力する ?mode=rss のURLにも、上記と同じ各パラメータを加えてフィードの中身を限定できます。
掲載する画像を装飾するために、画像1つ1つに異なるclass名を加えたい場合もあるでしょう。 例えば「センタリングしたい画像」や「右寄せした上で後続を左側に回り込ませたい画像」など、特殊なレイアウトで表示したい画像を掲載したい場合などです。 そのような場合に使えるテクニックは複数あります。
後述の「掲載バリエーションを複数用意したい場合の秒数活用テクニック」を使う方法もありますので、併せてご参照下さい。
Ver 3.2.0以降には、本文中に直接class名を指定してマークアップできる装飾記法があります。 例えば、以下のⒶように記述すると、Ⓑのように出力されます。
[F:sakura:あいうえお]<span class="deco-sakura">あいうえお</span>この自由装飾機能の中に画像を含めれば、（画像そのものにclass名が加わるわけではありませんが）画像の親要素に自由なclass名を付加できます。
詳しくは、「class名を自由に指定できる装飾記法」をご覧下さい。
ただし、いちいちclass名を自力で書かなければならないので、頻繁に使いたいclass名の場合には少々面倒かも知れません。その場合には、次にご紹介する方法もご検討下さい。
てがろぐでは、本文内に埋め込んだ画像には embeddedimage というclass名が付加されて、実際には例えば下記のようにHTMLが出力されます。
また、文字装飾の「太字」では、指定範囲に decorationB というclass名が付加されて、実際には例えば下記のようにHTMLが出力されます。
このⒶⒷ2点を利用すれば、『ある画像を、太字の装飾内に掲載する』ことで、
……というような出力ができます。
このようにすれば、「decorationB」クラスに含まれる「embeddedimage」クラスを装飾することで、この画像に対してだけ適用できるスタイルを作れます。例えば以下のような感じでCSSソースを書けば良いでしょう。
.decorationB .embeddedimage {
～太字装飾内に含まれる画像用のスタイル～
}
てがろぐ側に用意されている文字装飾の種類数だけしかバリエーションを用意できませんが、その代わり、ボタンクリックだけで専用記法を挿入できるため、いちいちclass名を記述せずに済むメリットがあります。
標準添付の各スキンでは、画像に枠が付いたり影が付いたり半透明になったりする装飾が適用されるようCSSに書いてあります。 CSSソースを編集すれば自由に表示をカスタマイズできますので、記述位置を探して参考にして下さい。
画像を挿入する際に使われる専用記法の共通部分を全文検索の検索語に指定すれば、画像が含まれている投稿だけを検索することもできます。
[PICT:代替文字:ファイルパス]を使った画像が含まれる投稿だけを検索するには、例えば検索語 PICT: で検索すれば良いです。
[IMG:代替文字]URLを使った画像が含まれる投稿だけを検索するには、例えば検索語 IMG: で検索すれば良いです。
PICT:|IMG: で検索すると良いです。
逆に、画像が含まれていない投稿だけを見たい場合は、マイナス検索機能を使って、-PICT: -IMG: のような2単語で検索すると良いでしょう。
OR検索やマイナス検索が使えるのは、Ver 3.2.1以降のみです。OR検索の場合は単語を半角縦棒「|」で区切りますが、その際に空白を入れてはいけません。（縦棒の前後に空白を入れてしまうと、縦棒記号そのものが検索されてしまいます。）
テキストリンクを作る記法は [リンクラベル]https://リンク先URL のような形式ですが、
このリンクラベルに :LB を加えて、[リンクラベル:LB]https://画像URL のように記述すると、テキストリンクでありながらクリックするとLightboxで画像が表示されるリンクになります。
➡ 解説場所を移しましたので、詳しくは、使い方・設定方法ページの「画像を直接埋め込まずに、画像へのテキストリンクとして掲載しつつ、リンク先の画像はLightboxで見せたい場合の書き方」項目をご覧下さい。
Windowsローカル環境では表示される画像が、サーバ上では表示されない場合は、ファイル名の大文字・小文字が一致しているかどうかを確認して下さい。
Windowsは、ファイル名の大文字・小文字を区別しないOSですので、Windows環境だと photo.jpg も Photo.jpg も photo.JPG も同じファイルだと解釈されます。
しかし、サーバで使われているUNIX系OSは、ファイル名の大文字・小文字を区別しますから、 photo.jpg と Photo.jpg と photo.JPG は、すべて異なるファイルだと解釈されます。
もし、画像ファイルは Photo.JPG なのに、てがろぐからは photo.jpg を参照するように書かれている場合、 Windows環境では問題なく表示されますが、 サーバ環境では表示されません。
大量の画像を一括してアップロードしたい場合は、てがろぐ側の機能を使わずにFTPを使って一気にファイルをアップロードしたいと考えることもあるでしょう。 FTPで画像ファイルをアップロードしても問題ありません。（Ver 3.5.0以降）
従来は投稿画像保存用ディレクトリへ任意のファイル名で画像をUPしてしまうと、ファイル名によっては画像一覧画面の最上部に常に表示されてしまって、一覧画面が使いにくくなっていました。（なので非推奨にしていました。） しかし、Ver 3.5.0以降では（正確にはβ版のVer 3.4.1以降では）、FTPでUPされたファイルでも（ファイルのタイムスタンプを参照してソートされるため）新着順に整列するようになりました。
たくさんの画像を一括してUPしたい場合にはFTPでUPすると楽でしょう。
FTPでUPした画像の投稿者は「-」の表示になり、管理者権限を持つユーザしか削除できません。（表示は誰でもできます。）
てがろぐ側の機能で画像をUPすると、ファイル名は「年月日時分秒付番-投稿者ID.拡張子」の法則で付けられます。 画像ファイル名が「20210519195719-nishishi.png」なら、これは2021(年) 05(月) 19(日) 19(時) 57(分) 19(秒) に、ID「nishishi」によってアップロードされた「png」画像ということです。 同時に複数の画像をUPした場合(で拡張子も同じ場合)には、秒の後に連番が付加されます。 FTPで直接アップロードする場合、この法則に則って画像ファイル名を作っておくと、任意のユーザがUPしたことにすることもできます。 これ以外の法則でファイル名を作っても、CGIの動作に特に問題はありません。
下記の画像を用意していますので、ご自身で設置なさったてがろぐCGI上でご自由にご活用下さい。
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
（背景素材）
上記画像のURLを直接指定してお使い下さっても構いませんし、ダウンロードしてご自身のサーバにUPしてお使い下さっても構いません。
上記の画像のURLを知るには、画像を右クリックして「リンクのアドレスをコピー」等の機能をお使い頂くか、画像をクリックして単独で表示させてからブラウザのアドレス欄をコピーするなどして下さい。
てがろぐ用スキンや、てがろぐCGIのユーザアイコン、カスタム絵文字等としてご自由にご活用下さい。
（アイコン提供：京都伏見稲荷ラーメン克享の女将）
投稿1つを単独で表示した場合に本文の末尾に自動挿入されるユーティリティリンク枠（下図1枚目のように「ユーザ×××だけの投稿を見る」などいくつか並んでいる枠）は、要らない場合もあるでしょう。 このユーティリティリンク枠は非表示に設定することもできますし、表示される内容を取捨選択することもできます。
詳しい方法は、カスタマイズ方法ページの「1投稿の単独表示時に見えるユーティリティリンク枠の装飾方法」項目をご覧下さい。
前後のページに移動するリンクは、デフォルト設定では「次の30件 »」のように件数が表示されます。 この件数を削除するには、管理画面の[設定]→[ページの表示]→【ナビゲーションリンクの表示】で、下図の赤丸部分のチェックボックスをOFFにして下さい。
投稿単独表示時には、デフォルト設定では隣接する前後の投稿へ「« No.2235 / No.2237 »」のように投稿番号を使ったリンクが表示されます。 この投稿番号(No.XXX)は表示しないようにもできます。 管理画面の[設定]→[ページの表示]→【ナビゲーションリンクの表示】で、下図の赤丸部分のチェックボックスをOFFにして下さい。
ここをOFFにするだけだと「« No. / No. »」のようなリンクになってしまいますので、適宜左右の入力欄を使って「« 前の投稿 / 次の投稿 »」のような分かりやすい表記を指定して下さい。
投稿単独表示時のナビゲーションリンクでは、左側が古い投稿、右側が新しい投稿です。
この順序を変更する機能はありませんが、古い投稿へのリンクには class="prevlink"が、新しい投稿へのリンクには class="nextlink"が付加されていますので、それらをCSSで使って装飾することで配置を調整することは可能でしょう。
複数の投稿を先頭に固定している際は、管理画面の[設定]→[ページの表示]→【先頭に固定表示する投稿】→『固定表示する投稿番号』欄を見ると、投稿番号が半角カンマ記号で区切られています。 この記述を望みの順序に並べ替えて下さい。
上図の場合は、No.200 → No.1773 → No.568 の順序で先頭に固定されます。
新規投稿時や編集時に、入力欄の下部にある「機能」ボタンを使って先頭に固定したり外したりできるのは、管理者権限を持つIDでアクセスしている際のみです。 管理者権限のないユーザの投稿を先頭に固定するには、管理画面内の上図の場所に管理者が投稿番号を手動で入力する必要があります。（管理者権限のないユーザが、自らの操作で投稿を先頭に固定する方法はありません。）
総ページ数が13ページ以上ある場合に限って、ページ番号リンクの途中を「1・2・3……38・39・40」のように省略して短く表示する機能があります。（標準では無効に設定されており、全ページのリンクが列挙されます。）
その機能を有効にする場合は、 管理画面の[設定]→[ページの表示]→【ナビゲーションリンクの表示】内の『総ページ数が多い場合に途中のページ番号リンクを省略する』チェックボックスにチェックを入れて下さい。 ここをONにするとページ番号リストの途中が省略されるようになります。デフォルトではOFFです。
詳しくは、カスタマイズ方法ページの「ページ番号リンクの装飾方法」項目もご覧下さい。
管理画面内の「投稿の削除/編集」画面に表示されるページ番号リスト（※投稿総数が100件を超えている場合にだけ表示されます）については、 [設定]→[システム設定]→【管理画面内の表示】→[▼管理画面内のUI]にある『総ページ数が多い場合に途中のページ番号リンクを省略する』項目のON/OFFを切り替えて下さい。 こちらは、標準でONです。
Twitterと同じ絵文字を表示する方法として、Twitter社によって「Twemoji」（Twitter絵文字ライブラリ）が提供されています。 これは、CDNサーバにあるJavaScriptを読み込むだけで良いので、てがろぐ外側スキンファイルの末尾あたりに以下の4行を足せば使えます。
<script src="https://unpkg.com/twemoji@latest/dist/twemoji.min.js" crossorigin="anonymous"></script> <script> twemoji.parse(document.body); </script>
例えば標準スキンをお使いの場合、外側スキン skin-cover.html の末尾付近に <!-- ▼遅延読み込みスクリプト群 --> と書かれた箇所があります。
その最下部（＝[[JS:LIGHTBOX:JQ]]の後）に上記の4行を加えると良いでしょう。
特にカスタマイズする必要はありませんので、上記の4行をそのままコピー＆ペーストすれば良いです。
このスクリプトが正しく読み込まれれば、ページ上の絵文字がすべてTwemojiに置き換えられて表示されます。
Twemojiは無償で使えますが、フッタ等にライセンスの表記が必要ですのでご注意下さい。詳しくは、Twemojiサイトをご確認下さい。
イラストの公開用途にお使いの場合などで、TwitterにURLが掲載された際に、画像が大きく表示されて欲しい場合には、OGPの設定画面で大画像が表示されるよう設定できますのでお試し下さい。（デフォルトの設定だと、小さなサムネイルが表示されます。）
管理画面の[設定]→[補助出力]→【OGP＋Twitter Cardの出力】→[▼Twitter Cardの設定]項目内の下部にある「twitter:card」欄で、プルダウンメニューを「summary_large_image (大画像)」という方に切り替えると、常に大きな画像で表示されるようになります。 デフォルトでは「summary (小画像)」が選択されているので、Twitterでは「左側に小さなサムネイル＋右側に概要(抜粋)文章」というような枠で表示されます。
なお、OGPの記述はSNS側でキャッシュされるため、一度でも表示を試したURLの場合は、てがろぐ側の設定を変えてもすぐには表示に反映されない可能性があります。 また、タイミングによっては画像がうまく表示されないことも多々あります。そのうち待てば表示されることもありますので、画像が表示されないからといって「どこか設定がおかしいのだろうか？」とあまり弄らない方が良いと思います。 まずはツイートを試してみて、数時間くらい待っても画像が表示されないようなら、そのときに設定を疑ってみて下さい。(^_^;) Twitterが公式に用意しているCard validatorにURLを入れたときに、右下のLog枠に「Card loaded successfully」と表示されていれば、少なくともTwitter Cardの記述は正しく認識されています。ここでエラーが表示される場合は、正しく出力されていません。
Facebookでの見栄えをプレビューしたい場合は、シェアデバッガーを使って下さい。 ただし、Facebookの場合は、表示されるプレビューサイズを指定する機能はありません。
Ver 3.8.0 以降では、「続きを読む」機能で隠された範囲はOGP＋Twitter Cardには含まれないネタバレ防止仕様になりました。したがって、特別な設定は不要です。
OGP＋Twitter Cardの各種設定方法については、使い方・設定方法ページの「OGP＋Twitter Card用meta要素の出力仕様」項目をご覧下さい。
Ver 3.8.0 以降では、「続きを読む」機能で隠された範囲はRSSフィードには含まれないネタバレ防止仕様になりました。 したがって、基本的には右図のようにRSSフィードでネタバレすることはありません。
しかしながら、『特定の検索結果へのRSSフィード』を購読されている場合には、設定によっては（RSSフィード内で）ネタバレする可能性がありますのでご注意下さい。
具体的には、管理画面の［設定］→［ページの表示］→【投稿本文の表示／テキスト】→「▼続きを読む・指定範囲を隠す 共通設定」区画にある『全文検索時でも隠す機能を有効にする』項目がOFFのとき（※標準でOFFです）、 全文検索結果では「続きを読む」機能を使って隠されている部分も隠されずに最初から表示されます。
てがろぐが生成できるRSSフィードは、各種パラメータを使って収録内容を限定できます。特定のカテゴリに限定したRSSフィードや、特定のハッシュタグに限定したRSSフィード等を配信できるのと同じ要領で、『特定の検索結果のRSSフィード』を生成することもできます。 このとき、先程の設定項目がOFFだと、検索結果のRSSフィードでは「続きを読む」機能を使って隠されている部分は隠されずに出力されます。
先程の設定画面で『全文検索時でも隠す機能を有効にする』項目をONにしておけば、（全文検索時でも隠されるため）特定の検索結果のRSSフィードでも同様に隠されます。
まあ、「検索結果へのRSSフィード」をRSSリーダで読んでいる人は滅多に居ないと思いますけども。(^_^;) 何らかの都合で、「検索結果へのRSSフィード」を登録しやすいような運営をしている場合には、『全文検索時でも隠す機能を有効にする』項目をONにしておく方がネタバレを防げて良いかもしれません、という話です。
RSSフィードに画像もそのまま出力される設定で使っている場合、下記のように設定すれば、ネタバレの危険がある画像だけを代替画像に置き換えて出力できます。(※Ver 3.9.1以降)
上図①のように『OGP(og:image)用の代替画像に差し替える』項目が選択されていると、NSFWフラグ付き画像はRSSフィードには出力されなくなります。
その際の代替画像は、上図②の『その画像がNSFWフラグ付きなら代替画像のURLを使う』項目の下にある「代替画像のURL」欄でURLを指定できます。ここに指定がない場合は、OGP用の共通画像が使われます。この設定は、OGPと共有している設定です。
OGP（og:image）の出力設定に関しては、使い方・設定方法ページの『OGP＋Twitter Card用meta要素の出力仕様』項目にある 「og:image 項目」をご覧下さい。
てがろぐのスキンは、だたのHTMLファイルですから、HTMLファイルを編集できるソフトウェアを使って自由に作成できます。 望みのデザインに最も近い既存スキンを編集する方法でカスタマイズすると楽に書けるでしょう。 望みのデザインに近いスキンがない場合は、デフォルトで採用されている標準スキンを編集すると良いかもしれません。標準スキンには最も多くのコメントが書いてありますから、どの記述が何の役割なのかが分かりやすいでしょう。 もちろん、白紙の状態からすべてを自力で記述しても問題ありません。
スキンの記述方法については、カスタマイズ方法ページで解説していますのでご参照下さい。
カスタマイズ方法ページの中にまとめて記載してあります。 このページの冒頭にある目次の中で「スキンのカスタマイズ方法」項目部分をご参照下さい。
リファレンスは大きく2つ、 「外側スキン用のキーワード(独自タグ)」と 「内側スキン用のキーワード(独自タグ)」とに分かれています。 さらにジャンル別に細かく分類してありますので、これらの場所を直接読む前に、 まずはカスタマイズ方法ページの目次をご覧になる方が目的の記法を探しやすいと思います。
スキンファイルは、HTML5（HTML Living Standard）で記述することを前提にしています。 XHTMLで書くこともできますが、その場合はHTMLファイルの先頭行にXML宣言を書かないで下さい。
外側スキンファイルをXML宣言で書き始めてしまうと、text/htmlではなくapplication/xmlのヘッダを出力する仕様なため、ブラウザによってはウェブページとして表示されない可能性があります。
どうしてもXHTMLでスキンを書きたい場合は、ファイル先頭のXML宣言は書かずに省略して下さい。
スキンの書き方全般については、てがろぐカスタマイズ方法ページをご覧下さい。
XML宣言とは、 <?xml version="1.0" …… のような感じで始まる、XMLのバージョン等を示す記述のことです。
（HTMLの場合は <!DOCTYPE html> のようなDOCTYPE宣言で始めるのが普通です。）
「てがろぐ」では、投稿日時を手動で指定することもできます（標準ではこの機能はOFFです）。
そして、投稿日時を構成する「年/月/日/曜/時/分/秒」は個別に取り出してスキン内で利用できます。
例えば [[DATE:s]] と書けば、投稿時の秒数だけが得られます。（参考：投稿日時関連要素）
この仕様を利用することで、00～59までの計60種類の装飾バリエーションを用意することができます。
投稿本文を作るスキン（内側スキン）で、投稿本文全体を囲む要素に例えば、以下のように書いておきます。
すると、投稿時刻が x時x分25秒 の場合は <div class="mystyle25"> ～ </div> というマークアップが出力されることになります。
この方法を使えば、CSSに以下のような行を加えておくことで、
.mystyle00 { ～装飾1～ }.mystyle01 { ～装飾2～ }.mystyle02 { ～装飾3～ }.mystyle58 { ～装飾59～ }.mystyle59 { ～装飾60～ }00～59までの最大60種類の装飾バリエーションを準備しておけます。
投稿日時を手動で設定しないといけませんが、日記のような用途だと、投稿日時のうち「秒数」はわりとどうでも良いでしょうから、ここを活用する方法も良さそうな気がします。 もっとも、「何番がどんな装飾か」というのを何とかして覚えるなりメモするなりしておく必要がありますが。
投稿1つを囲む枠の色を変えるとか、背景色を変えるなどのように枠そのものを装飾する用途にも使えるでしょうし、 「その枠内の特定の要素」を装飾対象にすることで、例えば以下のような装飾バリエーションを作ることもできるでしょう。
それぞれ、例えば以下のようにCSSを書くとこで用意できます。
/* Ⓐ */ .mystyle10 a { font-family: cursive; }
/* Ⓑ */ .mystyle20 img { display: block; margin: auto; }
/* Ⓒ */ .mystyle30 .decorationQ { background-color: black; color: white; }
どれも、.mystyle番号 に含まれる要素を装飾するよう記述するだけです。
ピンポイントで指定の範囲に指定のclass名を適用させたい場合には、class名を自由に指定できる装飾記法もあります。 この機能の方が、何でも好きなclass名が使える上に、スキンHTMLのカスタマイズが不要なので楽に使えるでしょう。 秒数を活用するテクニックは、もっと大がかりな装飾を複数パターン用意したい場合には便利そうです。
投稿日時を投稿時に手動で設定できるようにするには、管理画面の[設定]→[投稿欄の表示]→【日時ボタンの表示設定】にある『投稿日時の自由入力ボタン「日時」を表示する』チェックボックスにチェックを入れて下さい。ボタンのラベル（デフォルトでは「日時」）は、ここで直接書き換えれば自由に変更できます。
フリースペースの入力欄は1つしかありませんが、下図の赤丸部分のように区切り文字として半角カッコ <> を書くと、そこでフリースペースを分割できます。
すると、それぞれの文章を別々の場所に掲載できるようになります。
分割したフリースペースの掲載方法は、カスタマイズ方法ページの「フリースペースの書き方」項目をご覧下さい。
分割できる個数に上限はありません。
分割できるのはフリースペースの「内容」欄の方だけで、上の「見出し」欄は分割できません。
『そのとき表示されている状況』に応じてページデザイン等の装飾を分けたい場合もあるでしょう。例えば、
……などです。
そのような状況に応じた装飾ができるように、HTMLのbody要素を <body class="[[SITUATION:CLASS]]"> のように書ける仕様を用意しています。
body要素以外の場所に書くこともできますが、body要素のclass属性を使うのが一番使い勝手が良さそうに思います。
詳しくは、カスタマイズ方法ページの「そのときの表示状況に応じてページデザインを切り替える方法」をご覧下さい。
上記のようにbody要素を書いておくと(←重要)、例えば以下のようなCSSを使うことで、特定の状況下でだけ表示できる（または非表示にできる）装飾を作れます。
body.home .homebox { display: block; } /* 表示 */
body:not(.home) .homebox { display: none; } /* 非表示 */
上記のようにCSSを書くと、トップページが表示されているときにだけ .homebox が表示され、それ以外の場面では .homebox は非表示になります。
body.onelog .infobox { display: block; } /* 表示 */
body:not(.onelog) .infobox { display: none; } /* 非表示 */
body.onelog.nohit .infobox { display: none; } /* 非表示 */
上記のようにCSSを書くと、投稿単独ページが表示されているときにだけ .infobox が表示され、それ以外の場面では .infobox は非表示になります。 しかし、存在しない番号の投稿単独ページでは非表示になります。
body.cat-tomoyo.toppage .sakurabox { display: block; } /* 表示 */
body:not(.cat-tomoyo.toppage) .sakurabox { display: none; } /* 非表示 */
上記のようにCSSを書くと、カテゴリ「tomoyo」の1ページ目が表示されているときにだけ .sakurabox が表示され、それ以外の場面では .sakurabox は非表示になります。
指定できる条件は他にも多数ありますので、 詳しくは、カスタマイズ方法ページの「そのときの表示状況に応じてページデザインを切り替える方法」をご覧下さい。
上記のCSS記述例ではあえて /* 表示 */ という記述を併記しましたが、通常の要素は何も装飾しなければ表示されるわけですから、/* 表示 */ の行は書かなくても問題ありません。
ここでは表示/非表示を対比させて分かりやすくしてみただけです。
以下のⒶⒷ2項目でご紹介したテクニックを併用すれば、「トップページだけで表示されるフリースペース」や「投稿単独ページだけで表示されるフリースペース」など、条件に応じて表示されたり表示されなかったりするフリースペースを用意できます。
まず、Ⓐの方法を使って3つのフリースペースを用意し、外側スキンHTMLに以下のように書いてあるとします。
<div class="freespace-general">[[FREESPACE:0]]</div> <div class="freespace-home">[[FREESPACE:1]]</div> <div class="freespace-onelog">[[FREESPACE:2]]</div>
また、Ⓑの方法にあるように、HTMLのbody要素は <body class="[[SITUATION:CLASS]]"> のように書いているとします。
このとき、次のようにCSSを書きます。
以下のようにCSSを書くと、[[FREESPACE:1]]はトップページが表示されている状況でだけ表示され、それ以外の状況では非表示になります。
body.home .freespace-home { display: block; } /* 表示 */
body:not(.home) .freespace-home { display: none; } /* 非表示 */
以下のようにCSSを書くと、[[FREESPACE:2]]は投稿単独ページが表示されている状況でだけ表示され、それ以外の状況では非表示になります。
body.onelog .freespace-onelog { display: block; } /* 表示 */
body:not(.onelog) .freespace-onelog { display: none; } /* 非表示 */
上記のように、特定の条件下でだけ表示されるフリースペースが作れます。
指定できる条件は他にも多数ありますので、 詳しくは、カスタマイズ方法ページの「そのときの表示状況に応じてページデザインを切り替える方法」をご覧下さい。
上記のCSS記述例ではあえて /* 表示 */ という記述を併記しましたが、通常の要素は何も装飾しなければ表示されるわけですから、/* 表示 */ の行は書かなくても問題ありません。
ここでは表示/非表示を対比させて分かりやすくしてみただけです。
スキンをカスタマイズする際に、例えば [[HOGEHOGE]] という記述を一時的に無効化しようと考えて、HTMLのコメントタグを使って <!-- [[HOGEHOGE]] --> のように書きたくなるケースがあると思うのですが、これはお勧めできません。
なぜかというと、 [[HOGEHOGE]] の箇所に実際に挿入されるHTMLソースの中にもHTMLのコメント記法が含まれている場合があるからです。例えば [[HOGEHOGE]] の箇所は
<div class="hagehage"><!-- ▼ここは○○です --><a href="higehige">ふげふげ</a></div>
……のように出力されていることがあります。
このとき、スキンHTMLに <!-- [[HOGEHOGE]] --> と書いてしまうと、実際には
<!-- <div class="hagehage"><!-- ▼ここは○○です --><a href="higehige">ふげふげ</a></div> -->
と出力されてしまいます。
HTMLの文法では、コメントは入れ子構造にできない仕様なので、最初に --> が現れたところでコメントアウトが終わってしまいます。
つまり、上記だと、最後の --> ではなく、半ばの --> でコメントが終わったとブラウザは判断してしまいます。
その結果、HTMLタグの開閉が一致しなくなってレイアウトが崩れてしまいます。 普通は、中途半端に何かが表示されていればコメントアウトがおかしいことに気付くでしょう。 しかし、てがろぐの各種記法には「ある状況でしか中身が挿入されない」という記法がいくつかあります。 そういうものをコメントアウトしていると、『状況によっては何も表示されないために、コメントアウトが中途半端なことに気付かない』というケースがあり得ます。 その場合、ある特定の条件が成立している場合にだけ表示が崩れる、ということになってしまいます。
てがろぐスキン内で使える専用のコメント記法を用意していますので、スキン内で指定範囲をコメントアウトしたい場合はその専用記法を使って下さい。(※Ver 4.4.1以降)
例えば [[HOGEHOGE]] という記法を一時的に無効化するには [[!-- [[HOGEHOGE]] --]] のように書けます。この記法は、外側スキン・内側スキンの両方で使用可能です。
➡ 詳しくは、リファレンスの【コメントアウト】項目をご覧下さい。
上記のコメント記法は、Ver 4.4.1以降でないと使えません。何らかの理由で古いバージョンをサポートする必要がある場合は、以下のような方法があります。
<!-- {{HOGEHOGE}} --> ←カッコの種類を変える
<!-- //HOGEHOGE// --> ←カッコを別の記号にする
<!-- [[ HOGEHOGE ]] --> ←カッコと英字の間に空白を入れる
上記のようにするか、もしくは何か余計な文字を加えるか削るかして、てがろぐCGI側が展開しないような書き方に修正することをお勧め致します。
てがろぐ専用記法（独自タグ）は、半角の角括弧を二重に [[ ～ ]] 使って、空白を挟まずに英大文字でキーワード（タグ名）を書いた場合のみ認識されます。
てがろぐCGIによって出力される何か（投稿そのものでもそれ以外でも可）について、ランダムに配色などの装飾を変化させる方法には、主に以下の2種類があります。
ページを表示する度に異なる色になるようランダムにしたい場合は、専用記法 [[RANDOM:数字]] が使えます。
例えば、[[RANDOM:24]] と書くと、1～24の間（1と24も含む）の数値がランダムに入ります。
ページを再読込するたびに、ランダムに選ばれた値が入ります。（※偶然、同じ数値が連続する可能性はあります。）
この機能を使って、例えば class="mystyle[[RANDOM:12]]" のようにclass属性を書けば、ページを表示する度に
class="mystyle1" ～ class="mystyle12" のいずれかが出力されます。
その結果、12種類の装飾がランダムに選ばれることになります。
投稿本文などを装飾する際に、ランダムに配色を決めたいが、1度決めた後はずっと同じ配色で表示させたい場合には、 大がかりな装飾バリエーションを複数用意したい場合の「秒数」活用テクニックが使えます。
ランダムに配色を変更させたい部分について class="mystyle[[DATE:s]]" のように書いておけば、投稿した瞬間の秒数に応じて
class="mystyle00" ～ class="mystyle59" のいずれかが出力されます。
正確にはランダムではありませんが、投稿した瞬間の「秒」に応じて選ばれるので、ランダムっぽく見せることは可能でしょう。最大60通りの装飾を用意できます。
もし、装飾の選択肢を6種類にしたい場合は、mystyle00 ～ mystyle09 までを同じ装飾にし、
mystyle10 ～ mystyle19 までを同じ装飾にし……、とすると良いでしょう。
この場合、数字は必ず2桁で出力される点に注意して下さい。0秒～9秒の場合は「00」～「09」と出力されます。
カテゴリをアイコンで表示する公式の設定項目はありませんから、少々アクロバットな対処方法になりますが、以下の3通りの方法を使えばカテゴリをアイコンで表示できます。
Ver 3.6.0以降にはカテゴリをアイコンで表示する機能があります。
詳しくは、カスタマイズ方法ページの「カテゴリ表示関連のカスタマイズ方法＆装飾方法」をご覧下さい。
ページ末のCopyright表記等で、1997-2021 のような感じで西暦を入れたい場合、外側スキン内に [[INFO:LASTUPDATE:Y]] と書いておくと、そこに最終更新日の西暦(数字4桁)だけが挿入されます。
最新西暦を手動で書き換えたり、JavaScriptを使って入れたりする手間を掛けなくても簡単に表示できます。
日付関連の挿入記法は、リファレンスの【投稿日時関連要素】をご参照下さい。
外側スキンに [[CALENDAR]] とだけ記述すると、その月のカレンダーだけ(＝1ヶ月分だけ)が表示されますが、
例えば [[CALENDAR:-2]] [[CALENDAR:-1]] [[CALENDAR]] のように記述すると、2ヶ月前から当月までの計3ヶ月分のカレンダーが並んで出力されます。
この方法を使えば、何ヶ月分のカレンダーでも好きなだけ並べられます。
カレンダー関連の記述方法については、リファレンスの【サイドコンテンツ要素】項目をご参照下さい。
また、カレンダー部分の装飾方法については、カスタマイズ方法ページのカレンダー表示の装飾方法項目をご参照下さい。
ハッシュタグの該当件数や、カテゴリの該当件数や、投稿月別の該当件数など、カッコ付きの該当件数を表示したくない場合は、CSSを使うことで簡単に消せます。
該当件数はすべて <span class="num">(38)</span> のようなHTMLで出力されており、必ず隣接する要素で種別（ハッシュタグなのかカテゴリなのか日付なのか）が特定できます。
そのため、以下のようなCSSを書くことで、それぞれの該当件数を非表示にできます。
.taglink + .num { display: none; } ➊.catlink + .num { display: none; }.datelistlink + .num { display: none; }上記のCSS➊は、「taglink」というclass名が付いている要素の隣(直後)にある「num」というclass名が付いている要素を非表示にする、という意味になります。 （※CSSのセレクタに使う「+」記号は、隣接兄弟結合子として機能します。）
単に .num だけを対象にしてしまうと、他の場所にある様々な数値もいろいろ消えてしまうのでご注意下さい。(^_^;)
状況に応じた見出しに（そのときの表示条件に合致している投稿の）該当件数が出るのを削除したい場合は、管理画面の[設定]→[ページの表示]→【ページの表示／全体】→[▼状況に応じた見出しの表示]にある、『該当件数を表示』チェックボックスをOFFにして下さい。
主に、カスタマイズ方法ページで、様々な部分を独自に細かく装飾する方法を解説していますのでご参照下さい。
そのほか、よく頂くご質問などを列挙しておきます。
あくまでも「厳密に比較すれば遅くなる」というだけのことであって、おそらく実際にはミリ秒単位の差しかないだろうとは思いますから、体感できるほどの違いが出ることは滅多にないでしょう。 したがって、あまり気にしなくても問題ありません。
なので「実際に試してみて問題がなければ問題はない」と言っても構わないのですが、まあ塵も積もれば山となるということで、負荷は低いに越したことはありませんから、一応は注意書きを加えています。 「○○すると重たくなります」と書かれている方法を避けても望みが実現可能なら、避ける方をお勧め致します。
データファイルに含まれる投稿件数が多くなってくれば、もしかすると体感できるほどの差が現れるかもしれません。
同じです。_(┐｢ε:)_
解説ドキュメントには「投稿ID」と「投稿番号」の用語が混在していますが、どちらも同じ意味です。そのときの気分で「ID」と書いたり「番号」と書いたりしていたようです。┌(:3」└)┐
投稿1つ1つに付与されるIDは「1以上の整数」で（削除しない限りは）連番で付与されます。「投稿ID（投稿番号）に上限はある？」項目も併せてご覧下さい。
てがろぐ配布ページTOPの「CGIのダウンロード」区画では、最新版よりも古い過去3バージョンまで配布していますので、そこからダウンロード頂けます。
最新版で何らかの問題があって旧バージョンに戻したい場合にご利用下さい。
最新バージョンには常に不具合の修正等も含まれていますから、特に問題がない限りは最新版をダウンロードしてご使用下さい。
また、最新版の導入で何らかの問題が発生した場合には、その旨をお知らせ頂けると助かります。
β版のテストにご協力をどうもありがとうございます。 β版として配布しているパッケージ（ZIPファイル）には、『直前の正式版パッケージ（ZIPファイル）と比べて更新したファイルだけ』しか含んでいません。 tegalog.cgi と fumycts.pl の2ファイルしか含まれていない場合も多々あります。
既に稼働しているてがろぐCGIがある場合は、そこへ tegalog.cgi と fumycts.pl の2ファイルを上書きアップロードすれば、最新β版として機能します。
β版を使って新規にセットアップしたい場合は、以下の手順で作業して下さい。
すると、最新の状態で新規セットアップができます。
したがって、β版のZIPには tegalog.xml , tegalog.ini , psif.cgi の3ファイルは常に含まれません。 逆に、tegalog.cgi と fumycts.pl の2ファイルは必ず含まれています。
今のところありませんが、自己登録型のリンク集ページを用意するつもりでは考えています。
今すぐにご自分の設置てがろぐをアピールなさりたい場合は、てがろぐ試験動作場へご自由にお書き込み下さい。(^_^)
作者が直接関与しているわけではありませんが、 「てがろぐ」を使っている創作系サイトを中心にした自己登録型のリンク集サイトとして 「てがWA!」というサイトがあります。
すみません。今のところは「仕様」です。(^_^;)
※非ログイン状態で投稿ボタンを押したときにはログイン画面が出てきますが、（今のところ）ログインできた後の投稿画面に引き継がれるのは投稿本文のみです。それ以外の情報は一切引き継がれません。
そのうち改善する可能性はあります。しかし、てがろぐはたいていログインしっぱなしで使われることが多そうなので、あまり解決の優先度が高いとは考えていません。^^;
Ver 3.8.0以降では、パスワードで保護された「鍵付き投稿」ができる機能が追加されました。詳しくは、使い方・設定方法ページの「鍵付き投稿（パスワード保護）機能の使い方」をご覧下さい。
なお、投稿単位ではなく、ページ全体をパスワードで閲覧制限したい場合は、Basic認証（基本認証）をお使いになるのが簡単です。 てがろぐCGIは、Basic認証の内側でも問題なく動作します。
Basic認証については、お使いのサーバ等のヘルプをご参照下さい。 .htaccessファイルに指定の記述を加えて .htpasswd等のパスワードファイルを作ると使えます。
特定のカテゴリだけをRSSフィードにすることも可能です。
例えば tegalog.cgi?cat=sakuratan&mode=rss のURLにアクセスすると、カテゴリID「sakuratan」の投稿に限定したRSSフィードが出力されます。
てがろぐCGIでは、今のURLの末尾に &mode=rss と加えれば、今見ている内容(＝限定条件)をそのままRSSフィードにできます。
なので、任意の単語の検索結果すらもRSSフィードにすることもできます。
もちろん、カテゴリの他にハッシュタグでもRSSフィードにできます。ある特定の種類の投稿だけをRSSでお知らせしたい場合などにご活用下さい。
使い方・設定方法ページの、 RSSフィードの出力項目や 条件を限定したRSSフィードの出力項目もご参照下さい。
てがろぐ Ver.3 以降なら、アスキーモード（テキストモード）のないFTPソフトでアップロードしても問題なく動く可能性が高いです(※)。まずは、お試し下さい。
アスキーモードでの転送が必要なのは、「CGIソース内の改行コード」を「サーバ側が求める改行コード」と一致するよう自動変換する必要があるからです。 したがって、その変換をローカルのテキストエディタ等で済ませておけるなら、アスキーモードのないFTPソフトを使ってアップロードしても問題ありません。 詳しくは、「アスキーモードで転送したかどうかを確認」項目をご覧下さい。
※てがろぐ Ver.3 以降の tegalog.cgi や fumycts.pl ファイルは、改行コードがUNIX標準の[LF]になっています。 たいていのウェブサーバが求める改行コードも[LF]でしょう。 したがって、たいていのウェブサーバで一致するでしょうから、アスキーモードのないFTPソフトでアップロードしても問題ない可能性が高いです。
システム面では特に問題はありません。（お使いのサーバで禁止されていないかどうかは事前にご確認下さい。）
チャット用途として使う場合は、ページを何度も再読込することになりますから、できるだけ軽いスキンを作って使う方が望ましいとは思います。 標準添付のチャットスキンをカスタマイズして、極限まで不要な部分を削除するなどするのがおすすめです。
なお、以下の面は若干面倒かもしれません。
エクスポート機能がありますから、終わった後に発言を一括ダウンロードするのは簡単で良いかもしれません。
なお、実際にチャット用途にお使いになった方から、「数人程度ならチャットとしての使用は問題はなさそう」という報告は受けています。(╹◡╹)
「Powered by てがろぐ」の文言は、ライセンスをご取得頂くことで、非表示に設定することはできます。 詳しくは、CGI使用条件（ライセンス）項目をご覧下さい。
ライセンスは主に法人サイト向けを考えて提供しているものですが、個人の方でもご希望ならご取得頂けます。
ライセンスは「Powered by てがろぐ」の文言を見えなくするための権利なので、ライセンスがあっても、管理画面の左下端に常時見えている著作権表示（Copyright表記）を削除してお使いになることはできません。
カスタマイズ方法ページの「著作権表示とPowered-by表記について」もご参照下さい。
てがろぐは、法人サイト・商用サイト等でも無料でご使用頂けます。特に注意点というほどのことはありませんが、強いて挙げれば次の3点があります。
なお、定期的に最新版のリリース情報を確認して、できるだけ常に最新版を使うような運用ができる体制でお使い頂くのが望ましい点もご留意下さい。
詳しくは、CGI使用条件（ライセンス）項目をご覧下さい。 また、カスタマイズ方法ページの「著作権表示とPowered-by表記について」も併せてご参照下さい。
このページに掲載する前に、てがろぐ動作試験版で、#🌱豆知識というハッシュタグを使って投稿していることがあります。 そちらも覗いてみて下さい。
ご質問もお気軽にどうぞ。
てがろぐ配布トップページに記載してあるフィードバック方法のご案内をご覧下さい。
事実上のサポート掲示板になっている、てがろぐ動作試験版へご投稿頂くのが今のところは一番な気がします。 返信には数日かかることもありますのであらかじめご了承下さい。
作者にカフェインを供給するには、こちらをご覧下さい。(╹◡╹)ﾉ
いつでも歓迎致します。
管理画面TOPの右上に表示されている「このCGIについて」枠内からもアクセスできます。
てがろぐCGIをご活用下さっていることが分かることが何よりのモチベーション維持に役立ちます。例えば、
……などの方法があります。
さらに、
……なども極めて歓迎致します。ぜひよろしくです。(╹◡╹)ﾉ
作者へのご連絡は、フィードバック方法のご案内をご覧下さい。