PEAK XOOPS - News

XOOPS2で、Smartyを採用した際、以下のように実装されました。
・テーマ == Fileテンプレート
・各モジュールのテンプレート == DBテンプレート
・各ブロックのテンプレート == DBテンプレート

モジュールやブロックの見た目に手を入れる場合、当然、これらのDBテンプレートをいじるわけですが、今のテンプレート管理が使いやすいと思っている人はいるでしょうか？

私は思いません。

ある程度技術力のある人なら、みんな私と同じ感想のようで、それ故に、モジュールやブロックについて、Fileテンプレートを採用する動きも多くあります。確かに、Fileテンプレートであれば、FTPでテンプレート構成ファイルを上げれば、一斉に切替可能ですから。

しかし、DBテンプレートは本来、管理者が手軽にいじれるために実装されたはずです。管理画面でちょっと変更すれば、それが反映される。それこそが正しい「Nuke」でしょう。（XOOPSは誰がどう見てもNukeの一派生です）

XOOPSデフォルトのDBテンプレートが評判悪いのは、ちょっとした設計ミスと、本来実装されるべき機能が未実装のままである、という２点に起因していると思われます。

以下に問題点を具体的に挙げます。

1) defaultテンプレートが編集不可能（DBテンプレートのオリジナルは、Fileに存在しているので、ここでオリジナルデータを担保する必要はまったくない）
2) 複製がテンプレートセット単位でしかできない（これだと、カスタマイズしていないモジュールのテンプレートが更新された時の手間が異常に大変になる）
3) テンプレートの削除が１個ずつしかできない（10〜20個もテンプレートのあるモジュールの不必要なカスタムテンプレートを消す場合に気が遠くなる）
4) どのテンプレートをどうカスタマイズしたのかが判らない


そこで今回、tplsadminモジュールという形で、上の問題点を解決した使いやすいDBテンプレート管理を実装してみました。

1) defaultテンプレートも編集可能
2) テンプレートの複製がモジュール単位でも、個別のテンプレート単位でも可能
3) チェックボックス方式で削除可能
4) カスタマイズしたかどうかが一目瞭然の管理画面と、diffが表示される編集画面を実装


このtplsadminがどういうモジュールであるかは、blocksadminを使ったことがあればより判りやすいでしょう。blocksadminではモジュール毎に使いやすいブロック管理画面を提供していたのが、tplsadminではモジュール毎に使いやすいテンプレート管理画面を提供するだけです。管理画面だけのモジュールなので、気軽に導入できます。

もちろん、myblocksadminと同様に、mytplsadminとしてモジュール作者が取り込めば、そのモジュールのメニューにも、簡単に「テンプレート管理」をつけることができます。今後、拙作のモジュールにも、順次mytplsadminを導入していく予定です。

今頃気付いたのですが、本家版XOOPS 2.2.xでは、cofigテーブルの仕様がちょっとだけ変わっています。

従来は、system関連のconfigは、conf_modid=0として保存されていましたが、本家版2.2.xでは、conf_modid=1となっています。

systemモジュールがmid=1であることなどを考えれば、本家版2.2.xの方が妥当だろうとは思えます。

問題は、それによってfatal errorが出る場合があることです。（具体的には、Protectorの管理画面など）

というわけで、configハンドラを取得する際には、conf_modid については、以下のようなCriteriaを利用すれば、本家版XOOPS 2.2.xでも、他のXOOPSでも動くコードになるでしょう。

$criteria = new CriteriaCompo(new Criteria('conf_modid', 0));
$criteria = new CriteriaCompo(new Criteria('conf_modid', 2, '<'));

実は、このサイトについては、あえて本家版で運用しています。
さすがに、2.2.x には穴が多すぎて自分で使う気にはとてもなれませんが、2.0.x 系列であればそれほど酷いことはありません。Protectorとの併用で十分に実用になるでしょう。

実は、2.0.13.2に上げたのは最近なのですが、以下のセキュリティパッチについて、その差が気になったので、ここにメモしておきます。

JP版:
2.0.12-JP -> 2.0.13a-JP

本家版:
2.0.13.1 -> 2.0.13.2

リダイレクトメッセージは、時間がかかって邪魔だと思いませんか？
実際、あのリダイレクトメッセージは、無駄なサーバ負荷にもなっています。

とうわけで、okuhikiさんの書込をヒントに、メッセージをじっくり読みたい人にも、さくさく作業したい人にも最善と思われるHackを施してみました。

このサイトで投稿などしてみればお判りいただけると思いますが、リダイレクトメッセージがリダイレクト後のページに、左ブロックとして表示されます。

また、リロードすれば消えるようにも作っています。ただし、このサイトには、FCH（ページ全体のキャッシュ）がかかっているので、リロードではたぶん消えません。

Hack方法はきわめて簡単です。
include/functions.php の redirect_header() 関数をちょっといじって、あとは、テーマを書き換えるだけです。

コアバージョンによって、結構違うのが面倒といえば面倒ですね。

2.0.13a では、include/functions.phpが書き変わって行数が違っていたので、そこを修正しました。また、HTTPレスポンス分割攻撃の可能性も0ではないため、一応対策コードも追加しておきました。

時間をかけた文章をフォーラムなどに投稿しようとして、タイムアウトに遭ったことはありませんか？
精神的なダメージは大きく、そういうことが頻繁にあると、誰も投稿しようとしなくなってしまうでしょう。

拙作オートログインでは、その対策を施してはいますが、オートログインを入れられない環境（セキュリティ上の理由や、XOOPS2.2）で、なんとかセッションタイムアウトを避けたい、という人も多いでしょう。

かといって、セッション生存時間を長くするのは、セッションハイジャックなどを考えるとマイナスです。

そこで、ハートビート法をXOOPSに取り入れてみました。

いじるのはテーマだけなので、かなり簡単なHackです。