サポートBBS

「configs/db.ini」の設定が間違っていれば管理画面が表示されずにエラーが表示されます。なのでDBへの接続は出来てるような気がします。DBの文字コード設定は「UTF-8」（ユニコード）になってますか？

res | 2010/09/04 Sat 20:12:13 [2261]

文字コードは関係ないと思います。

まずデータはちゃんと取れてますか？　データがまったくない状態だと必要なファイルが生成されず、JavaScriptのエラーになります。

「logs」ディレクトリのパーミッションは「707」もしくは「777」に変更されてますか？　変更されてないと必要なファイルが生成されません。

「setup.php」で表示される HTMLタグ設定 共通（必須）というのをちゃんと書いてますか？　これを先に書いてから各数値の出力タグを書かないとJavaScriptのエラーになります。

res | 2010/08/30 Mon 22:41:05 [2258]

がんばってやってみたけどだめでした。
あきらめます。
ありがとうございました。

url | res | 2010/09/01 Wed 03:29:30 [2259]

すみません、自己レスです。
あれから色々調べており、自己解決してしまいました。
htaccessが邪魔していたようなので、同ファイルを削除したところ、まともに動き始めたようです。

大変失礼しました。

url | res | 2010/08/13 Fri 15:33:50 [2256]

Lapisの「PHPから直接呼び出す方法」は「ページタイトルを取得できないケースがある」という問題をかかえているため、お勧め出来ません。普通に「JavaScriptを使う方法」にした法が無難です。

記述場所はテンプレートのHTMLファイルです。具体的なファイルパスは分かりませんが、管理画面からいじれると思います。言ってる意味が分からない場合は設置を諦めるかもうちょっと勉強することをお勧めします。

res | 2010/08/10 Tue 20:38:42 [2252]

早々のご回答有難うございました。

管理画面にて編集できる場所は無いか探してみたところ、無事に見つける事が出来、タグを挿入する事が出来ました。

ただ気になったのが、タグを挿入したのは本日8月11日の16時なのに、本日の解析を見ると、本日の午前6時や7時にアクセスしているらしき形跡が見受けられました。
いずれも自分のPCからアクセスしているらしき内容なのですが、その時間帯に私自身がアクセスした記憶がありません。

私のタグの挿入の仕方が間違っているのでしょうか…？

恐れ入ります。お手隙の時にご回答をお願いいたします。

res | 2010/08/11 Wed 16:15:44 [2253]

全体的に時間がずれている場合はサーバーが海外にあると思われます。「configs/conf.ini」の13行目を以下に書き換えて上書きアップして下さい。（以前のデータが変更されるわけではありません）

gm_date = 9

時間がずれてなく、たまたま変な時間に変なアクセスがあった場合は気にしないで下さい。データが取れている時点で基本的にちゃんと動いていると思って頂いて構いません。世の中常識では考えられない、科学では説明出来ない出来事が往々にしてあるものです。

res | 2010/08/12 Thu 20:34:30 [2254]

特に設定する必要はありません。ページを読み込んだ時点で「ファイルへのリンク」に「クリックしたらページを移動する前にデータを送信する」というイベントを自動的にセットするようになってます。

res | 2010/07/27 Tue 20:16:23 [2250]

透明ＧＩＦになっているからでしょうか？？

res | 2010/07/12 Mon 07:31:48 [2247]

とりあえず「トラフィックエクスチェンジ」とやらがどんなものなのか知りません。「アクセスログが取れてない」というのは2種類の意味があるんですがどっちですかね？

1.アクセス自体が記録されない

JavaScript & noscript が動作しない環境からのアクセスになる？　→ write.phpをincludeする方法に切り替える（PHPページのみ）


2.リファラが記録されないので他のアクセスにまぎれてしまう

→ そのサービス＆ブラウザ＆メーラーの仕様なのでそういうものだと納得するか、URLのクエリに専用の文字列を入れて判別させる。

res | 2010/07/12 Mon 21:03:57 [2248]

http://act.st/etc/env_check.php

上記のページにアクセスしてみて、「MSIE 8.0」と表示されるか確認してみて下さい。

＞/logsにログが保存されないです。

「logs」ディレクトリのパーミッションは「707」に変更されてますか？　まぁ殆どのデータはDBに保存されるのでそんなに重要じゃないんですけどね。「logs」に保存されるのはカウンター用のJavaScriptファイルとPHPの実行エラーログぐらいです。

追記：ってあーWindowsサーバーですか？　アクセス権の制御方法は自分はちょっと知らないのでお役に立てないかもしれません。当サイトのスクリプトは「UNIXサーバー」向けですので。

res | 2010/06/14 Mon 13:58:00 [2238]

>「MSIE 8.0」と表示されるか確認してみて下さい。

アクセスしてみたところ、「MSIE 8.0」と表示されました。
やはり詳細ログには「IE 7.0」と表示されてしまいます。

>「logs」に保存されるのはカウンター用のJavaScriptファイルとPHPの実行エラーログぐらいです。

カウンターのログと、PHPのエラーログは保存されているようです。
アクセスログもこのディレクトリに保存されると思っていました。(^^;

res | 2010/06/14 Mon 18:56:01 [2239]

同じIPアドレスで別のPC（IE7）から最初にアクセスしていた、ということはないですか？　「configs/conf.ini」の初期設定では「UAが違っていても同じアクセスと判定する」という設定になってます。その場合最初にアクセスしたUA情報が保持されます。

そうでないなら下記のページにアクセスして表示された情報をそのままコピペしてここに書いてもらえますか？

http://act.st/test1.php

res | 2010/06/18 Fri 08:46:56 [2240]

IE 8.0
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

やはり詳細ログには「IE 7.0」と表示され変わりないです。

res | 2010/06/20 Sun 11:28:13 [2241]

二連続でこういうことを言いたくはないのですが、「さっぱり原因が分からない」です。原理的にはありえません。なぜかと言うと試してもらったプログラムは「Lapis」のUA判定と「まったく同じもの」だからです。

とりあえず意味がないと思いますが「configs/conf.ini」の28行目を以下にして様子をみて下さい。すいませんです。

ua_check = 1

res | 2010/06/20 Sun 22:05:07 [2242]

　　　 .┌┐
　　　／ /
　.／　/ i
　|　( ﾟДﾟ)
　|（ﾉi　　|）
　|　 i　　i
　＼_ヽ＿,ゝ
　　 U" U

そうですか、原因不明ですか…。

外部からのアクセスでも同様の症状がでるか試したいので、
http://like-on-time.ddo.jp/test.htm にアクセス
してもらえないでしょうか？
もし、解析結果がIE8を使用しているのにIE7と表示される場合は、利用を検討してみます。

お手数をおかけしますがよろしくお願いします。

res | 2010/06/23 Wed 01:39:00 [2243]

IE8でアクセスしてみました。どうでしょう。ちなみにWindows7です。

res | 2010/06/23 Wed 10:49:25 [2244]

　　 ||　　　　　⊂⊃ 
　　 ||　　　　∧　∧ 
　　 ||　　　 （　 ⌒ ヽ 
　∧||∧　　　∪　　ﾉ 
（　 ⌒ ヽ　彡　　Ｖ 
　∪　　ﾉ　　ﾌﾜｰﾘ 
　　∪∪ 
　　　：
 ‐ニ三ニ‐

アクセスありがとうございました。
外部からの接続では問題なく、きちんと「IE8」と表示されました。
原因はこちらのPCにあるみたいです。
しかし、なにが原因なのかわかりません(^^;
ちなみにサーバーを、「Apache」にしてみたり「PHP」を再インストールしてみたりしましたが、「IE7」と表示されるのは変わりなかったです。

プログラム自体には問題ないので利用させていただきます。
ただし、私のPCからのアクセスは「IE7」なりますけど…w

res | 2010/06/24 Thu 20:18:53 [2245]

まず「猫でもわかる設置方法」は『Lapis 4.2.0』を対象としている相当古い情報です。なのでこれを当てにしてはいけません。「readme.txt」と「setup.php」のみ参考にして下さい。

「a.js」は既に廃止して存在していません。またタグの記述も昔は3箇所だったのが2箇所で済むように改良されています。いい加減ページを更新しなきゃいけませんね。まぁ気が向いたらやりますｗ

エラーは「lapis」から見て「mint」が存在しない（見つからない）というメッセージです。「lapis」と「mint」を同一ディレクトリにアップロードしていますか？　「lapis」と「mint」というディレクトリ名を変更してたりしませんか？　パーミッション（アクセス権）を変な感じに設定してたりしませんか？

res | 2010/05/18 Tue 20:15:48 [2227]

　　　　　　　　il||li　　
　　　　　 ∧∧　 　　　
　　　　　/⌒ヽ)　　
..,,....～（,＿,,,）.....,,,,....

　ご回答ありがとうございます。1つ目・2つ目の疑問が解決して安心しました。

　3つ目ですが、ディレクトリ構成としては、
　　abc/lapis
　　abc/mint
というように、同じフォルダの中に置いているので、恐らく問題ないと思います。
　また、abc/lapis/logsのlogsのフォルダのみですが、パーミッションは707や777にしてみたのですが、相変わらず上記のエラーが発生します。

　db.iniの記述が間違ってるのかもしれないと思い、既に別のデータベースを入れてるので、そちらと比較してみたりしてますが、どうしても解決する様子がありません。

　大変申し訳ないのですが、可能であればこちらの解決手段を、再度こちらで質問させていただいてよろしいでしょうか。

　よろしくお願いいたします。

res | 2010/05/19 Wed 00:44:32 [2228]

一旦全部削除してもう一度最初から設置しなおしてみて下さい。ちょっと現時点では何が原因なのかわからないです。あ、「.htaccess」は使わないで試してもらえますか？

res | 2010/05/21 Fri 08:35:18 [2229]

　　 ∧,,∧　
　　ミ,,ﾟДﾟ彡　
　　(ﾐ 　　ﾐつ　
　　 ﾐ 　　ﾐ　
　　 ∪ ∪　

　返信ありがとうございます。
　何度か全削除→lapis入れなおしで試してみたり、.htaccess(と、index.htaccess)を削除してみたのですが、同じ結果でした。

　また、「abc/lapis」より外のディレクトリにも「.htaccess」を置いていたので、試しにこちらも削除してlapis/index.phpを再度実行してみたところ、上記のエラーメッセージに、それまでなかったと思われる
「Fatal error: Class 'Controller' not found in /virtual/アカウント/public_html/hoge.jp/abc/lapis/index.php on line 37」というようなエラーメッセージが追加されたようです。

　試しに、その「abc/lapis」の外にある「.htaccess」を再度アップロードし直してみたところ、そのメッセージが消えなかったため、確実になかったかはわかりませんが、なかったように思います。

　「.htaccessを使用しない」というのが、削除するという意味でないのでしたら、勘違いすみません。

res | 2010/05/24 Mon 01:35:57 [2230]

なんとなーく原因が分かってきました。以下意味が分からなければスルーして下さい。ひょっとしてPHP本体が「セーフモード」で動作してるか、それに近い制限を付けて動かしてる可能性がありますね。ようするに「上位ディレクトリにアクセス出来ない」という制限です。

最終手段として「mint」を「同一ディレクトリ」ではなく、「lapis/mint」となるように「lapis」ディレクトリ内に設置して下さい。

そして「lapis/index.php」の34行目

include_once('../mint/modules/core/controller.php');

という部分を以下に変更して上書きアップしてみて下さい。

include_once('mint/modules/core/controller.php');

res | 2010/05/24 Mon 19:26:03 [2231]

　　　 ∧,,∧　
　　　ミﾟДﾟ彡　
　　⊂ﾐＵ,,Ｕﾐ⊃　

　度々の質問すみません。

　今回いただいたやり方(abc/lapis/.htaccess等を削除・abcの上にある.htaccessは削除しない・abc/lapis/mintにする・「lapis/index.php」の34行目変更)でやってみたところ、↑↑にて相談させていただいた4番目のエラーが消えました。

　ところが、相変わらず最初の3つのエラーは(事実上)同じものが表示されています。具体的には(../mint/modules/core/controller.php) という表記が(mint/modules/core/controller.php)に変わった程度です。

>ひょっとしてPHP本体が「セーフモード」で動作してるか
とあったので、調べてみたところ、サーバーやPHP等に関して知識がないため、見当違いかもしれませんが、借りてるサーバーがXREAのため、セーフモードで作動しているものと思われます。


　度々の質問申し訳ありませんが、宜しければ再度原因を質問させてください。宜しくお願い致します。　

res | 2010/05/25 Tue 00:57:59 [2232]

「lapis/.htaccess」の1行目に以下の記述を入れて上書きアップして下さい。

AddHandler application/x-httpd-phpcgi .php

あと忘れてましたが「lapis/write.php」の52行目も

「../mint/」から「mint/」に変更して下さい。

ちなみに自分が持ってるXREAのアカウントで試してみましたが現象を確認出来ませんでした。（s292.xrea.com）セーフモードのサーバーとそうじゃないサーバーが混在してるんですかね、XREAは。

res | 2010/05/25 Tue 20:39:06 [2233]

　　 ||　　　　　⊂⊃ 
　　 ||　　　　∧　∧ 
　　 ||　　　 （　 ⌒ ヽ 
　∧||∧　　　∪　　ﾉ 
（　 ⌒ ヽ　彡　　Ｖ 
　∪　　ﾉ　　ﾌﾜｰﾘ 
　　∪∪ 
　　　：
 ‐ニ三ニ‐

　毎回素早いご回答、ありがとうございます。というか、質問ばかりで申し訳ありません。

　XREAのサーバーのセーフモード云々は、当方の無知で見当違いの事を書いてしまった可能性があります。
　こちらのアカウントはs302.xrea.comなので、仕様はほぼ同じなのかなあと思っています。
　サーバーのソフトウェア情報の項目を見る限り「MySQL」の項目以外同じに見えるので…。

　今回いただいたアドバイスで、さらに質問させていただきたいのですが、「lapis/.htaccess」の一行目に書くのでしょうか?それとも「lapis/index.htaccess」の一行目に書き加えて、「.htaccess」という名前で上書き保存するのでしょうか。
　一応両方試してみましたが、どちらの方法でもエラーメッセージが以下のようになりました。

Warning: Front::include_once(mint/modules/core/controller.php) [function.Front-include-once]: failed to open stream: No such file or directory in /virtual/アカウント名/public_html/hoge.jp/abc/lapis/index.php on line 34

Warning: Front::include_once() [function.include]: Failed opening 'mint/modules/core/controller.php' for inclusion (include_path='.:/usr/local/lib/php') in /virtual/アカウント名/public_html/hoge.jp/abc/lapis/index.php on line 34

Fatal error: Class 'Controller' not found in /virtual/アカウント名/public_html/hoge.jp/abc/lapis/index.php on line 37

　さらに、独断でindex.phpとwrite.phpの28行目「define('fw_dir','../mint');」とdefine('fw_dir','..mint');を「'../mint'」から「'mint'」にして試してみたりもしたのですが、特に変化は見られませんでした。

　何度も質問してしまい、申し訳ないのですが、再度解決方法を質問させていただきたいです。

　よろしくお願いします。

res | 2010/05/25 Tue 21:58:48 [2234]

すいませんちょっと現時点では解決方法はさっぱり分かりません。そのサーバー固有の問題のような気がしないでもないです。くやしいですがお手上げです orz

res | 2010/05/27 Thu 20:08:00 [2235]

　　　∧∧　　ミ　＿　ドスッ
　　 (　 　,,)┌─┴┴─┐
　　/　　　つ.　 終　 了 │
～′　/´　└─┬┬─┘
　∪ ∪　　　 　 ││　_ε３

何度もお手数かけてしまい、申し訳ありません。
サーバーを変えてみるか、諦めるかします。

本当にありがとうございました。

res | 2010/05/27 Thu 23:20:42 [2236]

＞左と右のアクセス数の意味って何なのでしょうか？

左がユニークアクセス数で右がページビュー（PV）です。ユニークは閲覧人数、PVは閲覧ページ数です。

アクセスエラーは基本的に「404 Not Found」の情報です。つまりリクエストされたのにファイルが存在しなかったという意味です。ファイルが二行（下がリンクになっている）の時は下のファイルから上のファイルを呼び出しているという感じです。

一行の時はブラウザなりロボットなりが直接呼び出しています（不正なアクセス？）。

res | 2010/04/24 Sat 14:47:51 [2222]

ありがとうございます。
アクセスエラーの原因は分かり、
修正して直ったのですが、
詳細ログのアクセスルートのリンクにマウスを合わせると
404 NOT FOUNT 04:20
と表示されてしまいます。

04:20とは何のことでしょうか。分・秒ですか？

また、まだ問題ありということでしょうか。

res | 2010/04/24 Sat 23:58:50 [2223]

＞04:20とは何のことでしょうか。分・秒ですか？

そのページの滞在時間（分・秒）です。404の時は気にしないで下さい。

res | 2010/04/25 Sun 12:45:32 [2224]

現在の仕様ではSQLiteの場合、データを削除しても実際に容量が減るのは次の日です。（日付が変わったタイミング）ここらへんは改善の余地ありですね。容量を減らす処理（データ整理）はとても時間がかかる処理ですので、それだけデータ量があると途中で終わってしまう可能性があります。

日付が変わってもデータ量に変化がなければ以下を試してみて下さい。

まず、FTPソフトで「logs/sqlite.db」を丸ごとダウンロードしてバックアップを取って下さい。で、「ログ管理」から残したいデータのリンクをクリックして個別にダウンロードして下さい（.csvファイルになります）。

次にFTPソフトで「logs/」にある全てのファイルを削除した上で、先ほどの「.csvファイル」をアップロードして下さい。

もう一度「ログ管理」を開いてリロードした上で「ログの読み込み」を実行して下さい（チェックボックスにチェックを入れて）。

res | 2010/04/05 Mon 08:38:05 [2216]

お忙しい中、こんなに早速のお返事ありがとうございます！！

そういうことだったのですか・・・。どうりでlogsフォルダの容量が全く変化がなかった訳です。
まずは日付が変わるのを待ってみます。
ご指示いただいた対応で何とかなると思います。

フリーのCGIでこんなに手厚いサポート、本当に感謝の気持ちでいっぱいです。ありがとうございました。

res | 2010/04/05 Mon 09:43:26 [2217]

昨日、日付変更線を超えて処理された結果を確認しましたところ、やはり管理人様が予言されていたとおり、サイズが大きすぎたせいか処理に失敗しておりました。
ファイルサイズに変化がありませんでしたので、「次の手」としてご指南いただいた方法で解決しました。

まずは結果のご報告まで。
いろいろとありがとうございました。

res | 2010/04/07 Wed 14:46:26 [2218]

　　　｡∧,,∧｡ﾟ　
　 ﾟ ミ;´Д｀ミっﾟ　
　　 ﾐつ 　 ﾐ　　　
　　　ﾐ　 （⌒）　
　　　 し⌒＾　

いつもお世話になっております。

前回、ログの削除に失敗していたので、logsフォルダ内を全て強制削除した上でcsvファイルからリロードして最近の必要なログのみを復旧させ、直った～！と喜んでいたのですが、実はその直後にエラーを起こして解析が動いていなかったことが判明しました。orz

logs/sqlite.dbを丸ごとバックアップするように指示を受けておりましたが、csvを戻すときにこのファイルもアップロードし、属性を変更していなかったのが原因でしょうか？
error.logを確認してみたところ、動かなくなったタイミングと同じ時刻（つまり、上記作業を行った直後）に、/lapis/actions/view/log_manage.php on line 415で無効な引数がforeach()に返されたという内容になっておりました。

それとも、一度サーバーの契約容量オーバーで何かのファイルが正常に更新できず、どこかが壊れてしまったのでしょうか？（丸ごと設置し直しが必要？）

何度もすいませんが、ご教示いただけたら幸いです。

res | 2010/04/24 Sat 06:20:25 [2220]

ちょっと説明が足りませんでしたね。すいません。正確に言うと「logsフォルダ内のファイルを削除した後、次のアクセスがあるとsqlite.dbが自動で生成されるのでそれにcsvファイルからインポートして欲しい」という感じです。

お察しの通り「sqlite.db」のパーミッションが原因だと思います。自動で生成される場合は「606」になりますが、手動でアップロードすると「644」になるので「606」に変更する必要があります。

res | 2010/04/24 Sat 14:34:39 [2221]

　　　∧∧　　ミ　＿　ドスッ
　　 (　 　,,)┌─┴┴─┐
　　/　　　つ.　 終　 了 │
～′　/´　└─┬┬─┘
　∪ ∪　　　 　 ││　_ε３

またもや迅速な回答ありがとうございました。

今度こそ、本当に直りました。(^_^;
無事、動いております。

たいへんお世話になりました。

res | 2010/04/26 Mon 00:35:22 [2225]