PHPのテクメモ

Xoopsでは大切な変数には$xoopsDBとか$xoopsUserとかいうふうに接頭語として$xoopsをつけているようだ。Xoopsのモジュールを作成する場合はファイルの配置場所とxoops_version.php、それにこれらの変数を知っておけばだいたい記述できるようになると思う。今後の開発の参考のために、大切そうな変数をピックアップしてみた。それぞれの詳細は、後日暇があるごとにメモすることにする（重要度は適当につけてみた）。

$xoopsblock（重要度C）
オブジェクト。多分ブロック関連のオブジェクトと思われる。

$xoopsConfig（重要度A）
配列。基本設定が保存されている模様。

$xoopsDB（重要度A）
オブジェクト。いわずと知れたデータベースのオブジェクト。

$xoopsErrorHandler（重要度A）
オブジェクト。多分プログラムを実行していく上で、ここにエラーが蓄積されていくような感じ。

$xoopsLogger（重要度B）
オブジェクト。ロギング関連と思う。

$xoopsModule（重要度C）
オブジェクト。これはモジュール関連でしょう。

$xoopsTpl（重要度A）
オブジェクト。Smartyの派生クラス。

$xoopsUser（重要度A）
オブジェクト？。アクセスしてきたユーザに関するもの。

とりあえず、ことあるごとにvar_dumpするとか、get_class_methodsとかget_class_varsとかのクラス・オブジェクト関数をそれぞれの変数に対して実行すれば何とかなると思う。

Xoopsでは左ペインや右ペインに自由にHTMLを表示でき、これをブロックという。ブロックはモジュールでも設定できるし、カスタムブロックとしてモジュールに属さないブロックを作ることも出来る。
現在作成中の記事管理モジュールでもブロックを作成しているのだが、これにかなりはまってしまった。はまった内容というのは「何度チャレンジしても予期していないものが表示されてしまう」というもの。
基本的にXoopsではこれらテンプレートはインストール時にxoops_version.phpでの記述に基づいてデータベースに格納される。このファイルにはテンプレートを呼び出すプログラム名やテンプレート名等を記述するのだが、原因は「テンプレートファイル名」だった。
ブロックのテンプレートは基本的にモジュール内の「templates/blocks」ディレクトリに設置することになっている。またxoops_version.phpでは特にディレクトリ名を指定することはなく、ファイル名だけで指定するようになっている。

ここで「予期しないものが表示されてしまう」原因は、「templates下におかれているテンプレートファイル名とtemplates/blocks下におかれたテンプレートファイル名が同じものだったこと」だった。

これはどういうことか。

どうやら同じファイル名のテンプレートがtemplates下にあった場合、そちらを読み込むようだ。だいたいこれがおかしい！。その階層をスキャンするようになっているのなら、xoops_version.phpでディレクトリも含めて指定すればいいはずだ。それが駄目なら、ブロックのテンプレートはtemplates/blocks下のみスキャンすればいいはずだ。

結局解決策として、ブロック用のテンプレートのファイル名を変更し、xoops_version.phpでのテンプレートの指定を変更することでうまく動作してくれた。

こんなことで1時間以上悩んでしまった。
こういうタコな仕様は改善されるべきと思う。

Xoopsモジュールを作成する上で、いくつか壁にぶち当たったのでメモ。
Xoopsではデータベースにアクセスするためのクラスが提供されるが、これには少し癖（というかお節介なところ）があるような気がする。

現在は記事管理のモジュールを書いているのだが、記事の表示回数を取得して、記事ランキング機能をつけないといけない。そこでモジュール内に専用のクラスを用意して、そこで表示回数をカウントアップする関数を書き、ページ表示時にその関数が実行されるようプログラムを記述した。この関数はデータベースの記事テーブル内の表示回数を格納するカラムをカウントアップするためのものだ。

しかし、いざこれを実行してみてもカウントアップされない。「え、なんで？」。
ためしに実行させているSQL文を書き出して、phpMyAdminから実行すると正しく動作している。「ん〜、自前のクラスで何か不都合があるのかも」と思い、プログラム内に直接SQLを書いて$xoopsDBに放り込んでみた。

しかしだめ。「え〜〜、なんで〜〜？」

$xoopsDBにはMySQLのエラーを取得する関数が用意してあるので、それを使ってみるとエラーはない模様。ますます「なんで？」。

仕方がないのでSQL実行後にvar_dump($xoosDB);を書いてみたら、エラーがあったよ。「Database update not allowed during processing of a GET request」。こんな舐めたエラー、おせっかいにもほどがあるよ！。
要はMySQLに渡す前にXoops側でチェックして、getでアクセスがあった場合は関数queryでテーブルの更新をかけられません、とのたまっているのだ。しかし「こんな仕様だとマジで使い物にならないはず」とソースを読んだら、もういっこ関数が用意されていた「queryF」。最後の「F」はforceの略？、強制的とか言う意味なのかな。

こちらの関数を使うことで無事処理が実行できた。
やはりXoops、少し（かなり）癖がある。慣れるまで大変だ。

今、Xoopsのモジュール作成にチャレンジ中。
チャレンジといってもお仕事なので、もちろんまじめに取り組んでいる。元来どんな仕組みでも癖というものがあるが、Xoopsについて、プログラムを書いていく上での、現時点での心象をメモしていく。

○好きなとこ
・どんなモジュールでもxoops_version.phpという設定ファイルを書くのだが、正しく書けばそれだけで簡単な設定画面を作成できる。

今のところ「いいな」と思ったのはそれだけ。個人的には「嫌だな」と思うところが結構ある。

○嫌なとこ
・一般ユーザ向けはSmartyで処理するのに管理画面はSmarty関係なし（ありえない）。
・php関数constantとか使ってて、変数の設定をするのに、本来$moji=VALUEみたいに書くように統一すればいいのに$moji=’VALUE’みたいな変則的な書き方をするべきところが一部ある（ていうか統一してよ）。
・各種キャッシュを無効にするオプションがない（どこかにあるのか）。モジュール作成時はファイルの書き直しが頻繁なのだから、キャッシュされるとそれを無効にする術がわからない。結局モジュールのアンインストール＆インストールなんていう手間な作業をしている。

数え上げればきりがない。まぁ、きっと奥深くお作法があるとは思うのだが・・・。Xoopsモジュール作成ガイドみたいなページないのかな。あれば絶対にページビューすごいと思うのだけど・・・。

どうも昨年当初からXoopsとOpenPNEを連携させるという機能への研究が始まっているらしい。それにOpenPNE開発元の手嶋屋さんも一声乗ってそうな感じ（手嶋屋さんのブログにて）。
しかし手嶋屋さんのブログで社長コメントが昨年2月以来追記されていない。なんでも文字コードがらみが大変なんだとか。ん・ん・ん。
さらに調べてみるとXoops、OpenPNE双方ともLDAPに対応させることが出来ているような記事も見受けられる。こんなふうにXoopsとOpenONEが直接連携しなくても、別のサービスを介して連携させることさえ出来れば十分だ。
そしてもう一つ言うなら、それがLDAPとかじゃなく、ウェブサービス的な感じでできるとうれしい。
最近ようやくXoopsモジュールの開発を始めたので、ちょっとチャレンジしてみる？！。少しお金がたまって生活に余裕が出来たらね。

と思ってさらに調べてたら2006年12月にスレーブPNEという名前で何かがでてる模様（ここ）。
XoopsはいいけどOpenPNE側でエラーメッセージが・・・。多分関数の引数を参照渡ししてるようなエラー。ソースも落とせそうなので、これで修正してしまえばいけそうな感じだ。

1年かかったんだ。