アクセス解析ツール「Mogura」を導入
アクセス解析ツール「Mogura」を導入してみました。
http://fmono.sub.jp/v_mogura/dl.phpからファイルをダウンロード・解凍し、設定ファイル編集後、設定ファイルで通したパスにファイル一式をアップロード。
後はセットアップファイルにアクセスするだけです。
詳しくは「Mogura」サイトの[使用方法]を参照してください。
プラグインの追加やカスタマイズも手軽にできそうで、結構満足しています。
現在、公開されているプラグインを4つ見つけました。
1 地域判別プラグイン
2 ホスト別集計プラグイン
3 月別アクセス解析プラグイン
4 月推移アクセス解析プラグイン
プラグインの追加方法はいたって簡単。
サイトからダウンロードしてきたファイルを解凍し、解凍後のPHPファイルをMoguraの plugin フォルダにアップロードします。。
次にMoguraの解析画面のサイドメニューの[コントロールパネル]から[アクション設定]→[メニューリスト]と開き、リストにアクションを追加登録します。
例えば、「地域判別プラグイン」を登録する場合は、
area||地域
を任意の場所に追加し、[更新]ボタンをクリックするだけです。
areaは先ほどアップロードしたPHPファイル名、二本のバーティカルバーは区切り、地域は任意につけた名称です。
グループ項目を追加する場合は、
[地域判別]
のように、半角ブラケットで囲みます。挟まれた文字列が項目として画面表示されます。
この話を友人と話していた際の話題です。
彼もセットアップしたそうですが、解析結果に文字化けが出るので、使用を止めたそうです。
これは、本体プログラムに問題があるのではなく、セットアッパーのテーブル生成SQLとサイトの文字コードが一致していないことに原因があります。
サーバの設定環境にもよりますが、テーブルの文字コードをCMSで採用した文字コードに強制的に合わせてることで対処します。
具体的には、「Mogura」のルートディレクトリにある「setup.php」をエディタで開き、TYPE=MyISAM の後ろに DEFAULT CHARACTER SET を追加設定してあげます。
例えば、「ログ保存テーブル」にujis(EUC)を設定する場合は次のようになります。
$t = constant("DB_COUNTER");
$sql["con"] = <<
CREATE TABLE IF NOT EXISTS {$t} (
counter_date date NOT NULL default '0000-00-00',
counter_val int(11) NOT NULL default '0'
) TYPE=MyISAM DEFAULT CHARACTER SET ujis;
SQL_STR;
この作業でうまく動作しない場合は、サーバ環境・設定を調べる必要があります。
すでに「Mogura」を使用し、同様の現象が出ている方は、テーブルを変換する必要がありますが、それでうまく動作するかは検証していません。
すでに取得したログから必要なものだけをローカル保存し、再セットアップした方が容易かもしれません。
このツールは、プログラムとHTMLが完全に分離していないため、見通しが多少悪いのですが、プログラムの構成は理解し易く感じました。
個人的には、完成された商品よりも、モジュールに容易に触れることのできるツールのバグを追いかけたり、カスタマイズしているのが大好きです。
ちょうどビニールのプチプチをつぶすのと同じです。達成感がたまりません。
でも本物のビニールのプチプチはイライラします。なぜでしょうか。
CMS MODxの覚書
検証を兼ねて、自社サイトをCMS MODxで構築することにしました。
将来的にはTYPO3や、Zend Frameworkや、CodeIgniterに変更するかも知れません。またこのブログも、いつWordPressや、NucleusCMSなどに変更するかわかりませんが、今のところ必要な機能をMODxで実現しようと思っていますので、しばらくはこのまま運用する予定です。
MODxバージョンは、0.9.6.1p2 です。
ブログの第1回目は、サイト構築にあたってのMODxの覚書です。
【文字化け対策】
●public_html/manager/index.php の 143行目に追加
mysql_query("SET NAMES utf8;");
●public_html/manager/includes/extenders/dbapi.mysql.class.inc.php の 97行目に追加
mysql_query("SET NAMES utf8;");
●public_html/index.php の 2行目に追加
mb_internal_encoding("UTF-8");
【Ditto修正】
●[リソース]→[リソース管理]→[スニペット]→[Ditto]の51行目を編集
$language = (isset($language))? $language : "english";
↓
$language = (isset($language))? $language : "japanese-utf8";
●/assets/snippets/ditto/classes/ditto.class.inc.phpの925~927行目をコメントアウト
if ($modx->config["modx_charset"] == "UTF-8") {
$dt = utf8_encode($dt);
}
上記修正後も Ditto の日付の文字化けが直りませんでした。
また、splitter がないと正常に Ditto が動きませんでした。
しばらくは、Ditto と格闘することになりそうですが、暇に任せての作業ですので、サイトの完成を含めていつになるのでしょうか。
その後utf8用の言語ファイルのロケール設定を修正してみました。
対象ファイルは次の7つ
/manager/includes/lang/japanese-utf8.inc.php
/assets/modules/docmanager/lang/japanese-utf8.inc.php
/assets/modules/quick_edit/lang/japanese-utf8.inc.php
/assets/snippets/ajaxSearch/lang/japanese-utf8.inc.php
/assets/snippets/AjaxSearch_OLD/lang/japanese-utf8.inc.php
/assets/snippets/ditto/lang/japanese-utf8.inc.php
/assets/snippets/eform/lang/japanese-utf8.inc.php
具体的には
setlocale (LC_ALL, 'ja_JP'); を
setlocale( LC_ALL, "ja_JP.UTF-8"); に変更
日付は正常に表示されるようになったようです。
またまたその後、Ditto 2.0.2にXSS脆弱性が確認されているらしいので、最新Stableバージョン(2008年06月20日時点で2.1.0)にアップデート。
アップデートは終わったものの、当初から問題になっているパラメータ設定が解決できていません。詳しいドキュメントが http://ditto.modxcms.com/ に掲載されていますので、これを参考に取り組むことにします。
アップデートで新たな問題が発生。
Jotのスニペットコールでソースが表示されています。またページネーション用プレイスホルダがうまく動いていません。
どんどん深みにはまっていくようです。
Jotの件はDittoコールをブラケット+エクスクラメーションではなく、二重ブラケットで呼び出すと直りました。
またまたまた、その後1年ほど経過し、MODxのサイトもいくつか立ち上げさせていただき、かなり理解が深まりました。
またMODxのバージョンも上がり、それに伴ってプラグイン・スニペットもアップデートされ、ここに書かれた問題はすべて解決しています。