リンク XOOPSをダウンロードしたい！ インストールについて知りたい！ モジュールについて知りたい！ テーマを探したい！ レンタルサーバーを探したい！
モジュールをアップデートしてみる [Permalink]
アップデートはインストールよりも簡単 [Permalink]
モジュールのインストール及びアンインストールの説明が終わったところで、いよいよ、モジュールを使って自分の文章をサイトに表示するための設定方法の説明といきたいが、ここまできたらついでなのでモジュールのアップデートの説明をしておきたい。アップデートというとインストールよりも難しそうだが、実際は普通のモジュールでもD3モジュールでもアップデートファイルを上書きするだけで済み、早い話、ファイルをアップロードすれば基本的にそれだけで終了する。アップロード後にもいろいろと段取りがあるインストールより遥かに簡単だ。
大きく分けて、モジュールのアップデート方法には「ファィルの種類が二種類」×「アップデートの手順が二種類」で計四種類のパターンがある。
作成者がアップデート専用ファイルを用意していない場合(だいたいこちら)
- 新しいバージョンのモジュールファイルを、そのまま上書きする
アップデート完了 - 新しいバージョンのモジュールファイルを、そのまま上書きして、「システム管理」→「モジュール管理」でアップデートボタンを押す
アップデート完了
作成者が新しいバージョンのモジュールファイルとは別に、アップデート専用ファイルを用意している場合(XOOPS本体のアップデートと同じ手順。かなりレアケース)
- アップデートファイルを、そのまま上書きする アップデート完了
- アップデートファイルを、そのまま上書きして、「システム管理」→「モジュール管理」でアップデートボタンを押す
アップデート完了
青線で囲ってあるのがモジュール管理画面にあるアップデートボタン。モジュールごとに存在している。指示がなくてもアップデートボタンはとりあえず押すようにしよう。
最近は、モジュール管理でアップデートボタンを押さなくても正常にアップデートできることが多くなってきたが、「押さなくてもいい」と書かれていても押す癖を付けておいたほうが簡単なトラブルに巻き込まれずに済むだろう。
なお、上書きの方法だが、本体をFFFTPを使って丸ごと上書きする場合、ファイル数が多いと面倒なのでついつい「新しければ上書き(ファイルの作成日時が、サーバのものよりローカルにあるものの方が新しかった場合のみ上書きする)」を選びたくなるが、この方法を取ると新バージョンのファイルが旧バージョンのファイルに上書きされないというケースが出てくる。
アップロードは「上書き」で。
なぜそういうことになってしまのか。サイト運営者が古いファイルをカスタマイズし、それをアップロードすると、作成日時がカスタマイズした日に変わる。その日が、モジュール作成者が用意したアップデート用のファイルの作成日時より新しい場合、当然、「新しければ上書き」というケースにはならないので、バージョンは古いのに上書きされないということが起きてしまうというわけだ。
このケースは二つの問題を引き起こす。一つは、バージョンの違うファイルがごちゃ混ぜになるということ。同じものだからと言って、新しい食品と古い食品を混ぜているようなものだ。こういった状態のモジュールは問題を抱えながらも表面的には普通に動作するが、ある段階で破綻し、まったく動作しなくなるということが結構起こりうる。サイト運営者にはある日突然動かなくなったように見えるので、しばしば問題解決まで非常に時間がかかる。
もう一つは、旧バージョンファイルにセキュリティホールがあった場合、そのまま残ってしまうということ。運営者はバージョンアップをした気になっているので、もし問題が起きた場合、これまた解決に時間がかかってしまう。
以上のように、「新しければ上書き」はトラブルを引き起こす中途半端な上書きをしてしまう可能性があるので、必ず「上書き」を選択しよう。
D3モジュールのアップデート方法 [Permalink]
D3モジュールのアップデートについても説明しておこう。この項目の方で「普通のモジュールでもD3モジュールでもアップデートファイルを上書きするだけで済む」と書いた。それは確かなのだが、D3モジュールの場合はアップロードするファイルとアップロードする場所がちょっと違うので説明しておきたい。
普通のモジュールは一つのディレクトリにファイルすべてが入っているので、これをサーバ上のmodulesディレクトリ以下にある、同名ディレクトリにそのまま上書きしてやればいいのだが、D3モジュールの場合(仮にweblogD3)、
html/modules/weblogD3
xoops_trust_path/modules/weblogD3
と、ファイルが入っているディレクトリが二つ存在する。どちらの方をアップロードしてやればいいのかといえば、
xoops_trust_path/modules/weblogD3
の方、つまり「xoops_trust_path」側だけでいい。D3モジュールはいくらでも複製できるという長所があるが、どれだけ複製していても、xoops_trust_pathにファイルをアップロードすればOKだ。
まれに、html/modules/weblogD3の方もアップデートしなければいけないときがあるが、そういった場合は更新情報にその旨が書かれていると思うので、ファイルのダウンロード時には常にチェックしておきたい。
一応書いておくと、指示がない場合に、「いや、でも心情的にやっておきたい」とxoops_trust_pathと合わせてhtml/modules/weblogD3の方をアップデートしたとしても特に問題は発生しない(無駄ではあるが)。だが、xoops_trust_path/modules/weblogD3の方にアップロードすべきファイルをhtml/modules/weblogD3にアップロードしたらさすがに駄目なので、アップロードする前にはよく確認しよう。
XOOPS Cube Legacyでのモジュールのアップデート [Permalink]
アップデートボタンを押さない限り、管理画面に表示されているバージョンと実際にサーバに存在しているファイルのバージョンが同一なのか違うのかわからなかった2.0.16a以前のXOOPSと違い、XOOPS Cube Legacyではバージョンアップしたモジュールファイルをサーバに上げれば、管理画面でその旨が一目で確認できるようになっている。
現在使用しているバージョンより新しいバージョンのファイルがアップロードされると、管理画面で現在のバージョンナンバーが青くなり、その横に赤い矢印のアップデートボタンが表示される。
旧XOOPS同様、アップデートボタンを押す押さないに関係なく、ファイルをアップロードした時点でバージョンアップは済んでいると考えてもほぼ問題ないが、赤い上下の矢印が向かい合っているわかりやすいアップデートボタンをクリックしてマイナスは一切ない。現在上がっているファイルのバージョンを確認しやすいように押しておいた方がいいだろう。
アップデートの確認画面。作業手順が明確になり、2.0.16a以前のXOOPSよりもわかりやすくなった。
アップデート時の最大の注意点 [Permalink]
最後にアップデート時の注意点だが、絶対に頭に入れておかなければならないのは、サーバ上にあるファイルは上書きしたら完全に消えるということ。自宅のパソコンに入っているソフトなら、場合によっては「上書きされたファイルです」という意味合いのバックアップファイルを作ってくれるかもしれないが、サーバはそんな気の利いたファイルは作ってくれない。
したがって、モジュールのテンプレートをカスタマイズしていて、それを複製していない場合、新しいバージョンのモジュールファイルをやみくもに全部上書きしてしまうと、当然、サーバ上にあった“カスタマイズしたテンプレート”はこの世から消滅する。渾身のコーディングも思い出だけしか残らない。彼女と別れても、「傷つけちゃってごめんなさい。これからは友達として応援します」などと書かれた手紙と前年の誕生日プレゼントぐらいは残ることから考えても、別れの残酷さで史上最強クラスといえるだろう。この悲劇を回避するためにテンプレートファィルは必ず複製しておこう。
さて、複製しておいたファイルをそのままアップロードして元に戻るならそれに越したことはない。問題は、カスタマイズしたファイルがアップデート対象ファイルになってしまった場合である。たとえばHTMLの記述が含まれているPHPファイルなどが当てはまりやすい。
カスタマイズしたファイルがアップデートとはまったく関係ないファイルであれば、バージョンアップしたモジュールのファイルを全部上書きしたとしても、複製しておいたものを更に上書きするという形で済むが、カスタマイズしたファイルがアップデート対象ということになると単純に元に戻せないので、
hoge.php(デフォルトのhoge.phpを作成者がカスタマイズしたもの)
↓
新しいモジュールファイル全部上書き
↓
hoge.php(通常のファィルに戻ってしまった！)
↓
こういうこともあろうかと、複製しておいたカスタマイズバージョンのhoge.phpを更に上書き
↓
hoge.php(無事、元に戻った)
という、“サイト作成の遠山・葛西スペシャル”とでもいうべき方法が使えなくなってしまう。カスタマイズした部分を、新しいファイルの似たようなところに移せばそれで済むだろうと思いたくなるが、そもそもどこをどうカスタマイズしたのか完全に忘れ、結果、バージョンアップを諦めるということもよくある話である。
こういった悲劇をどう回避すればいいのかというと、「WinMerge」のようなファイル内容を比較できるソフトを使い、素の旧ファイルとカスタマイズした旧ファイルを比較し、どこがどうカスタマイズされたのか割り出して、新ファイルに適用するというような対処方法が考えられる。
WinMergeの画面。二つのファイルのソースの違いを確認できる。
[コラム]セキュリティアップデートをせずにサイトをクラックされるとどうなるか [Permalink]
XOOPSに限らず、インターネットに関連するソフトウェアが必ず直面する問題が「脆弱性」というやつである。
たとえば、
あらかじめ「管理者固有の」メールアドレスを設定ファイルに書き込んでおき、それをサイトのフォームに入力することによって管理者としてログインできるサイト
というのがあったとしよう。
だが、このメールアドレスのチェックというのが、プログラムを組んだサイトの運営者が「自分は政府関係者の人間でgo.jpドメインのメールアドレスを使っている。まさか自分のサイトを訪れるユーザでこのドメインのアドレスを持っている人間はいないだろうから、大丈夫だろう」と踏んだ結果、「@以後のドメイン名が一致していればOK」としていたらどうだろうか。仮に設定したアドレスが“example@example.go.jp”だった場合、入力されたアドレスが“a@example.go.jp”でも“b@example.go.jp”でも管理者としてのログインを許してしまうということになる。脆弱性というのは、このような、プログラムに存在する想定外のアクセスを通してしまう穴である。
ではこのような脆弱性を放置、つまり、セキュリティアップデートをまったくせずに放置してクラックされたらいったいどうなるのだろうか？
過去の歴史において、XOOPSで構築された(そして、多くは放置していた)サイトがクラックされた例はいくつもあるが、多くの被害のパターンが“トップページを書き換えられる”である。どう書き換えられるかはだいたい2パターンあり、一つは、「このサイトは俺様がクラックしてやった」みたいな感じで、クラックしたことをただ誇示されるというもの。もう一つはクラックした個人、あるいはグループの主張が載せられるというものだ。
クラックされたサイトのトップページのイメージ。
完全に再現するのもあれなので画像はネタに走ったが、とても直視できない残酷な写真などを貼りつけられる場合も多々ある。
こういうクラッカーたちは、登録されているユーザは誰かなんていう情報には恐らく興味はないだろうし、見てもいないと思う。
だが、決して「トップページが書き換えられました」だけで被害が済むとは限らない。サイトを復旧したとしても、登録していた人は不信感を抱くだろうし、人によってはもう二度と来ないだろう。また、残酷な写真を見てしまい、トラウマを抱いてしまうユーザもいるかもしれない。また一見してはわからないが、トップページにウイルスを仕込まれている可能性もある。Windowsアップデートは手動でやってます、セキュリティソフトは高いので入れてません、みたいなユーザがいたら確実にそのウイルスを食らって、二次被害、三次被害を呼ぶ。さらに、トップページに貼られた画像がどう見ても裸の小学生とかになってくると状況は極限まで悪化する。
確かに、玄関に鍵を掛けずに何度も外出しているのに泥棒に入られたことは一度もないという人がたくさん(？)いるように、セキュリティアップデートをまったくせずに放置していてもハッキングされない場合も多々あるだろう。だが、対処すれば狙われる危険性はずっと減るのに、あえてせずに自サイトの行方を運に委ねるというのは無謀だ。
24時間、常にアップデート情報を見られるとは限らない。なので、現実的なのは「セキュリティアップデート情報を目にしたら、その時点でファイルを入手してアップデートを行う」ということだ。後でやろうと思うと忘れるかもしれないし、もしかしたら、直後にしばらくネットにアクセスできない環境に置かれるかもしれない。早め早めの対応を心がけてサイトの安全を守ろう。
バージョン管理システム「Subversion」でファイル管理を楽にする [Permalink]
また、もう一歩進んだ対処方法として、バージョン管理システムをパソコンにインストールし、XOOPS関連のファイルはなんであろうがとにかく管理下に置くというやり方もある。
Subversionというソフトウェアがあるのだが、このソフトを使うとファイルの履歴をすべて残してくれ、いつでも内容を取り出せる。
Subversionをマウスなどで扱えるようにするTortoiseSVNで見たファイル比較画面。WinMergeのそれとよく似ているが、どこを削除し、どこを書き加えたのかということが詳しくわかる。
仮にhoge.phpというファイルをカスタマイズしたとすると、
素のhoge.php
│
└カスタマイズしたhoge.php
│
└カスタマイズしたものを更にカスタマイズしたhoge.php
│
└カスタマイズしたものを更にカスタマイズしたものを更に……(以下略)
と、カスタマイズした記録をファイルごとに残しておいてくれる。もちろん、中身もしっかり記録してくれるので、どの時点でも好きに戻せる。当サイトもSubversionで管理しており、このページはmain4.htmというファイル名なのだが、加筆、編集したごとのmain4.htmがきちんと残されているので、前々回アップしたmain4.htmと今回のmain4.htmはどこかどう違うのかなということも一目瞭然だ。
TortoiseSVNで見たファイルの履歴画面。いつのものであってもすべて中身も記録されている
Subversionを掘り下げるとXOOPS以上に切りがないのでこの辺でやめておくが、興味を持った、導入したいということであれば、
Subversionダウンロードページ
TortoiseSVN及び日本語化ファイルダウンロードページ
上のページからSubversion、TortoiseSVN、TortoiseSVNの日本語化ファイルをダウンロードし、任意の場所にインストール、その後、
hiromasa.zone TortoiseSVN でファイルのバージョン管理をしてみる (2)
上記のページの記述を元に取り組んでみることをおすすめしたい。
私感であるが、「バージョンアップについていけない」とか「バージョンアップなんてしたくない」となってしまうのは、“自分でもなにをどうしたのか思い出せないぐらいカスタマイズしたファイルが、事もあろうにバージョンアップ対象ファイルになってしまった”というケースに頻繁に遭遇した結果、というパターンが多いと思う。
ファイルをカスタマイズした場合は、どのファイルのどこをどうカスタマイズしたのかすぐわかるようにしておいた方がいい。そうすれば新しいファイルに同様のカスタマイズを施すのも楽になり、アップデートを怖がらなくて済む。
[コラム]アップデートしたのに、バージョンナンバーが変わらない？ [Permalink]
新しいファイルを上書きして、モジュール管理画面でアップデートボタンを押したのに、なぜかバージョンナンバーが変わらない。あれ、もしかして古いファイルを上書きしたのかなと思って見てみるが、新しいファイルで間違いない。え、ということはちゃんとアップデートできていないの？ と、何度も上書き→アップデートを繰り返すがやっぱり変わらない。いったいどうして！？ こんな風な経験をした人も少なくないと思う。
バージョンナンバーはやはり気になる。
ほとんどの場合、モジュール作成者がモジュールのフォルダにあるxoops_version.phpというファイルに記載されているバージョンナンバーを書き換えなかったために起きるトラブル(と言うほど大したことじゃないけど)だ。そのまま放っておいても特に問題ないと思うが、どうしても気になるようだったら、xoops_version.phpにある、
$modversion['version'] =
以降に書かれたバージョンナンバーを自分で書き換えてアップデートしよう。
モジュールを実際に稼働させてみる [Permalink]
インストールしただけではモジュールは動かない [Permalink]
いろいろと脱線したが、とりあえずここまででモジュールのインストールが完了したということになる。
では、今すぐにでもモジュールが使えるのかというと、実はもう一つ、重要な作業を行わなければならない。それはモジュールの設定である。
多機能な家電製品――たとえばハードディスクレコーダー――は、「どういう環境にあって(チャンネル設定のために使用する地域に入力)」、「どう動いてほしいのか(保存する画質などを決める)」ということをきちんと設定しないとすべての能力を発揮できないが、XOOPSのモジュールも似たようなものである。モジュールのインストールが終了したというのは、家電製品ならば然るべき場所に置いてプラグを差し込んで通電した、ぐらいの段階なのだ。
ブログモジュールであれば「日常」とか「ペット」とか、投稿用のカテゴリを作らなければならないし、newbbなどのフォーラムモジュールでは、「Q&A」とか「雑談」という風にどういうテーマの投稿を受け付けるのか、やはりカテゴリを作らなければならない。
そして、そういった基礎的な設定が終わった後、そのモジュールにどのグループがアクセスできるのか、どのグループはアクセスできないのか、といった「アクセス権限」の割り振り、後に詳しく書くが、モジュールが排出する情報ブロックをサイトのどこに配置するのかというデザイン部分の設定も行う必要がある。これらの設定を行い、ようやくモジュールが稼働を始めるのである。使えるようになるまでまだやることがあるのかよとうんざりしてしまうかもしれないが、設定は順序立てればそう大変な作業ではない。最後の仕上げということで気合いを入れて行えばあっという間に終わる。では改めて順を追って“設定作業”を説明してみよう。
まず、稼働までに要する基本的な準備という部分で分けると、モジュールには4つの種類がある。
- その1 インストールすれば、とりあえず動かせるモジュール
細かいことを抜きにすればすぐにでも使えるというタイプだ。設定項目には一般的な数値などが既に入っており、改めて設定し直さなくても稼働させられる。weblogD3も実はこのタイプで、メインメニューに出てくる「うぇブログD3」というリンクをクリックし、「ブログ投稿」を選択すれば投稿フォームが出てくる。
weblogD3は予めカテゴリが一つ設定されているので、インストール終了後、メインメニューの「うぇブログD3→ブログ投稿」を選ぶことによって記事を書くことができる。
- その2 カテゴリを決めてやらないと先に進まないモジュール
newbb系のフォーラムモジュールがだいたい当てはまる。同じフォーラムモジュールでもXOOPS YYBBSのようなタイプは立食パーティのようなもので、場を用意したのでお好きにどうぞという感じなのだが、newbb系は企業面接会のような感じで、まずいくつかのテーマがあり、そのテーマ別に場を用意するという形になる。よって、設置するためには運営者が「どこでなにを話すのか」ということを決めなければならない。
d3forumのカテゴリー作成画面。
- その3 他サービスのデータを入力しないと駄目なモジュール
天気予報や地図、アマゾンなどのオンラインショップの商品画像の表示をするモジュールがあてはまる。最初からベーシックな設定がなされている場合もあるが、ほとんどの場合は、連携するサービスから固有のIDなどを取得し、それを入力して初めてまともに動く場合が多い。
他サーバとのデータのやりとりをする必要があるので、キャッシュフォルダが用意されている可能性が高いのも特徴だ。その場合、パーミッションを777、707にしないと動かない場合もある。
XP-Weatherの設定画面。特定サービスのライセンスキーなどを入力する必要がある。
- その4 他のモジュールと連動させる必要があるモジュール
あまり多くはないが存在している。内外のフィードを加工して表示させることができるD3Pipesはaltsys(0.55)がないとインストールすらできないし、XOOPS YYBBSはexFrameがないと動かない。ちょっと毛色の変わったところではX-Reviewというレビューモジュールは、他のモジュールのテンプレートと連動させる必要がある。この手のモジュールは準備段階を含めて、大抵の場合、トータルで敷居が高めなので、すぐに動かそうとあまり急がず、ゆっくりと時間をかけて設定を行った方がいいだろう。
使いたいモジュールがどのタイプに属するものなのかを見極めた上で、前準備を行おう。
モジュールを自分の使いやすいようにする「一般設定」 [Permalink]
準備が終わったら、いよいよ設定を行う。管理画面の左に並んでいる、インストールしたモジュールのアイコンをクリックすると、設定できる項目のリンクが表示される。どういう項目があるのかはモジュールによって違うが、ほぼどのモジュールにでもあるのが「一般設定」だ。
これはモジュールの基本的な動作を決める、言い換えるなら「モジュールを自分好みに動作させるための」非常に重要な設定部分であり、あらかじめ最大公約数的な設定がなされているとはいえ、必ず見ておいた方がいい。
weblogD3の一般設定画面。
weblogD3の一般設定では、
- 1ページ毎に表示するエントリ数
- RSSアイコンを表示するかどうか
- 更新Pingを送るかどうか
- 画像ファイルの保存先ディレクトリをどこにするか
- trackbackがあったらメール通知するかどうか
など、ブログとして基本的なものを含め、50を超える項目が存在している。設定の変更をする必要がない項目も数多くあるが、たとえば、日付の書式がデフォルトでは「Y/m/d(2007/08/26といった表示になる)」となっているものの、視覚障害者が使う音声ブラウザでは「/」が入っている数列を分数と解釈するため、ブラウザの使用者が日付とは思えない読み上げになってしまう。ということで、「Y-m-d」と設定し直す、といったこだわりポイントを見つけて、自分なりの設定をすべきだろう。
サイト作成自体が初めてで、こういった設定に慣れていなければ「一般設定」はあえてスルーしてもいいと思う。おそらく、使っているうちにあそこがああなっていれば、ここがこうだったらという部分が出てくるはずなので、もしそういう意識を抱いたら、改めてモジュールの一般設定を覗いて、設定でどうにかできるか確認してみよう。
サイトを鮮やかに彩る“ブロック”という仕組み [Permalink]
カテゴリ作成などの前準備、一般設定まで終わったとなると、モジュールを動かすための設定はほぼ終了といっていい。普通のレンタルブログなら、記事を書き始めることができるだろう。しかし、XOOPSにはレンタルブログにはない、二つの特徴があるので、この特長を生かす「設定」が必要になってくる。
二つの特徴とは、
- コンテンツであるモジュールが、インプットされた情報を加工して“ブロック”というものを排出する
- サイトにアクセスしてくるユーザは「ログインをする登録ユーザとログインをしないゲスト」に分かれる
である。
まず、XOOPS型CMS独特のものといえる“ブロック”について説明してみたい。
唐突ではあるが、皆さんが会社の社長だとする。部下に「とりあえず、これについて分析しておいて」と材料を渡せば、「こんな結果が出ました」といろんな資料が上がってくるだろう。XOOPSにあてはめると、部下がモジュールで資料がブロックということになる。
weblogD3であれば、まず記事を書く。するとコメントが付いたり、トラックバックが付いたりする。これらの「記事」「コメント」「トラックバック」などが、社長である皆さんがモジュールに渡す“材料”である。
部下であるモジュールはこれらの材料を受け取り、分析して、「最新のブログエントリ」「最近のブログのコメント」「最近のトラックバック」といった資料、つまりブロックを排出する。このブロックは文字通りブロック形式になっていて、サイトの好きな場所に置いていけるのだ。よって、
「『最新のブログエントリ』はもっともインパクトがあるコンテンツだからサイト中央の上部に置こう。『最近のブログのコメント』はちょっと目立つサイト右側の一番上、『最近のトラックバック』は自分が見る用って感じで、サイト左の一番下に置いておくか」
という割り振りが可能である。この割り振りは本当に自由で、インストールしたモジュールが排出するブロックをどこにどう置いてもいいのだ。自分のブログを右下に、付いたコメントをど真ん中に置いても構わない。それら操作の結果、2カラムのレイアウトが3カラムになっても、3カラムのレイアウトを1カラムになってもデザインは崩れない。しかも、もう少し後で詳しく書くが、設定はテンキーを1回叩き、マウスを2回ぐらいクリックするぐらいのもので、本当に簡単だ。
一つのモジュールは様々なブロックを排出する。どのブロックをどこに置くか、また表示するかしないかの判断はすべて作者に委ねられる
Movable TypeやWordPressといったブログツールでも、最新のコメントやトラックバックを並べることはできるだろうが、そのレイアウトを管理画面から自由にコントロールするというのは無理である。もしテンプレートが設定している「最新のコメント」「最新のトラックバック」の位置が気に入らないなら、テンプレートを直に編集しなければならない。また、2カラムなのが気に入らない、3カラムにしたいとなったらテンプレートの編集というよりも改造に近くなる。2カラムのテンプレートを使うのであれば、基本的には2カラムでしか運用できないのだ。
情報の表示位置を少ない労力で好きなように変更できるというのは、ブログツールにはない大きなXOOPSの長所だろう。
2カラムのレイアウト。メインメニューが左にある。これを右に移してみると……
このように3カラムになる。ブロックの位置はテンプレートに左右されないので自由自在だ。
もちろん、ブロックを表示するかしないかということも自由に決められるので、ものすごく簡潔なデザインのサイトを作ることも可能だ。
XOOPSで作られたサイトがよく「いかにもXOOPSっぽい」といわれるのはおそらくこのブロックのせいで、いろいろなブロックを積み重ねていく作業が楽しくてついつい置きすぎてしまい、結果的に、サイト全体がまるで積み木を重ねたようにブロックだらけになってしまうからであろう。
様々なモジュールのブロックが3カラムに敷き詰められたXOOPSのトップページ。
鍵を持つ人しか見られないコンテンツ――ログイン機能を活かしてアクセス権限を設定する [Permalink]
もう一つの特徴は、アクセスしてくるユーザがサイトにログインをする登録ユーザとログインをしないゲストに分かれるというものだ。
最初の方でも書いたが、XOOPSでは大まかにアクセスしてくるユーザを３つに分けることができる。まず自分(管理者)。次にメールアドレスを提示して認証を受けた人たち(登録ユーザ)。そして一般の読者(ゲスト)だ。XOOPSは、現在アクセスしているユーザがどのグループに属しているのかはっきりと把握しているので、モジュール本体及びブロックすべてに設定できるアクセス権限が100%有効になる。
アクセス権限の一例
たとえば、weblogD3で書いたブログ本文を
- 自分だけが見られる
- 自分と登録ユーザは見られるが、ゲストは見られない
- 自分とゲストは見られるが、登録ユーザは見られない
- 三者とも見られる
という風に設定できる。更に細かい割り振りも可能だ。
この特徴を活かすとどういうことができるのかというと、フォーラムモジュールに、
- 投稿された文章は、自分、登録ユーザ、ゲスト、みんな見られる
- だけど投稿できるのは、自分と登録ユーザだけ
と権限を設定すれば、バイアグラ販売サイトなどのURLを書き込みまくる外国からのスパム投稿を防ぐことができる。
ログインしたユーザしか入れないエリアにゲストが入ろうとすると、上のような表示が出てIDとパスワード、新規登録を促す画面に移動させられる。
ああいったスパム投稿は、外国人がいちいちブラウザを使ってアクセスしてきて用意されたテンプレを貼りつけているわけではなく、
bbsとかforumなんていう、いかにもフォーラムが置かれています、みたいなディレクトリを探し、
↓
見つけたら、フォーラムのスクリプトを探し、
↓
名前、メールアドレス、文章を貼りつけられそうなフォームを探し、
↓
あったら書き込んで、投稿ボタンっぽいものを探して押す
という動きをするようにプログラムされたロボットが勝手にやっているので、「投稿するにはログインしてください」とか「ユーザ登録してください」というフォーラム相手には無力である(最近はユーザ登録も自力でこなすロボットがいるが……)。だから、ログインしないと書き込めないというのは、スパムに対して非常に有効なのだ。
スパム投稿の一例。たった一日放置しただけでまったく管理されていない印象を与えてしまう。
更に、多くの人にユーザ登録されたいという前提があるなら、アクセス権限をユーザとの駆け引きに使うというのもありだろう。
たとえば、weblogD3の「最新ブログエントリ」ブロック、これはブログのタイトルを表示するブロックなのだが、このブロックへのアクセス権限を「登録ユーザでもゲストでもOK」という風にしたとする。
すると、当然のことながら、ログインしてようがしてまいが全員平等にブログのタイトルを見られるということになる。
ところが、weblogD3モジュール本体(ブログ本文)へのアクセス権限を「登録ユーザはOK、ゲストはNG」と設定すると、ログインしていないユーザはどういうブログが更新されたのか、それは「最新ブログエントリ」ブロックを見ることでわかるが、そのタイトルをクリックしても弾かれてしまうということになる。ようは、「ブログを読みたかったら登録してね」ということだ。
普通のサイトで同じことをするためには、.htaccessを使って該当ページにBasic認証をかけるというやり方もある。
Basic認証の画面。
だが、この方法だと、ログインできなければ、
というエラーが出てしまって慣れていない人は困惑してしまうし、なにより、見たい、書き込みたいという欲求を叶えるためには「管理人に直接メールを出してパスワードを請求する」ということをしなければならない。これはかなり敷居が高いといえるだろう。
XOOPSであれば、登録をうながすような画面が表示されるので、ユーザも「ああ、登録すれば読んだり書いたりできるんだな」とすぐわかるし、登録は自動なので敷居も直接請求よりはずっと低い。
アクセス権限をうまく設定すれば、運営者もユーザもお互いが必要以上に負担をかけず、サイト作成、そして閲覧を楽しめるのである。
2005年1月6日執筆 2008年1月20日加筆修正