動作要件はとても緩いので、たいていのウェブサーバでは何も気にせず8ファイルをアップロードするだけで使える場合も多そうな気がします。
Perl5さえ使えればたいてい動作します。データベースは不要です。
お手軽マイクロブログCGI「てがろぐ」のセットアップ方法です。お使いのサーバに設置する手順を解説しています。
手順と言っても基本は全ファイルをアップロードして、パーミッションを設定するだけです。簡単です。本当に簡単です。説明が長いのは、念のための補足説明が多いだけで、必須の手順はわずか3ステップです。
《最終更新： 2022年09月21日 》
動作要件はとても緩いので、たいていのウェブサーバでは何も気にせず8ファイルをアップロードするだけで使える場合も多そうな気がします。
Perl5さえ使えればたいてい動作します。データベースは不要です。
当サイトは、「さくらインターネット」のサーバ上で公開されています。
てがろぐCGIの動作テストも、さくらインターネットのサーバで実施しています。さくらインターネットをお使いなら、何も書き換えることなくそのままアップロードしてパーミッションを正しく設定すれば動きます。
てがろぐのセットアップ方法は、ダウンロードしたZIPファイル（※ダウンロードはてがろぐ公式TOPページから）を展開して、出てきたファイルをWebサーバの任意の場所にアップロードして、下表に記したパーミッション(アクセス権/属性)に設定するだけです。 ただし、サーバによっては、てがろぐCGI本体（tegalog.cgi）の1行目を、サーバ側が要求するように事前に書き換えておく必要があります。
したがって、セットアップ手順は下記の3ステップだけです。
これだけで動作します。
最近のウェブサーバなら、おそらく特に何も書き換えずにそのままアップロードするだけで動くことが多いです。
なので、まずは何も書き換えずに「設置手順2」へ進んで下さい。
もし、最終的に（設置手順3の後で）「500 Internal Server Error」が出るようなら、
CGIソースの1行目にある #! /usr/bin/env perl の記述を、例えば #! /usr/bin/perl や #! /usr/local/bin/perl などに書き換える必要があります。
その場合は、tegalog.cgi をテキストエディタで開いて、1行目をサーバ会社が指定する通りに書き換えて下さい。
例えば、
説明用の「README.TXT」ファイルを除くすべてのファイルを任意のディレクトリにアップロードして下さい。
その際、FTPソフトの設定は「アスキーモード」（テキストモード）にする方が無難です。
設置後のディレクトリ構造は下図のようになります。
自由に作成したサーバ上のディレクトリへ、必要なファイルをアップロードすれば良いだけです。サブフォルダも含めてアップロードする場合は、フォルダ構造(階層構造)を維持したままアップロードして下さい。
考えるのが面倒なら、とりあえず全部アップロードすれば良いです。(笑)
図の左側は最小限のファイルだけで使う場合のディレクトリ構造、中央は最小限のファイルだけで使う場合の推奨形態、右側は完全版の全ファイルをUPする場合のディレクトリ構造です。 （※backupサブディレクトリはデータの自動バックアップのために必要で、imagesサブディレクトリは画像を投稿できるようにするために必要です。なので、この2ディレクトリだけは最小構成で使う場合でもある方が望ましいです。）
※FTPソフトでアップロードする際に、転送モードが「バイナリモード」になっていると、CGIソース内の改行コードが正しく変換されないために、ブラウザでは「500 Internal Server Error」が表示される場合があります。 その場合は、FTPソフトの設定を確認してみて下さい。
※FTPソフトを使わずに、Webサーバのコントロールパネルからファイルをアップロードすると、バイナリモードでアップロードすることになってしまい、うまく動作しないことがあります。 その場合は、FFFTPなどのFTPソフトを使ってアップロードして見て下さい。 （どうしてもそのようなソフトウェアが利用できない場合は、一旦 tegalog.cgi と fumycts.pl をテキストエディタで読み込み、改行コードをお使いのWebサーバに合わせて変更した上で上書き保存し、アップロードして下さい。）
アップロードしたファイルのパーミッション(アクセス権/属性)を下表のように設定して下さい。
※特に、さくらインターネット、ロリポップ、Xserver、XREA、usamimi.info、fya.jp等に設置する場合は「suEXEC」側のパーミッションに設定して下さい。 お使いのウェブサーバで「suEXEC」という安全な仕組みが有効になっている場合は「suEXEC」側の値を設定しないと動かない可能性があります。（特にディレクトリの設定は絶対ですので気をつけて下さい。）
| ファイル名 | パーミッション 一般の場合 / suEXEC | 補足 | |
|---|---|---|---|
| ▼プログラムファイル | |||
| tegalog.cgi | 755 | 700 | メインCGI （これを実行します） ※0 |
| fumycts.pl | 644 | 600 | 補助プログラム （メインCGIから呼び出されます） |
| ▼データファイル（CGIによって書き換えられるファイル） | |||
| tegalog.xml | 666 | 604 | 投稿データ記録用ファイル（CGIによって編集されます） ※1,2 |
| tegalog.ini | 666 | 604 | 設定記録用ファイル（CGIによって編集されます） ※1,3 |
| psif.cgi | 666 | 600 | パスワード・セッションID格納ファイル（CGIによって編集されます） ※1,4 |
| ▼表示HTML関連ファイル | |||
| skin-cover.html | 644 | 604 | 表示用スキンファイル（テンプレートHTMLファイル：外側用） ※1 |
| skin-onelog.html | 644 | 604 | 表示用スキンファイル（テンプレートHTMLファイル：内側用） ※1 |
| tegalog.css | 644 | 604 | 表示用スタイルシートファイル ※1,5 |
| ▼サブディレクトリ（※設置は任意） | |||
| backup | 766 | 705 | 自動バックアップファイルが蓄積されるディレクトリ ※6 |
| images | 766 | 705 | 投稿画像ファイルが蓄積されるディレクトリ ※6 |
| skin-* | 755 | 705 | 別スキンは「1スキン1サブディレクトリ」で置けます。 ※7 |
※0：ファイル名を「index.cgi」に変更しても動作可能ですが、それよりは『ファイル名「tegalog.cgi」を省略してアクセス可能にする方法』の採用がお勧めです。
※1：ファイル名は自由に変更可能です。（ファイル名の変更内容は tegalog.cgi 内に反映させる必要があります。よく分からない場合はデフォルトのままご使用下さい。）
※2：ファイル拡張子は.xml以外に変更しても構いません。（記録形式はXMLです。）
※3：ファイル拡張子は.ini以外に変更しても構いません。（記録形式はINIベースの独自仕様です。）
※4：ファイル拡張子は.cgi以外でも構いませんが、外部から閲覧されるのを防ぐために「.cgi」にしてあります。他の拡張子に変更する場合は、.htaccessファイルなどを使って中身が閲覧されないように設定して下さい。ログイン用のパスワードを忘れてしまった場合は、このファイルの中身を空っぽにして再度アップロードすると、無条件ログインが可能になります。
※5：ファイル拡張子は.cssでなければなりません。ファイル名は、skin-cover.htmlのlink要素に書かれているファイル名に合わせる必要があります（スキンによっては tegalog.css ではない場合もあります）。
※6：このディレクトリには「書き込み権限」の付与が必須です。しかし、サーバでsuEXECが使われている場合は、705等の一般的な値のままで正しく動作します。その場合は、766などに設定すると（主に画像表示の面で）正しく動作しなくなります。
※7：ディレクトリ名は何でも構いません。必ずしも「skin-」で始まっている必要はありません。
ウェブサーバによっては、上記の「755」や「644」などのパーミッション(アクセス権/属性)値は「705」や「604」のように真ん中をゼロにしないといけない場合があります。詳しくはウェブサーバのヘルプをご参照下さい。
さくらインターネット、ロリポップ、Xserver、XREA、usamimi.info、fya.jpなどのサーバに設置する場合は、上表にある「suEXEC」側の値を設定して下さい。 特にディレクトリのパーミッションを誤って「一般の場合」の値に設定してしまうと、例えば「画像投稿処理は完了できるのに、画像が一切表示されない」といった動作上の不具合が起こります。（パーミッションを正しく設定し直せば解決します。）
ZIP内に含まれている「Readme.txt」ファイルは、アップロードしないで下さい。解説を記述したただのテキストファイルですから。
➡ ここまで完了したら、もう動作するハズです。
動作を試す際には、ブラウザで tegalog.cgi にアクセスする必要がある点にご注意下さい。自身で何らかの工夫をしない限り、ディレクトリ名までのURLにアクセスしても表示されません。 ディレクトリ名までのURLで動くようにしたい場合は、さらに『ファイル名「tegalog.cgi」を省略してアクセス可能にする方法』をご参照下さい。
てがろぐには、複数のスキンをアップロードしておいて、別スキンを一時的に適用する(スキンを切り替える)機能があります。
その機能を使う場合は、「1スキン＝1サブディレクトリ」の階層構造でアップロードして下さい。ディレクトリ名は何でも構いません。
スキンファイルは、置き場所に応じて以下のように扱われます。
てがろぐVer 1.4.0以降には、CGIの管理画面上で本番適用スキンを切り替えられる機能があります。 しかし、本番適用するスキンはCGIと同じディレクトリにスキンファイルを置いておく方が、より高速に動作します。 使用するスキンが確実に決まった場合には、スキンファイルを物理的に移動しておくことをお勧め致します。
別スキンの適用方法やスキン内の各ファイルの役割については、カスタマイズ方法ページ内のスキンをカスタマイズする際に書き換えるファイルもご参照下さい。
配布ファイルの文字コードは、すべて UTF-8 になっています。
UTF-8コード以外での動作は想定していませんし実験もしていません。
文字コードは、UTF-8のままアップロードされることをお勧めしますが、他の文字コードを使用したい場合は、全ファイルを使用したい文字コードに変換した上でアップロードして下さい。一部のファイルだけ文字コードを変えると、文字化けが起こります。
（文字コードを変更した場合は、tegalog.cgi の68行目を適切に書き換える必要があります。）
よく分からない場合は、文字コードを変換せずUTF-8コードのままご使用下さい。
データファイル内には、サンプルデータが含まれています。 サンプルデータが不要なら（※当然不要でしょうが：^^;）最初に使用する際に管理画面上で削除して下さい。 もしくは、中身が空のデータファイル(tegalog.xml)を新しく作成してからアップロードしても構いません。しかし、ファイル自体のアップロードを省略すると、動作時にエラーになります。
最新版のCGI一式は、TOPページの「CGIのダウンロード」区画からダウンロードできます。
最新バージョンで新たに追加された機能や修正された不具合等の案内は、リリースノートでご覧頂けます。追加機能ごとに公式ヘルプ各ページへのリンクも用意していますので参考にして下さい。
以前のバージョンをお使いの場合は、 tegalog.cgi と fumycts.pl の2つのファイルのみを上書きアップロードして下さい。
それ以外のファイルをアップロードする必要はありません。
特に、データファイル(tegalog.xml)を上書きしてしまうと、過去のデータが消えてしまいますので、くれぐれもご注意下さい。
なお、CGIソースに直接記述する形の設定は、上書きするとデフォルト設定に戻ってしまいます。アップロードする前に、以前と同じように編集しておいて下さい。
「今までは動いていたのに、バージョンアップすると動かない！」という場合は、CGI本体（tegalog.cgi）1行目の記述を書き換え忘れていないか確認して下さい。 ただし、Ver 3.7.0以降では、ほとんど環境で1行目を書き換える必要はなくなっています。まずは何も書き換えずに上書きしてみて下さい。 そのほか、トラブルシューティング区画の「500 Internal Server Errorになってしまう場合の対処方法」項目などもご参照下さい。
データファイルはそのままの状態で、CGIを最新版に更新するだけで使い続けられます。
※Ver 1.x系から Ver.2系 へのアップグレード時でも、データファイルや設定ファイルはそのまま引き継げます。
※Ver 2.x系から Ver.3系 へのアップグレード時でも、データファイルや設定ファイルはそのまま引き継げます。
Ver 1.x系から一気に Ver.3系 へアップグレードする場合でも、データファイルや設定ファイルはそのまま引き継げます。
もし、配布されているスキンをそのまま利用している場合は、スキンファイル群も同時に上書きアップロードすれば、新しく加わった表示機能を簡単に活用できます。 スキンをカスタマイズして使っている場合は、上書きアップロードはしないようご注意下さい。その際は、新パッケージに含まれるスキンHTMLやCSSの中身を別途ご覧になりつつ既存スキンを編集すると、カスタマイズしやすいでしょう。
標準添付のスキンはいろいろありますが、スキンのHTMLやCSSソース内に最も詳しくコメントを書き添えてあるのは「標準スキン」です。 新しい機能に関する書き方を、ソースを読んで知ろうとする場合には、「標準スキン」のソースをご覧になることをお勧め致します。
もし自動バックアップ機能を有効にしている場合は、バックアップ蓄積ディレクトリの中に、直前までのデータファイルが存在します。
データが失われてしまった際には、バックアップ蓄積ディレクトリの中にある最新日付のファイルをダウンロードして、ファイル名を変更し、CGIと同じディレクトリにアップロードすれば（バックアップされた時点のデータが）回復します。
てがろぐ本体を置いたディレクトリに「.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でもアクセスできるようになっています。
投稿画像を蓄積するための「images」サブディレクトリのパーミッション設定が誤っていないかどうかを確認してみて下さい。
画像の投稿はエラーなく完了するのに、表示だけがされないという場合は、ほぼ間違いなく、imagesディレクトリのパーミッションの設定を 766 にしてしまっていることが原因です。755や705などに変更して下さい。
「suEXEC」という安全な仕組みが有効のサーバ（さくらインターネットやロリポップなどもそうです）では、ディレクトリのパーミッションを誤って「一般の場合」の値に設定してしまうと、「画像投稿は完了するのに、画像が一切表示されない」という動作上の不具合が起こります。 ディレクトリのパーミッションを正しく設定し直せば解決します。
suEXECという安全な仕組みが有効なサーバでは、サブディレクトリのパーミッションはデフォルトのまま（755など）で構いません。
ここで（全員に書き込み権限を付加する意味の）766 にしてしまうと、そのサブディレクトリに格納されたあらゆるファイルは（安全のために）表示されなくなります。
その場合は、サブディレクトリのパーミッションを 755 や 705 に変更すると表示されるようになります。755 か 705 のどちらに設定すべきかは、サーバのヘルプをご参照になるか、または他のディレクトリのパーミッションを確認すると良いでしょう。（さくらインターネットやロリポップでは 705 にして下さい。）
※各ファイルのパーミッションの値については、セットアップ(設置)方法ページの「設置方法3：パーミッションの設定」をご参照下さい。
構成ファイル群をアップロードしたハズなのに、ブラウザでアクセスすると「404 Not Found」や「403 Forbidden」のエラーが出てしまう場合は、tegalog.cgi にアクセスしているかどうかを確認して下さい。
自身で何らかの工夫をしない限り、「ディレクトリ名までの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になってしまう場合」項目を参考にしてみて下さい。
どうしてもエラーが解消しない場合は、試しに別のディレクトリに新規セットアップを試してみて下さい。それで動作するなら、バージョンアップの過程に何か問題があります。
CGIの構成ファイルを「アスキーモード（テキストモード）」でアップロードしたかどうかを確認して下さい。 バイナリモードでアップロードしてしまうと、改行コードが正しく変換されずに、Internal Server Errorになることがあります。 試しに、アスキーモードであることを確認した上でアップロードし直してみて下さい。
配布ファイルの改行コードは、てがろぐVer 2.xまではWindows標準の[CR]+[LF]でした。この場合、たいていのウェブサーバとは異なります。 てがろぐVer.3以降はUNIX標準の[LF]になっています。この場合、たいていのウェブサーバとは一致するでしょうが、必ず一致するとは限りません。なので、念のためにアスキーモードで転送する方が無難です。
もし改行コードが自動変換されない方法でアップロードしたい場合（Webサーバのコントロールパネル経由でアップロードしたい場合など）は、任意の改行コードで上書き保存できるテキストエディタ（例えばEmEditor）を使って、改行コードをWebサーバの仕様に合わせて上書き保存した上でアップロードしてみて下さい。
（たいていのWebサーバではUNIX系OSが使われていますから、改行コードは[LF]にする必要があります。）
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の最新版をお使い下さい。）
ウェブサーバ側で指定されているパーミッションの設定方法が「一般の場合」か「suEXECの場合」かを確認して下さい。
suEXECという安全な仕組みが採用されているサーバでは、「suEXECの場合」に示したパーミッションを設定しないと動作しないことがあります。
（特に、ディレクトリに対してGroupやOtherへ書き込み権限を付与すると動作しません。） 設定値は、パーミッションの設定をご覧下さい。
特に、次に挙げる各レンタルサーバでは、suEXEC側の設定にする必要があります。
さくらインターネット、ロリポップ、Xserver、XREA、usamimi.info、fya.jp など。
※suEXECの方がセキュリティ面で安全な仕組みなので、suEXECを採用しているサーバは多数あります。たいていサーバのヘルプに記載がありますから、サイト内検索やページ内検索等で調べてみて下さい。
ローカル環境や自力でセットアップしたサーバ等で稼働させる場合には、必須のPerlモジュールがサーバにインストールされていない可能性があります。 CGIの設置環境要件の記述をご確認頂き、不足していればインストールして下さい。
権限の問題でサーバにモジュールをインストールできなくても、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ワードを避ければ良いだけなので、以下の2通りの対策が考えられます。
/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のせいというわけでもないのかもしれません。とすると、ロリポップサーバでは（どうやっても）受け入れるしかない仕様なのかもしれません。^^;（解決できる設定方法を発見された場合は、ぜひお知らせ下さい。）
投稿時や設定変更時に「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以降にバージョンアップしてみて下さい。
普段お使いのブラウザ以外のブラウザでもログインを試してみて下さい。それでうまくいくなら、お使いのブラウザのキャッシュ設定が強すぎる可能性があります。 他のブラウザでも同様の問題が発生する場合は、サーバ側のキャッシュ設定が強すぎる可能性があります。
レンタルサーバのロリポップでこの問題が発生する場合は、ロリポップアクセラレータを無効に設定してみて下さい。
埋め込み合成用のスキンを使った表示結果を、SSIやPHPなどを使って他ページに合成している場合では、画像やハッシュタグリンクなどのリンク先が(相対パスで出力されるために)リンク切れになってしまう可能性があります。 その際は、下記の設定項目（黄色矢印部分と水色矢印の部分）にチェックを入れておくと、それぞれが絶対URIで出力されるようになるため、リンク切れにならずに済みます。
出力結果を別ページに埋め込む際の設定方法（注意点）には他にも少々ありますので、詳しくは、あるスキンの出力結果を別のページに埋め込む方法をご覧下さい。
※複数のスキンを併用しているなど、『一時適用中のスキンを維持できるリンクを出力する』のチェックを外す方法を避けたいなら、JavaScriptを使ってリンク先URLを動的に編集する方法もあります。詳しくは上記ページをご覧下さい。
最新版の tegalog.cgi と fumycts.pl をアップロードしたのに、Web上のてがろぐがバージョンアップされておらず旧バージョンのままに見える場合は、下記の点をご確認下さい。
なお、tegalog.cgi は index.cgi に改名しても動作しますが、そうしなくても、.htaccessファイルに1行書いておくだけで、ファイル名は tegalog.cgi のままで「 / 」で終わる短いURLでアクセス可能にできます。 詳しくは、わざわざファイル名を index.cgi に変更しなくても、「/」で終わるURLでアクセスできるようにする方法をご覧下さい。
てがろぐCGIは、HTTPS環境でも問題なく動作します。 もし、SSL証明書を導入してHTTPS化したにもかかわらず、ブラウザのアドレス欄に緑色の錠前アイコン(🔒)ではなく黄色の警告アイコン(⚠)が表示されてしまう場合は、表示ページ内のどこかでHTTP決め打ち（ http://～ のURL）の画像などが読み込まれている可能性があります。 特に、『ユーザアイコンのURLが「http://～」で書かれている』というケースが散見されますので、ぜひご確認下さい。
HTTPSアクセス時に黄色の警告アイコンが出る場合は、たいてい以下の理由です。
ページに埋め込む画像をURLで指定する場合に、https://～ ではなく http://～ で書いてしまうケースはよくあります。 てがろぐの場合、特にユーザアイコンの設定は見落とされがちな気がします。 ユーザアイコンは、管理画面の「ユーザIDを管理」からユーザ別に設定できます。
ユーザアイコンのURLは https:// から書かなくても、「/」で始まる絶対パスで書くこともできますし、CGI本体の設置場所を基準にした相対パスで書くこともできます。
また、CGI本体と同じディレクトリに画像ファイルを置いているなら、単に画像ファイル名を書くだけでも表示可能です。
※ユーザアイコンは、CGIの存在する位置からの相対パスで指定するか、サーバルートからの絶対パスで指定するのがお勧めです。
にっちもさっちもいかなくなった場合は、作者までお問い合わせ下さい。 その際は、発生している問題の詳細、設置場所(URL)、お使いのサーバ会社名など、できるだけ詳しい情報をお知らせ頂けると、話が早く進みます。 サーバのエラーログがあるととても望ましいです。
1つ1つを異なるディレクトリにアップロードして下さい。例えば以下のような感じです。
ディレクトリ名は何でも構いません。要は、「1つのてがろぐ＝1ディレクトリ」で構成されていれば問題ありません。
CGIやデータファイル等の全構成ファイルの名称を変更すれば同一ディレクトリ内に複数のCGIを設置することも不可能ではありませんが、お勧めはできません。 また、そのような稼働方法では動作試験をしていません。
てがろぐCGIを複数個設置する場合で、それぞれのCGIを新規にセットアップしたなら、以下の設定は（ほとんどの場合で）不要です。
しかし、「既に稼働しているてがろぐCGI」の全構成ファイルをコピーする方法で2つ目のCGIを設置した場合(※1)には、以下の設定を手動で行う必要があります。
※1：正確には、他の場所で既に稼働していたCGIの tegalog.ini ファイルをコピーして流用した場合には、以下の設定が必要になります。
管理画面の「設定」→「システム設定」→「ログイン維持設定」区画内にある『このCGI固有の識別文字列』項目に入力されている数文字の英数字を、他のCGIと重複しない文字列に変更して下さい。 文字数に制限はありませんが、Cookieの接尾辞に使われますので、5文字前後くらいにしておくのが無難だと思います。
《▼なぜこの設定が必要か？》
てがろぐCGIのログイン状態は、ブラウザのCookieを利用して維持されます。 同一サーバ内に設置するCGIで、もし同じCookie名を流用してしまうと、1つのドメインにつき1つのログイン状態しか維持できません。 そのため、どれか1つにログインすると、他のすべてのログイン状態は解除されてしまいます。
それを防ぎ、すべてのCGIで個別にログイン状態を維持できるように、別々のCookieを発行してログイン状態を維持できる仕様になっています。 それぞれのCGIを別個に識別する目的で異なるCookie名を利用するために、1つ1つのCGIで異なる識別文字列が必要です。 （入力した識別文字列がそのままCookie名になるわけではなく、ベースのCookie名に付加される接尾辞として使われます。）
その識別文字列を設定するのが、『このCGI固有の識別文字列』項目です。
新規にセットアップした場合は、この識別文字列には5文字の英数字がランダムに入りますので、（確率的にはほとんどの場合で）他とは異なる文字列が指定されています。 そのため、手動で識別文字列を書き換える必要性は（ほぼ）ありません。 9億分の1くらいの確率で同じ識別文字列が偶然設定されてしまう可能性はありますが。(^_^;)
設置するドメインが異なっていれば、同じ識別文字列を使っても問題ありません。（同じ識別文字列を使うメリットは何もありませんが。）
設定で「このCGI固有の識別文字列」項目を書き換えるたびに、認証状態を保持するCookie名が変わるため、全ユーザが自動ログアウトされてしまいますのでご注意下さい。 （それぞれのユーザが再度ログインすれば、それ以後はまたログイン状態を維持できます。）
設定で「このCGI固有の識別文字列」項目を書き換えた結果として全ユーザがログアウトしてしまった場合は、サーバ側に保存してある既存の認証記録は消えないため、管理画面TOPの下部に表示されている「ログイン人数」の表示は減りません。 そのままでは正しいカウント値になりませんので、それが気になる場合は、設定を変更した後に一度だけ、管理画面から「全員を強制ログアウト」ボタンを押してサーバ側の認証記録をクリアして下さい。 すると、サーバ側に保存してある認証記録がすべて消えるために「ログイン人数」のカウント値が0に戻りますから、それ以後は正しいログイン件数が表示されます。
同じ識別文字列を指定しても、IDやパスワードを共用できるわけではありません。 同じ識別文字列を指定しても、不便になるだけでメリットは何もありません。
複数のてがろぐCGI間でIDやパスワードを共用する方法はありません。
ただし、既に稼働しているCGIから tegalog.ini と psif.cgi の2ファイルをコピーしてセットアップすれば、既に設定されていたIDとパスワードをコピー(流用)して使うことは可能です。
（※同時にその他の設定も引き継がれます。識別文字列も引き継がれるため、セットアップ後に修正が必要です。また、日付別カウント数・ハッシュタグカウント数・カテゴリカウント数なども引き継がれてしまうため、その方法でセットアップした場合は、セットアップ後に一度だけ管理画面から「投稿の再カウント」を実行する方が良いでしょう。）
てがろぐCGIを複数個設置しているときに、それぞれを区別しやすくする方法を2つ用意しています。
管理画面の配色(カラーテーマ)を切り替える機能があります。 複数のてがろぐCGIを併用する際に、どれを使っているのか迷わないよう色分けする用途にもご活用頂けます。 あくまでも管理画面のUI配色を選択するだけであって、ページの表示（スキン）には一切影響しません。
Ver 3.5.0以降では、下記の7テーマから選択できます。（Ver 2.7.0～3.4.0では、最初の4テーマのみから選択できます。）
ここで設定したカラーテーマは、ログアウト状態でも適用されます。（WordPressのようにログインユーザごとに適用されるわけではなく、ログインしているかどうかに関係なく全員共通の配色として表示されます。）
ブラウザのタブ（タイトルバー）で識別できるように、タイトル先頭に任意の識別名を挿入する機能もあります。 ここで指定した識別名は、管理画面では常時左上に表示されるほか、ブラウザのタイトルバー先頭にも（管理画面が表示されている状況では）常時表示されます。 あくまでも管理画面で「そのてがろぐの用途」を識別しやすくするための機能であって、ページの表示（スキン）には一切影響しません。
設定場所は、管理画面の［設定］→［システム設定］→【管理画面内の表示】→『管理画面のタイトル先頭に挿入される識別名』項目です。
同一ブラウザの複数のタブで、別々のてがろぐCGIを同時に使っている場合に、それぞれを区別しやすくするためのニッチな機能です。^^;
もし必要があれば、tegalog.cgi の中身をテキストエディタで読み込んで、下記の通りに書き換えられます。
※fumycts.pl側には書き換える項目はありません。
※デフォルトの状態で使用するのであれば、（1行目以外は）まったく書き換えなくても動きます。
▼Perlの位置
▼基本設定
▼オプション設定
▼その他
特に必要がなければ、何も変更せずにお使い頂くことをお勧め致します。上記以外の各種設定は、ブラウザ上で管理画面から変更できます。
