ログインにはPHPの「セッション（session）」機能を使用しています。
設置サーバーでPHPの「セッション（session）」機能が有効で無い場合、本プログラムは使用不可になります。
ただ、一般的なレンタルサーバーであればまず問題とはなりません。

よくあるミスとしてはファイルをBOM有りで保存してしまったというのがあります。
BOM有りで保存してしまうとセッションが維持できずページを移動するとログイン画面が表示されます。

Windows標準のメモ帳で開いて保存するとBOM有りとなりますのでメモ帳はPHPファイルでは絶対に使用してはいけません。
TeraPadなどのエディタソフトを使用して下さい。またTeraPadの場合は「UTF-8N」で保存して下さい。
BOMについては以下ページをご参照下さい。
https://www.php-factory.net/trivia/03.php

ログインにはPHPのセッションというものを使用しています。このセッションは定期的に削除されるようになってます。
セッションの性質としてデフォルトではログイン後、ページ遷移せずに24分が経過した場合、100分の1の確率でセッションファイルが削除されます。
※セッションファイルが増えすぎないようにするための仕様です。

要するにログイン後そのまま放置して24分以上経ってから他のページに移動しようとするとログイン画面が表示されてしまう場合があるということになります。

ただ、実際に24分以上も放置することは少ないと思いますし、 また確率的に削除されることは非常に稀です。 ですので、頻繁に発生する場合は少なくともこの仕様が影響しているとは考えづらいです。

その他考えられる原因としては セッションファイルの保存先のディレクトリが 他のシステムでも使われていて、 それの影響で削除されてしまっているのかもしれません。
それを回避する方法を以下に記載しますので、お試しいただければと思います。

1，セッションの有効期限を延長して、セッションファイルの保存用ディレクトリを指定する
設定ファイル（config.php）の一番下の方にでも以下2行をコピペして追加して下さい。

ini_set( 'session.gc_maxlifetime', 14400 ); // 秒(デフォルト:1440)
session_save_path( dirname(__FILE__) .'/../session' );

これでセッションの有効期限が240分となります。
また、セッションファイルの保存先がadmin/session/になります。

2，セッションファイル保存用ディレクトリを用意する
admin/内にsessionという空のディレクトリ（フォルダ）を1つ作って下さい。
次にadmin/include/内にある.htaccessファイルをコピーして
作成したsession/ディレクトリ内に入れて下さい。
※セッションファイルにアクセス出来ないようにするためです。（必ず実施して下さい）

以上。

これで一度管理画面からログアウトしてログインしてみて下さい。
ログイン出来て、またadmin/session/内にセッション用のファイル（ランダム文字のファイル名です）が生成されていればOKです。

これでしばらく様子を見てみて下さい。

まず、サーバー上のuploadフォルダを開いて見て下さい。そこでFTPソフトの「更新」を押してみて、デフォルトでindx.htmlがありますが、それ以外に.jpgなどの画像ファイルがあるかどうか確認下さい。

ある場合には単純に表示側のimgタグのパスが間違っていることが考えられます。設置によって階層構造を変えている場合に発生しやすいです。できれば配布している階層そのままで設置してみて下さい。

そこに画像ファイルが無い場合は画像がアップされていないということです。考えられることはuploadフォルダのパーミッションが間違っている（基本的にはその場合管理画面で警告が出ます）、または、サーバーのphp.iniの設定でアップロードファイルの容量制限に引っかかっている、GDライブラリがインストールされていないなどが考えられます。プログラム側で5MBに設定しても、サーバー側の設定が2MBの場合はサーバー側の設定が優先されます。特にさくらサーバーのデフォルトは2MBだったと思います。

サーバーの容量制限については以下ページで解説してますのでご確認、必要に応じて設定変更してください。
サーバーのphp.iniによるアップロードファイルの最大容量の確認と容量制限の変更

PHPのGDライブラリですが、これはPHP4.3以降標準でインストールされていますので、ほとんどのサーバーでは問題無いはずです。
ただ、サーバーによっては、デフォルトで「Off」になっている可能性もあります。

以下ページを参考に現在のphp.iniの設定を表示させ、
サーバーのphp.iniの設定確認方法
「gd」でページ内を検索してみてください。「GD Support」などがあれば動いていることになります。
逆に「gd」自体見つからない場合には「有効」にする必要があります。

php.iniの設定で
;extension=php_gd2.dll 部分の先頭のセミコロンを削除してapacheを再起動すればOKです。
php.iniの設定、変更手順などはサーバーによって違います。詳しくはマニュアル、または無いような意地悪なサーバーなら直接サーバーに問い合わせてみて下さい。
「GD」を有効にしたいのですが・・・と質問すれば回答してくれるかと思います。

バックアップ機能をオンにしていれば（デフォルトはOFF）、data/backup/内に保存されているバックアップファイルで復旧が可能です。このファイルはdata/data.datを単純にコピーしたものです。

ファイル名はバックアップ時の「年月日時分秒」となっています。
「例　backup20131002024103_data.dat（この場合2013年10月2日2時41分3秒ということ」
これをリネームしdata/data.datを上書きすればOKです。その場合、念のためパーミッションを確認下さい。666等書き込み可能である必要があります。ただし、バックアップは新規投稿時のみ作成されます。もし新規投稿後にクライアント等が「編集」、「削除」などを行っていると、その変更内容は反映されていませんので先祖返り（デグる）する可能性があります。必要に応じてクライアントに説明、確認等を行うのが良いかもしれません。

バックアップを行っていなかった場合には申し訳ありませんがデータの復旧は不可能となります。
念のためサーバー会社に問い合わせてみてもいいかもしれません。バックアップを取っている可能性があるかもしれません。

サーバー障害によるデータ全損失の場合には復旧は不可となります。
この場合も念のためサーバー会社にお問い合わせください。
可能であれば念のため定期的にデータファイルをダウンロードされることをおすすめします。

結論から申しますとぷららホームページサーバーでは動作しません。以下のようなエラーが出るはずです。Fatal error: Call to undefined function mb_convert_encoding() in ○○○
これは「mb_convert_encoding」関数がないよーというエラーで、
及び
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings.
も出ます。これはタイムゾーンが設定されてませんよーのエラーになります。タイムゾーンは解決可能ですが、上記mb_convert_encoding関数はどうしようもありません。そのため、ぷららでは使用不可です。ぷららにも問い合わせましたが、正式に回答をいただいてますのでご参考まで

--------------------------------------------------------
恐れながら、弊社ユーザーCGIサーバーは「mb_convert_encoding」の関数に対応をしておりません。
また、現時点で今後対応の予定はございません。
ご要望に沿えず申し訳ございませんが、ご利用可能な範囲にてユーザー
CGIをご利用くださいますよう、お願い申し上げます。
--------------------------------------------------------

mb_convert_encoding関数は文字コードを変換する関数ですが、メールフォームにかぎらずPHPプログラムでは非常に良く使われるメジャーな関数です。
Yahoo、ぷららに限らずプロバイダ系全般に言えますが、制限や特別な設定が必要だったりとトラブルが非常に多いです。
本職では無いのでしょうがない部分もありますが、プロバイダ系は基本的には動作しないものとお考えください。
なのでホームページサーバーとしては極力使うべきではありません。（と断言できます（笑）もう、ちょっと怒ってますｗ）
たくさんの不具合報告をいただいています。

管理画面で登録ボタンを押すとエラー表示される場合があります。これは主にロリポップ系、CPIなどに導入されている「WAF機能」による可能性が高いです。以下ページを参考にこの機能をOFFにしてみてください。
ロリポップの新機能「WAF機能」をOFFにする

以下ページに掲載されているサーバーの場合にはそのままでは問題があります。内容は若干異なりますが、対応方法はおなじになりますので、ご参考の上でご対応下さい。
https://www.php-factory.net/cms/detail.php?id=6

このプログラムは画像アップ時に設定ファイルで設定したサイズに自動で縮小されますが、この処理は比較的大きなメモリを消費します。
要するにサーバーのPCスペックに依存する部分になります。
（経験上、安い（PCスペックが低い）サーバーの場合に発生する可能性が高い問題であり、エックスサーバーなど中程度以上のサーバーであれば基本的には発生しません）

解決策としては、以下3パターンがあります

1，メモリの上限を上げる
これができるかどうかは微妙ですが、 PHPの設定で一応上げることができます。 ※ただし、経験上この設定は無視される可能性があります。 （サーバー側が許可していない、またはそもそもPCのスペックが低いなど） 以下ページに変更方法を記載しておりますのでご参考下さい。
http://www.php-factory.net/trivia/05.php

2，縮小サイズを大きく設定する
デフォルトでは600pxに設定していますが、 これをたとえば1000pxなどでお試しいただく。 縮小率が高いほどメモリを消費します。

例　2000px → 1000pxへの縮小よりも2000px → 600pxの縮小のほうがメモリを多く食う。

逆にこれで解決した場合には、 メモリが原因だったということになります。

ちなみにですが、このプログラムは設定ファイルで設定したサイズよりも大きい場合にのみ縮小処理が実施されますので、 たとえば設定サイズを適当に10000とか現実的にありえない値に設定しておけば縮小処理を無効化することが出来ます。場合によってはこれで回避するということも考えられます。が、表示側ページが重くて大変かもしれません。。。

3，事前に縮小する
この場合、根本的な解決とはなりませんが、 サーバー移転が難しい場合には、 また上記の設定でうまくいかない場合には、 残念ながらこれしか選択肢は無いと思います。

ちなみに画像の縮小には「縮小専用」というフリーソフトがオススメではあります。ドラッグ＆ドロップするだけで複数の画像ファイルを設定したサイズに一括（かつ一瞬）で縮小してくれます。
縮小するだけのことでわざわざPhotoshopなどを使うのは効率が悪いですからね。（クライアントが持っていない可能性も高いですし）

iPhoneで撮影した写真の場合、縦写真が横写真として保存されてしまう場合があり、 その対策として、画像を回転させる処理を実装していますが、 その処理部分でエラーが出てしまっています。

極稀にサーバーによっては実行に必要な関数が存在しないことがあり、 その場合にエラーとなってしまいますので、この処理を無効化することで対処可能です。

対象ファイル：admin/put.php
修正箇所：171行目付近の以下の箇所

//画像の回転（iPhoneの縦写真が横写真として保存されてしまう問題の対策）
if(function_exists('exif_read_data') && function_exists('imagerotate')){
    $exif_datas = exif_read_data($_FILES['data']['tmp_name']['upfile'][$key]);
    if(isset($exif_datas['Orientation'])){
          if($exif_datas['Orientation'] == 6){
             $image = imagerotate($image, 270, 0);
          }elseif($exif_datas['Orientation'] == 3){
             $image = imagerotate($image, 180, 0);
          }
    }
}

こちらをまるっと削除すればOKです。
またはすべての行の先頭にスラッシュ2つ「//」を入れるか、CSSと同じように/*と*/ですべてを囲んでコメントアウトしてもOKです。

以上です。

プログラムのバグなどによってデータが消えてしまうようなことはシステムの仕様上ありえないです。
これはプログラムの性質上、最も優先すべきものでもありますので必要十分な検証と致命的な不具合が絶対に起きないような設計を行なっています。

また配布してからこれまで相当な期間が経過しておりますが、 そういった報告は一度も届いておりません。
私自身も受託開発案件の仕様によってはこのプログラムをベースにすることが多いためヘビーユーザーでもあります。

それでも万が一そういった致命的な不具合が発生した場合でも対処できるようデータファイルの自動バックアップ機能も付けていますので万全を期しています。
※デフォルトはOFF。ONにすることを推奨します。設定ファイル（config.php）で簡単に設定できます。

ただ、それでも唯一発生することが考えられる状況があります。それは複数人で同時に管理画面で更新作業を行うようなケースです。
データの保存方法はテキストファイルでの保存形式を採用していますが、 ファイル書き込み処理がまったく同時に行われてしまうとデータ損失する可能性が理屈上は一応あります。（マイクロ秒単位で同時など）

これはファイルオープンとファイルロックの処理の間にはどうしても極々わずかな隙（タイムラグ）が出来てしまうためですが、 そのタイムラグは一瞬（マイクロ秒単位）ですので、発生する可能性は限りなく低いです。（100万分の1秒単位で同時に更新した場合などに限られる）
それでもできる限り特定の人間のみが更新したほうがより安全と言えます。（更新する人数が増えるほどリスクは高まる）

ちなみにですが、複数人で更新するリスクはこの他にもあります。（むしろこちらは普通に発生すると思います）
たとえば特定の記事を二人で同時に更新している場合をイメージすればわかりやすいと思います。
一人目が編集画面を開いて文字を修正しています。その間に二人目が同じく編集ページに入って文字を修正します。
この時点でピンと来るかと思いますが、この段階で一人目が保存ボタンで保存して、二人目が同じく保存ボタンを押して保存したとします。
この時点で一人目の作業は無かったことになってしまいます。
一人目は当然文字を修正したものと思っていますが、実際には変更されていません。
これはいわゆるデグリ（先祖返り）です。
こういったリスクもあるので、 管理画面での更新作業はできる限り一人が行うべきでもあります。

「ページ遷移エラー(トークン)」はCSRF対策のために実装しているセキュリティ上必要なワンタイムトークンが働いた場合に表示されるものですが、 以下のような条件でも表示されることがあります。
※ただ通常の操作では基本的には表示されることはありません。

表示される例としてはたとえば、
新規登録時であれば、
投稿内容の入力
→保存
→ブラウザの戻るボタン
→保存
のようなページ遷移で発生します。
投稿記事の再編集でも同じことが起きます。

または投稿画面を開いた状態で他のタブであらたに同じ投稿画面を開いた場合で、 初めに開いていたページで登録すると同じくページ遷移エラー(トークン)となります。

これは同じブラウザで同じページを2つ以上開いてしまうとトークン用のセッションが上書きされて書き換わってしまうためであり、正常な動作です。

またその他考えられることとしては、 セッションがタイムアウトした場合です。
たとえば投稿画面を開きっぱなしにして相当な時間が経過していると セッションがタイムアウトして切れてしまい、結果エラーとなる可能性もあります。
※PHPのセッションはデフォルトでは約24分でかつ100分の1の確率でセッションが切れます。（分母はsession_start()が呼ばれた数）
※これは確率的には相当低いため、発生することはまずないでしょう。

こういった理由から通常の操作で表示されることはまずありませんので、 たまたまそういった操作を行ったということだと思います。

2021/04/15追記
ブラウザがChromeの場合でかつ特定のプラグインを導入している場合に、この症状が出るという報告がありました。
プログラム側では対処不可能ですので、ブラウザを変えるかプラグインをOFFにしていただくしかありません。

もちろん対応しています。WPなどのようにややこしいことは一切ありませんので安心して下さい。
特に意識する必要すらありません。表示側、管理画面側ともSSLでそのまま問題なく表示できます。https経由でアクセスするだけです。
※非SSLのhttp通信による外部ファイルの参照などは一切行なっておりません。

また投稿記事内にアップした画像やPDFなどのファイルのパスはすべて相対パスとなっていますので、 非SSL環境からSSL環境に変わったとしてもまったく問題ありませんし、もしドメインが変わったとしても問題ありません。
（いずれも意識する必要すらありません）
※このあたりがWPとは大きく異なる部分でもあります。

尚、SSL自体の導入などはご自身にて対応下さい。（SSL自体はPHPとは直接関連がありません）

至って簡単です。WPのようにややこしいことは一切ありませんので安心して下さい。
すべてのファイルをダウンロードしてそのまま新サーバーにアップするだけです。
サーバーによっては稀にファイル保存ディレクトリやデータファイルのパーミッション変更が必要な場合もありますが、その場合には管理画面内に赤字で警告が出るようになっていますので、 管理画面にログインすることですぐに分かります。

何も警告が出ず、投稿なども問題なくできていれば引っ越しは完了です。
※警告が出た場合はそのメッセージのとおりにパーミッションを変更すればOKです。

また投稿記事内にアップした画像やPDFなどのファイルのパスはすべて相対パスとなっていますので、 非SSL環境からSSL環境に変わったとしてもまったく問題ありませんし、もしドメインが変わったとしても問題ありません。
（いずれも意識する必要すらありません）

ただし、PHP環境も変わりますので必ず事前に設置＆動作確認を実施して下さい。

登録年月日の西暦のプルダウンは2015年から翌年までの西暦が自動で反映されるようになっているため翌年以降も問題ありません。
（意識する必要はありません）

尚、スタートの西暦を2015年よりも後としたい場合は
include/admin_function.php
の以下の箇所を変更すればOKです。（ファイル内に1箇所しかありませんので検索すれば見つかります）
$start = 2015;