ブログ

なぜ表示フォントが違う？

2011-03-10T23:50:00+09:00

EUCからUTFへの移行テストをしてみて気がついた

表示されるフォントが違うのだ。
ゴシックで表示されていたのだが、明朝になっている。

どうして？
どうやら IE だけの問題のようだが...
IE + UTF-8 って変なことが結構起こる...

CSSに設定するしかないかなぁ....

XCL2.2 RC１が出た

2011-03-05T23:20:00+09:00

ついに RC まできた。
http://sourceforge.net/apps/phpbb/xoopscube/viewtopic.php?f=5&t=246

できればRC4 とかまで行かないで欲しいが...

そろそろ既存の環境を移行する準備をしなければ。

wizmobile [0.5X] は重いの？

2010-04-14T00:20:00+09:00

名前解決のせいですっかり手間取ってしまったが
wizmobile 0.5x を試してみた。

でも、0.5x は重いような気がする。

0.4 までは 200ms 程度だったレスポンスが 5sec 程度になっている。
何かまた、サーバの問題があるのだろうか？
それとも機能が増えてこうなったの？

inquiry [0.33] の Preload

2008-12-07T23:40:00+09:00

inquiry の preload が行うこと

PreBlockFilter で
FrontController.PostFilter というデリゲートをセットする。

postFilter 時に
_FRONTCONTROLLER が定義されていなければ
FrontController.PostFilter を raise する。

このデリゲート中では
モジュールの情報をロード ($module->loadInfo()) し、
_SESSION['INQUIRY'] を unset している？
mod_info['mcl_update'] == 'inquiry' なら smarty プラグインをインストールする？

うーーーん。
まず


$module=new XoopsModule();
$module->loadInfo(...)

が気になる。

これをすると、キャッシュされた modinfo を使わずに xoops_version.php は確実に再読み込みされる。

確かに、他への影響を減らすにはよいのだろうが...

XCL [2.1.5] レンダリングのなぞ

2008-09-21T00:30:00+09:00

■_commonPrepareRender
_commonPrepareRender()
はブロックやメイン、テーマのレンダーごとに毎回呼ばれるが、mXoopsTpl に変数をセットしているので、一度セットすれば十分なのではないのだろうか？
内容的にも、不変なもののように見えるが...
RenderTarget で上書きされた場合のことを考慮しているのだろうか？
そうかも...
とはいえ、ちょっと効率が気になる...

■RenderTargetにアサインされた変数
ブロックの場合、RenderTargetにアサインされた変数は、XoopsTpl にコピーされ、レンダリング後 XoopsTpl から消去される。
しかし、メインブロックの場合は、レンダリング後に消去されていないように思える...
なので、theme.html でその変数を使用することができる？(未確認)

XCL ログインのなぞ（その２）

2008-09-11T00:40:00+09:00

その１でコードを変更してみたのだが、よくよく見るとちょっと問題がある。

XoopUserHandler は criteria の条件をエスケープしてくれないので、このままでは脆弱性につながる恐れがある。
修正するとすれば↓のようにする必要がある。


$userHandler =& xoops_gethandler('user');

$criteria =& new CriteriaCompo();
$criteria->add(new Criteria('uname', addslashes(xoops_getrequest('uname'))));
$criteria->add(new Criteria('pass', md5(xoops_getrequest('pass'))));

$userArr =& $userHandler->getObjects($criteria);
$user =& $userArr[0];
(...中略...)

$xoopsUser = $user;

なるほどね。
確かに XoopsObjectHandler は問題ですね...
本来 criteria に渡す際に addslashes などを考慮しなければいけないのはつらい訳で、これでは脆弱性が容易に埋め込まれてしまう...
しかも addslashes は SQL 特有の処理なので criteria の抽象性が失われてしまうし...

Core の部分も XoopsObjectGenericHandler のようにしたいが、それでは影響が大きくなりすぎてしまうので変更できない。
ということで、最初のコードに落ち着いているということかな？

どちらにしても、users に問い合わせをしたいときには
xoops_gethandler('user') ではなく xoops_getmodulehandler('users', 'user') を使え！
というのを覚えておこう >> 自分

XCL ログインのなぞ（その１

2008-09-10T23:10:00+09:00

XCLのログインコードを見ていてちょっと気になったのは


$userHandler =& xoops_getmodulehandler('users', 'user');

$criteria =& new CriteriaCompo();
$criteria->add(new Criteria('uname', xoops_getrequest('uname')));
$criteria->add(new Criteria('pass', md5(xoops_getrequest('pass'))));

$userArr =& $userHandler->getObjects($criteria);
(...中略...)
$handler =& xoops_gethandler('user');
$user =& $handler->get($userArr[0]->get('uid'));

$xoopsUser = $user;

というくだり。
_
なぜ xoops_getmodulehandler('users', 'user') で取得したハンドラでログインチェックを行い、その後そのuid から xoops_gethandler('user') ハンドラを使って $xoopsUser を取得するのだろう？

互換性の問題から $userArr[0] が使えないのはわかるが、それであれば最初からxoops_gethandler('user') ハンドラでログインチェックをすれば良いのでは？

事実このように修正しても、一見動いているように見える...


$userHandler =& xoops_gethandler('user');

$criteria =& new CriteriaCompo();
$criteria->add(new Criteria('uname', xoops_getrequest('uname')));
$criteria->add(new Criteria('pass', md5(xoops_getrequest('pass'))));

$userArr =& $userHandler->getObjects($criteria);
$user =& $userArr[0];
(...中略...)

$xoopsUser = $user;

違いを探るためにそれぞれのハンドラの実装をチェック
・xoops_gethandler('user')
ファイル=kernel/user.php
クラス=XoopsUserHandler extends XoopsObjectHandler
・xoops_getmodulehandler('users', 'user')
ファイル=modules/user/class/users.php
クラス=UserUsersHandler extends XoolsObjectGenericHandler

確かに基底クラスが異なっていたり、XoopsUserHandler は大きすぎる感じはあるが、互換性のためには XoopsUser (=XoopsUserHandler) が必要なことを考えると、そのまま使っても良いような気がするのだが....

続く...
(追記)
上記のコードには問題があるので続きを必ず読みましょう...

altsys の言語定数キャッシュを消したら手動で更新を忘れないように...

2008-08-09T23:40:00+09:00

altsys の言語定数キャッシュ(XOOPS_TRUST_PATH/cache/*)を消してしまうと、ほかのキャッシュのようには自動で生成されない。
これはパフォーマンスとの兼ね合いの仕様であろう。

なので、変更した定数の画面を呼び出して、手動で更新するように。

たまにキャッシュをクリアして、このわなに引っかかり驚く...
くれぐれも忘れないように >> 自分

モジュールのバージョン表示が変わらない？

2008-06-05T23:10:00+09:00

d3blog を 1.02 から 1.02.3a にアップデートしたのだが
モジュール管理画面のバージョン表示は 1.02 のまま変わらなかった。
アップデートに失敗したのか？
しかしd3blogの一般設定画面に新しい項目が増えているから、バージョンはあがっているようだ。
trust_dir にある modules/d3blog/xoops_version.php を見てみると


$modversion['version'] = 1.023;

ためしに xoops_version.php を編集して試してみる


$modversion['version'] = 1.025;

アップグレード必要のマークが表示された。
念のため情報画面を見てみると
1.02 » 1.02
となっている??


$modversion['version'] = 1.033;

アップグレード必要のマークが表示された。
情報画面では
1.02 » 1.03
と表示された。

結論(?)
バージョン情報は x.xx までしか表示されないということかな。

仕様らしきものを見つけた...
http://xoopscube.org/modules/pukiwiki/index.php?cmd=read&page=XOOPSCubeLegacy%2FReference%2Fxoops_version&word=xoops_version


$modversion['version'] 
A version number of the module. This is must. This value is converted to integer and stored to DB.

$storedVersion = (int)($modversion['version'] * 100);Therefore, you must write a version with 'x.xx' format.

$modversion['version'] = '2.08';The following examples are not handled correctly.

[BAD EXSAMPLES]
$modversion['version'] = '1.0.2.1';
$modversion['version'] = '2.5 beta';

とはいえ、cube の世界ではいろいろ議論されているようである...
とりあえず、自分で作るときは n.nn でわかるようにしたほうがいいかな。

ブログ