Home » XOOPSの新型モジュールシステム「D3」の説明

D3モジュールとはなんなのか?

 単純にいうと、サーバの「隠しスペース」とでもいうべき場所を有効利用し、従来のモジュールと比べて、「複製の圧倒的な容易さ(同じモジュールをいくつでもインストールできる)」「セキュリティの向上」という利点をもたらしてくれる新型モジュールシステムです。
 今までのモジュールは、/modules/ という、基本的にブラウザで誰でもアクセスできる場所にすべてのファィルをアップロードしていましたが、D3モジュールはファィルの役割によって、

 今までのモジュールのアップロードに使っていた /modules/
 D3モジュール用に開拓する /xoops _trust_path/

 という二箇所に分けてアップロードすることになります。
 xoops _trust_pathというのは、D3モジュールの登場で初めて定義された場所なので、このディレクトリを使うためには、XOOPSに「今度、xoops _trust_pathっていうディレクトリを作って、そこにモジュール関連のファイルをアップロードでするから。よろしく~」と教えてあげる必要があります。そのために、D3モジュールを初めてインストールするときは、mainfile.phpをエディタで開き、設定を自分で書き込まなければなりません。

 今までのモジュールであれば、そういった事前準備などしなくても、/modules/ というディレクトリにファイルをアップロードして、管理画面で2、3回ボタンをクリックすればインストールが終了したので、PHPファイルを開いて文字列を書き込むという作業に抵抗感を覚える人は多いでしょう。便利そうだけど、よくわからないまま大事なファイルをいじって、サイトが見られなくなってしまったら嫌だからという理由で使用を敬遠している人も相当数いると思われます。

 しかし、設定を書き込むのは最初にD3モジュールをインストールしたときのみです。時間にすれば数分の作業でできますし、もし、記述の仕方が間違っていたりしてサイトが表示できなくなったとしても、mainfile.phpを自分のパソコンのハードディスクにあらかじめバックアップしておき、それを上書きしてやれば必ず元に戻ります。

なぜD3モジュールなのか?

 それまでまったく問題なく使えていたものが、ある日突然切り替わったりすると、大抵の人は「え、今までのでいいじゃん」と思うでしょう。現在、GIJOEさんのモジュールで開発がD3に移行されたパターンは以下の通りですが、

ほとんどの人は、TinyDや旧Xoops Protectorを特に不満なく使っていたのではないでしょうか。逆に、突然仕様変更になって戸惑っている人も多いかもしれません。では、なぜこれらのモジュールがD3化したのか。それはD3モジュールならではの長所が、開発者だけではなく、利用者にとっても有益だからです。いつものように、たとえ話を使って説明してみたいと思います。

↑このページの一番上へ

D3モジュールの長所とは

 簡単に言って2点あります。
 まず、今までのモジュールを「全国各地に実店舗を置いて展開しているAmazon.co.jp」と思ってください。これは実際にはありえないものなので、行きつけのコンビニの看板を頭の中でAmazonに書き換えて、それが日本のあちこちに存在している様子を想像していただけるといいと思います。
 次にD3モジュールを「ネットでオンライン販売を展開しているAmazon.co.jp」と思ってください。こちらは、実在しているAmazonということになります。

 両方のAmazonが新たに「車の販売」を手がけることになったとします。XOOPSのモジュールで言えば新機能の搭載、要アップデートです。
 実店舗を置いて展開しているAmazon.co.jpの場合、全国にあるすべての店舗に社員が出向き、手間と時間を掛けて改装して車を置くスペースを作り、実際に車を置かなければなりません。このことをXOOPSの従来のモジュールに置き換えれば、TinyDなど複製したモジュールをアップデートする場合、それぞれのモジュールフォルダにアクセスしてアップデートファイルをいちいち上書きしていかないと駄目ということになります。手間がかかる作業なのでミスも出やすいでしょう。
 しかし、オンライン販売だけのAmazon.co.jpであれば、車は本社の倉庫を拡張して置いておけばよく、あとはサイトに「車の販売始めました」とでも書いて画像を載せればOKです。支店とも言えるアフィリエイトサイトの画像も勝手に切り替わります。本社が変われば、同時に全体も変わるのです。
 D3モジュールに置き換えれば、XOOPS_TRUST_PATH側(本社→管理する側)とmodules側(支店→管理される側)が分かれるという仕組みから複製(新たなる支店の建設)が極めて容易であり、アップデートする場合も、本体(XOOPS_TRUST_PATH側)だけ上書きしておけば、アップデート箇所はそこから子フォルダに連絡されるので、どれだけモジュールを複製していても基本的に作業は一回で済んでしまうというわけです。
 以上のように、D3モジュールは複製及びアップデートの手間、あるいは改造の手間が非常に簡単です。

 もう一つの大きな長所は「セキュリティの向上」ということです。
 実店舗を置いて展開しているAmazon.co.jp。当然、商品は棚に並んでいます。その商品が「PHPファイル」だとすると、悪意を持った客はそれを変な風にいじる可能性があります。あるいは、普通なら客が入るようなところではないけど、入ろうと思えば入れる場所に入り、店について大事なことが書いてあるファイルなど、商品ではないものにも触ってくれるかもしれません。もちろん、店側はそうされないように、またされても問題が起きないように対策を取っていますが、あっと驚くような手段で一枚上を行かれる可能性もあるわけです。結果、店舗全体にひどい落書きをされたり、それだけでは済まずに店の重要情報(顧客のメールアドレスや名前)をごっそりと持っていかれ、そこから二次被害につながるということになりかねません。
 オンライン販売だけのAmazon.co.jpであれば、商品のPHPは、本社の倉庫、つまりドキュメントルート外にあるXOOPS_TRUST_PATHにあるので、悪意を持った客は、ネットを介した状態ではどう頑張ってみてもその商品に細工をすることはできません。触れる場所に存在しないわけですから。

 もし、この説明にピンと来なくてXOOPS以外にもCGIやPHPのスクリプトを使っているという場合は、そのスクリプトのフォルダ内を見てください。○○.ini、○○.cfgといった、ブラウザでアクセスすればダイレクトに内容が展開されるファィルに、暗号化されていない平文の管理パスワードが思いっきり書かれているのを見つけることができるかもしれません。.htaccess(後述)で弾いているケースがほとんどだとは思いますが、中にはランダムなファイル名を付けているだけというものもあるでしょう。.htaccessで制御もせず、indexファイルも置かず、フォルダの一覧が見られる設定になっていたら。ランダムなファイル名なんて対策になりません。第三者が○○.ini、○○.cfgをダブルクリックした瞬間、パスワードが漏れます。
 しかし、もしドキュメントルート外、つまりブラウザでアクセスできる場所にこれらのファイルがあれば、このようなケースは防げるわけです。ドキュメントルート内に置く必要のないファイルは無用なトラブルを防ぐためにできるだけ外に出すというのが現在のトレンドです。

ドキュメントルート外にのみフォルダがある場合の、ユーザとフォルダの関係ドキュメントルート外にD3モジュールのフォルダを置いた場合

キャプション 左の図は通常のモジュールと閲覧者(登録ユーザ)の関係。閲覧者は基本的にすべてのファイルに直接アクセスできる。セキュリティホールを知っている、あるいは偶然のアクセスによってもトラブルを起こす可能性がある。右の図はD3モジュールと閲覧者の関係。閲覧者はドキュメントルート外にあるD3モジュールに直接アクセスできない。しかし、ドキュメントルート内に設置されたD3モジュールフォルダを介して情報を得ることができる。Amazonのたとえでいえば、ドキュメントルート内のD3モジュールフォルダはペリカン便の人である。閲覧者は店に置いてあるものには一切手を触れることはできないが、手順を踏んで「商品」を請求すれば、ちゃんとペリカン便の人が運んできてくれる。

 管理がしやすい、セキュリティの向上、この2点において、旧モジュールからD3モジュールに乗り換える価値は充分にあるのです。

↑このページの一番上へ

インストールについて

 D3モジュールのインストールについては、それぞれのファイルに同梱されている説明を見れば大丈夫ですが、一応順を追って説明します。

 まず、D3モジュールを初めてインストールする場合、mainfile.phpに「XOOPS_TRUST_PATH(ドキュメントルート外または内のこの場所に、D3モジュールを統括しているフォルダがあるよ、という定義)」を書き込む必要があります。XOOPSは「XOOPS_TRUST_PATH」の存在なんて知りませんから、場所を教えてやるのです。ちなみにXOOPS Cube Legacy2.1は「XOOPS_TRUST_PATH」の存在を最初から知っており、パスを書き込む場所がちゃんと用意されています。D3の設定を一からやらなければいけない、つまりパスを書き込む場所すらユーザが用意しなければならないのは、XOOPS 2.0.16aまでのXOOPSです。
 とりあえず、mainfile.phpをハードディスクのどこかにバックアップしておいた方がいいでしょう。D3モジュールにおいてトラブルを誘発する原因は、ほとんど、mainfile.phpの書き換えミスだと思うので、もしサイトの表示がおかしくなったら、バックアップしておいたmainfile.phpを上書きしてやれば大丈夫です。

 書き換えるmainfile.phpをエディタで開いたら、

 define('XOOPS_URL', 'あなたサイトのアドレス');

 の下に、

 define('XOOPS_TRUST_PATH','/home/yourhome/xoops_trust_path');

 という一行を付け加えてください(繰り返しになりますが、XOOPS Cube Legacy2.1のmainfile.phpには、既にこの行は存在します。よって改めて書く必要はありません)。

 define('XOOPS_URL', 'あなたサイトのアドレス');
 define('XOOPS_TRUST_PATH','/home/yourhome/xoops_trust_path');

 上のような並びになります。

xoops_trust_pathを定義したmainfile.php

キャプション XOOPS_TRUST_PATHを設置したmainfile.phpの中身。

 /home/yourhome/というのは、人それぞれ違ってきます。もし覚えていなかったら、mainfile.phpに書いてある、

 define('XOOPS_ROOT_PATH', 'あなたのサイトのルート');

 を参照してください。多分、'あなたのサイトのルート'は、'/なんとか/かんとか/public_html' こんな風になっていると思うので、public_htmlを除いた、/なんとか/かんとか/ を /home/yourhome/ に当てはめればOKです。
 ちなみに、/なんとか/かんとか/部分は必ずしも、このようにスラッシュ二つ分とは限りませんし、public_htmlも絶対そうなっているとは言えません。よくわからなければ「あなたのサイトのルート」に書かれているパスの一番最後の文字列は無視し、先頭のスラッシュから、無視した文字列の直前までのスラッシュ、ここまでをコピーして/home/yourhome/のかわりに貼りつけてください。

 もし、「あなたのサイトのルート(太字部分)」に下のように書かれていたら、

 define('XOOPS_ROOT_PATH', '/home/yourhome/user/site/www');

 最後の文字列は無視して、

 define('XOOPS_ROOT_PATH', '/home/yourhome/user/site/www');(赤の部分無視)

 先頭のスラッシュから無視した文字列の直前のスラッシュまでをコピーして(切り取りではなく、あくまでもコピー)、

 /home/yourhome/user/site/     さようなら~www

 xoops_trust_path設定行の/home/yourhome/部分にペースト。

 define('XOOPS_TRUST_PATH','/home/yourhome/user/site/xoops_trust_path');

 書き換えたら上書き保存して、FFFTPなどでアップロードしてやります。この際、サーバにあるmainfile.phpのパーミッション(属性)が444とか404だと上書きできないので、644、604などに変更してからアップロードするようにしてください。パーミッションの変更が面倒だったらサーバのmainfile.phpを削除してから、アップロードでもかまいません。

mainfile.phpのパーミッション(属性)を変更する画面

キャプション パーミッションの変更画面。

 次にドキュメントルート外に「xoops_trust_path」という名前のフォルダを作成します(なお、モジュールファイルの中にあるxoops_trust_pathフォルダをそのままアップロードするならば作成する必要はありません)。この場合のドキュメントルート外というのは、インターネットに公開しているフォルダの親フォルダ(普通はpublic_html)と並列している場所と考えていいと思います。
 もし、FFFTPなどでサーバにアクセスしたとき、サーバ側の画面に「class」とか「kernel」とか「modules」とかXOOPSのフォルダが表示されていたら、「一つ上のフォルダへ」のボタンをクリックして、ドキュメントルート(public_html)外に移動してください。「一つ上のフォルダへ」をカチカチとクリックしても、サーバ側の画面(フォルダ構成)が変化しなくなったとき、「public_html」というフォルダが見えたら、そこがドキュメントルート外と考えて多分大丈夫です。

ドキュメントルート外のフォルダ構成の一例

キャプション ドキュメントルート外のフォルダ構成の一例。

 ドキュメントルート外に管理者自身もアクセスできないサーバ(たとえばロリポップ)の場合は、ドキュメントルート内、つまり通常、ファイルをアップロードするところの適当な場所に「xoops_trust_path」というフォルダを作成し、その絶対パスをmainfile.phpにある、

 define('XOOPS_TRUST_PATH','/home/yourhome/xoops_trust_path');

 に書き入れてください。public_html直下に作った場合は、

 define('XOOPS_TRUST_PATH','/home/yourhome/public_html/xoops_trust_path');

 こんな感じになるかと思います。ロリポップだと、

 define('XOOPS_TRUST_PATH','/home/sites/lolipop.jp/users/ここは人によって違う?/web/xoops_trust_path');

 こんな感じでしょうか。

 ドキュメントルート内にXOOPS_TRUST_PATHを置いた場合でも、モジュールの複製及び複製したモジュールのアップデートが簡単といった恩恵は受けられます。
 なお、少しでも安全性を高めるために、作成したXOOPS_TRUST_PATHフォルダの中に、

 order deny,allow
 deny from all

 と書いた.htaccessファイルを入れるようにしてください。deny from allの行も必ず改行すること。deny from allと書いたら、最後にエンターキーを1回押すということです。.htaccessの作り方は、エディタの新規作成で上の二行を書き、.htaccessという名前で保存してやればOKです。あくまでも名前は

 .htaccess

 であって、

 .htaccess.txt

 などではないので要注意。orderから始まる二行の意味を要約すると「誰も入ってくんじゃねえよ」です。.htaccessについて詳しく知りたい方は、

 .htaccess実践活用術

 などを参考にするとよいでしょう。このファイルを使うとなにができるのかということを深く知ると、格段に幅が広がります。

サーバにあるドキュメントルート内のフォルダ

キャプション サーバにアクセスして、public_html直下のフォルダが出てきたら、一つ上のフォルダへ移動する。

 XOOPS_TRUST_PATHフォルダの作成はFTPクライアントソフトで行います。FFFTPであれば、サーバー側の画面のどこでもいいので右クリック。そうすると、メニューに「フォルダ作成」というものが出るので、それを左クリック。フォルダ名入力画面に xoops_trust_path と入れればOKです。

フォルダ作成画面

キャプション 右クリックした際、無関係のフォルダにフォーカスが当たったりするが、気にせずにフォルダ作成を選択。

 ここまできたらあとは簡単で、D3モジュールを解凍し、htmlフォルダに入っている方のファイルは、いつものmodulesフォルダへ、xoops_trust_pathフォルダに入っている方は、先ほど作成したxoops_trust_pathにアップロードするだけです。そして、モジュール管理画面で、一番下に表示されているはずの、D3モジュールのインストールアイコンを押して完了ということになります。
 参考までに書いておくと、どのD3モジュールを使うにしても、まずはblocksadminの後継であるaltsysを先にインストールしておいた方がいいです。テンプレートの改造(編集)、ブロック及びアクセス管理のしやすさが、このモジュールが入っているのといないのとではまるで違います。altsysはすべてのD3モジュールの土台と考えてください。

動画リンク D3モジュールのアップロード ビデオチュートリアル

(再生時間60秒 1.2MB 要FLASHプラグイン)

 ドキュメントルートの内外にそれぞれファイルをアップロードするという作業を感覚的に掴めるように、FFFTPとaltsysを使ったビデオチュートリアルを用意しました。見ていただければわかると思いますが、非常に簡単です。手順がこのページに書いたものと多少違い、また、ドキュメントルート外にフォルダを作成する方法を見ていただくため、無駄な手順を一個踏んでいますが、この通り実行していただいて特に問題はありません。説明文の文字が所々かすれているので、見えない部分は想像で補っていただくようお願いいたします。

アップデートと削除について

 先にも書いた通り、アップデートはどれだけ子フォルダを複製していたとしても、基本的に本体側(xoops_trust_path)のみ上書きで問題ありません。子側もアップデートする場合は、そういう指示が必ずあると思いますので、ファィルに添付されている説明ファイルを確認しておきましょう。
 削除は通常のモジュールと同じ削除方法で大丈夫です。モジュール管理画面で手順を踏んで、本体側とxoops_trust_path/modules/以下にある子側のフォルダをそれぞれ削除ということになります。ただ、他にもD3モジュールがインストールされている場合は当然として、D3モジュールが削除したものしかなかったとしても、xoops_trust_pathフォルダとmainfile.phpに書いたxoops_trust_pathはまた後で使う可能性が非常に高いので、そのままにしておいた方がいいでしょう。

↑このページの一番上へ

うまくインストールできない場合

 ちゃんと設定したつもりなんだが、どうもうまくいかないという場合は、以下のポイントをチェックしてみてください。

 '/home/yourhome/xoops_trust_path'と書くところを'/home/yourhome/xoops_trast_path'としてしまったなど。綴り間違いだけではなく、大文字と小文字の区別にも注意してください。

 特に“xoops_trust_path”というフォルダをあらかじめ作成しておいて、その「中」にモジュールのxoops_trust_pathフォルダを転送してしまったというケースに注意。これだとxoops_trust_pathフォルダの中に更にxoops_trust_pathフォルダが存在するということになってしまいます。
 上書きする場合は必ず、ローカル(自分のパソコン)とサーバで同一のフォルダをぶつけるような形にしてください。“xoops_trust_path”フォルダを上書きするなら、サーバ側に“xoops_trust_path”フォルダが見えている必要があります。くれぐれもサーバ側の“xoops_trust_path”フォルダをダブルクリックして開いて、そこにローカル(自分のパソコン)の“xoops_trust_path”フォルダをアップロードしないように。

 html側とxoops_trust_path側のフォルダ名が/modules/とか/モジュール名/とか結構かぶっているので混同しないようにしましょう。

 上のチェック項目と似ていますが、入れ違えるのではなく、ローカル側を切り替えずに、サーバのhtml側、xoops_trust_path側に同じファイルを転送してしまうというミスも考えられます。

 アップロード時、なんらかのトラブルでサーバに上がっていない、または不完全な状態で上がったファイルがあるかもしれません。こういう場合はすべてのファイルをアップロードし直してみてください。また、html側、xoops_trust_path側共に、常に/modules/フォルダ以下に必要なファイルがすべて入っているとは限りません。/modules/フォルダをアップロードした記憶はあるが……という場合は、/modules/フォルダと並列しているフォルダ(たとえばcommonフォルダなど)がないかどうか確認してみてください。

↑このページの一番上へ

2007年2月12日執筆 2008年1月12日加筆修正