リンク XOOPSをダウンロードしたい！ インストールについて知りたい！ モジュールについて知りたい！ テーマを探したい！ レンタルサーバーを探したい！
XOOPSデフォルトのモジュール管理部分の問題点 [Permalink]
ブロックとアクセス権限の話をしてきたが、ではどうやってそれらの設定を行えばいいのか。ここからは、その部分の説明をしていきたいと思う。
当然のことながら、XOOPSはブロックとアクセス権限の設定をするための機能を持っている。「ブロック管理」と「グループ管理」というものだ。管理画面からシステム管理のアイコンをクリックすることでリンクが表示される。それぞれ、
ブロック管理
モジュールが排出するブロックをページのどこに配置するかを設定する。
ブロック管理画面。
ブロック設定は、こんな風にサイト画面を縦横に区切って(縦のみ5列)考えるとわかりやすい。縦軸の1が左カラム、5が右カラムとなり、2と4はセンターカラムの左右、3はど真ん中、ということになる。もし、×マークのところ(センターカラムの左)にブロックを表示したいと思った場合は……
上のように設定すればよい。「表示サイド」が横軸ということになり左から2番目にチェック、並び順が縦軸ということになり「3」と入力だ。
グループ管理
モジュール本体やブロックにどのグループ(管理者、登録ユーザ、ゲスト)がアクセスできるのかを設定する。
グループ管理画面
ということを設定できる。
しかし、画像を見ればなんとなくわかるように、操作画面が煩雑で正直かなり使いにくい。また、ブロック管理では各々のページに表示できるブロックのリストをずらりと並べて「で、どれ表示すんの？」と聞いてくるので、プロセスがどうして冗長になってしまう。たとえば、TSUTAYAのアダルトコーナーへ行って柚木ティナのDVD を借りるとして、うる星やつらのコスプレがジャケットになっている「ティナだっちゃ☆」が、コスプレというジャンルに収納されていたら、ものすごく探しにくい。借りる人間の思考は、
「柚木ティナの」DVDを見たい
↓
パッケージ画像表示のためAmazonアフィリエイト使用。
が出発点であり、
「コスプレ物を」見たい
ではないからだ。
XOOPSのブロック表示も同じで、多少の例外はあるだろうが、ユーザの前提はきっと、
さっきインストールしたモジュールのこのブロックをトップページに表示したい
であり、
トップページに表示できるブロックの一覧を見て選びたい
↓
ではないだろう。
altsysでモジュール管理の負担を一気に軽減する [Permalink]
では、もう少し直感的に、表示したいブロックをぱっぱっと選ぶ方法はないのか？ そんなユーザの欲求に応えてくれるモジュールがある。altsysだ。
altsysの画面。
以前、XOOPSデフォルトのブロック及びグループ管理(アクセス権限の設定)の使いにくさを解消するため、blocksadminというモジュールがあった。blocksadminの管理システムをモジュール単体ごとに組み込めるようにしたmyblocksadminは今でも様々なモジュールで使われており、私もかなりお世話になった。
altsysはblocksadminの後継モジュールであり、モジュールのブロック管理、グループ管理に加え、テンプレートの管理も引き受ける、モジュールの外面部分を総合的に管理するものだ。
XOOPSデフォルトのブロック管理、グループ管理がページを基本としているのに対し、altsysはモジュールを基本としている。よって、「このモジュールのこのブロックはここに置きたい」「このモジュールのアクセス権限はこうしたい」という、管理者の要求に素速く応えることができる。
使い方だが、ブロック管理とグループ管理については「ブロック管理」という項目で一つにまとまっており、同一画面で管理できるようになっている。ブロックをどのページのどこに表示したいのか、どのグループがアクセスできるのかという設定はかなり直感的に操作できるのであまり説明は必要ないだろう。
altsysのアクセス権限設定画面。モジュールごとに用意されているので、別のモジュールのブロックと間違えるという心配がない。
モジュールの見た目をカスタマイズする「テンプレート管理」 [Permalink]
慣れないと戸惑いそうなのが「テンプレート管理」機能である。
ここでXOOPSにおけるテンプレートとはなにかということを簡単に説明しておこう。静的ファイルのみで構成された普通のサイトの場合、index.htmlに表示されているものはindex.htmlに書き込まれているものであり、表示されているものをカスタマイズしたいと思ったら、index.htmlをエディタなどで開いて編集してやればいい。ところがXOOPSのようにPHPで作られたサイトの場合、
a.html
b.html
c.html
と、複数のHTMLファイルを呼び出す形で、
index.php
が成立しているということが多い。よって、あるモジュールにアクセスしたとき、URLの最後がindex.phpになっていたとして、その画面の表示をカスタマイズしたいからといってモジュールフォルダにあるindex.phpをカスタマイズしても意味がないということが多々ある。
その場合、index.phpを構成しているa.html、b.html、c.htmlをあたらなければならないのだ。この、a、b、c、それぞれのHTMLファイルがテンプレートであり、テンプレートの編集を簡単に行うための機能がaltsysの「テンプレート管理」なのである。
管理という名前が付いているものの、実際は「テンプレート編集」と表した方が似つかわしいかもしれない。この機能を使うと、ハードディスクにあるテンプレートファイルをエディタで開き、カスタマイズしてFFFTPでサーバにアップロードという、編集の際の面倒な工程を踏まず、オンラインで編集し、反映させることができる。
編集画面の一例。下が実際に編集する画面、上が編集されたものを表示する画面である。青で「+」と書き込まれている部分は、デフォルトの状態からここが書き加えられましたという意味を表している。ちなみにデフォルトの状態からここが削除されましたというときは赤で「-」になる。
デフォルトのテンプレートとの差異を+(加筆)と-(削除)で表してくれるので、自分がどこをどう編集したのかすぐにわかる。また、テンプレートのコピーを作れるので、渾身のカスタマイズをしたのに、モジュールをアップデートしたらテンプレートも上書きされて綺麗さっぱり消えてしまうという悲劇も防げる。
コピーの作り方は画面を見ただけだとピンと来ないと思うので、ここで説明しておこう。まず、コピーを置く場所を作る必要があるので、altsysの「テンプレート管理」の一番下の左、「新規にテンプレートセットを作成する」で文字通り、テンプレートセットを作成する。ベース(どのテンプレートセットを基本とするかということ)は「空(ベースとするテンプレートセットはなしで、ただコピーしたテンプレートを置く場所だけ作る)」でいいだろう。セット名はなんでもいいのだが、ここではcustomとしておく。
テンプレート管理の一番下の左側にある
新規作成ボタンを押すと新たにテンプレートセット(ファイル)を置く場所ができる。空で作れば当然真っ白だ。ここに、デフォルトテンプレートを編集したもののコピーを置くという操作を行う。
編集したファイルはわかりやすいように背景が緑色になる
コピーしたいファイルにチェックを入れ、行先で「custom」を選び、コピー実行ボタンを押す。すると、あっさりと「custom」にコピーが置かれる。
左右の色が同じということは、ファイル自体も同じということだ
こうしておけば、モジュールの新バージョンをインストールすると同時にテンプレートファイルがデフォルトに戻ってしまったとしても、今度は「custom」から「default」にファイルをコピーしてやれば元に戻るということになる。
コピーをデフォルトに上書きするときは、コピーを作るときとは逆の感じで。行先をdefaultにしてコピー実行、つまり上書きしてやればいい
簡単に書くと、
悪い例
あるモジュールのテンプレートファイルhoge.htmlをaltsysにて編集した
↓
自分的に見た目がよくなって満足
↓
あるモジュールがバージョンアップしたので、普通にアップロードした
↓
当然、hoge.htmlも上書きされてしまった
↓
元のデザインに戻せなくなった
良い例
あるモジュールのテンプレートファイルhoge.htmlをaltsysにて編集した
↓
自分的に見た目がよくなって満足
↓
コピー用のテンプレートセット領域を作って、そこにカスタマイズしたhoge.htmlをコピーしておいた
↓
あるモジュールがバージョンアップしたので、普通にアップロードした
↓
当然、hoge.htmlも上書きされてしまった
↓
コピー用のテンプレートセット領域にバックアップしておいたカスタマイズ版hoge.htmlを、上書きされたデフォルトのhoge.htmlに更に上書きした
↓
デザインが無事元に戻り、すぐに平和な日々が訪れた
ということになる。
テンプレートのカスタマイズを行いたいが、どのファィルをいじればいいのかわからないというときは、「テンプレートの高度な操作」にある、「テンプレートを枠で囲う」が使える。
テンプレートの高度な操作を選ぶと出てくる画面。
これを選んで、一度、カスタマイズしたいブロックが表示されているページに戻ると、なんとすべてのブロックに、ブロックを作っているテンプレートの名前が表示される。あとは編集したいブロックのテンプレートファイル名をクリックして、好きにカスタマイズするだけだ。
ブロックを形成しているテンプレートファイルの名前が赤字で表示される。Editをクリックすると編集画面に飛ぶ。
さすがにカスタマイズに関してはマウスをクリックすればなにかができるというわけではなく、HTMLかCSSの知識がある程度必要になってくるが、その二つの知識があればaltsysは大きな力になってくれるだろう。
さあ、ここでやればモジュールの設定はすべて終わったということになる。その後のモジュールのインストールはこの作業(アップロード→インストール→設定)を繰り返すだけだ。最初は戸惑う部分が多いと思うが、慣れてくればルーチンワークとして簡単にできる。使いたいモジュールをインストールして、XOOPSならではのサイトを構築していってみよう。
ユーザを惹きつけるXOOPSデフォルトの機能に注目してみる [Permalink]
一般設定でサイトに自分ならではの個性と色をつける [Permalink]
モジュールのインストール及び各種設定が終われば、サイトはもう動き出したも同然である。あなたのサイトを入学間近の小学生だとすれば、帽子をかぶってランドセルを背負ったぐらいの段階までは来ている。が、大事なものがない。それは名札だ。今の段階で公開すると、サイト名はみんな同じになってしまう。XOOPSのシステムを通して、自分のサイトにとっておきの名前を付けてあげよう。同時に、どういう方向性でサイトを運営していくのか、誰でもユーザ登録できるようにするのかしないのかといったことから、未登録ユーザでもコメントを書き込めるようにしたとき、彼の名前を「ゲスト」にするのか「匿名」にするのか「名無しさん」にするのかという細かいことまで、あなたならではの色、個性、方向性を決めていこう。
細かいだなんていかにも面倒そうだなあと不安になっている人もいるかもしれないが、実際のところ、ほとんどはデフォルト(あらかじめ入力されているもの)で問題ない。デフォルトから変更したほうがいいだろうと考えられる場所をピックアップしていくので、まずはその部分の設定をしてみてほしい。
なお、この辺のサイトの根幹の設定項目(XOOPS Cube Legacy2.1では管理画面内の“互換モジュール”及び“ユーザモジュール”にある)のそれぞれの説明は当サイトにある「システム管理ぷちマニュアル」を参考にしてほしい。
では、管理画面の左上にある「SYSTEM ADMIN」と書かれたアイコンをクリックし、右に出てくるいくつかの項目から「一般設定」を選び、更に出てきた項目から「一般設定」の編集というところをクリックしてみよう(XOOPS Cube Legacy2.1では、左メニューの“互換モジュール”から“全般設定”)。右側にモジュールの設定と似たような、なにやらごちゃごちゃと書かれた項目がずらりと並ぶはずだ。
XOOPS 2.0.16a以前の設定画面。
XOOPS Cube Legacy2.1以降の設定画面。2.0.16aのものと比べると、行き方、名前は違うが基本的に同じだ。
上でも書いたが、デフォルトの設定でいい部分が多々あるので、すべてにおいて意味を解釈しようとしなくても大丈夫。まず以下の項目の設定だけ変更してほしい。
- サイト名
- サイト副題(空欄にしても可)
- themes/ ディレクトリからの自動アップデートを有効にする “いいえ”から“はい”に
- デバッグモードを有効にする “PHPデバグ”から“オフ”に
拍子抜けした人も多いだろうが、基本的にこの4つだけ。「サイト名」「サイト副題」の2つに関しては特に書くこともないだろう。3つめの「themes/ ディレクトリからの自動アップデートを有効にする」は“いいえ”のままだとテンプレートファイルになにをどう追加しても反映されないようになっているので、サイトのデザインを変えたいなあと思っているなら“はい”に、4つめの「デバッグモードを有効にする」が“PHPデバグ”のままだと、サイト下部にnoticeが表示されてしまうという見映えの問題(noticeに関しては当サイトのコラム 本体インストールまたはモジュールインストール後に出現する“Notice”について を参照のこと)があり、“オフ”にということだ。
もう一箇所設定すべきなのは、「SYSTEM ADMIN」と書かれたアイコンをクリック→一般設定の所にある「ユーザ情報設定」の部分(XOOPS Cube Legacy2.1では左メニューの“ユーザーモジュール”から“一般設定”)。上がサイト全体の設定だとすると、ここはユーザに関する設定の部分だ。
XOOPS 2.0.16a以前の設定画面。
XOOPS Cube Legacy2.1以降の設定画面。これもやはり、2.0.16aのものと比べると、行き方、名前は違うが基本的に同じだ。
正直なところ、「ここだけは変更しておけ」とか「ここはこうしておけ」という部分は一つもない。“運営者が目指すサイトの方向性”あるいは“運営者の性格”によって千差万別になってくる部分だからだ。
- ユーザ自身のEmailアドレス変更を許可する
- ユーザが自分自身のアカウントを削除できる
- 利用許諾文を表示する
などなど、まさに運営者次第の設定だといえる。「ユーザが勝手に登録したメールアドレスを変更できたら、架空のアドレスをにして荒らすかも……」とか「ユーザが自分でアカウントを削除できたら、暴れるだけ暴れて消えるかも……」とか「利用許諾文を表示しないとユーザに好き放題されるかも……」と心配する人――以前、サイトを荒らされた経験のある人――と、「俺は場所を提供するだけ。管理なんてしねえよ」という人とでは“はい”と“いいえ”の並びがまったく違うだろう。
なので、ここの部分に関してはシステム管理ぷちマニュアルを読みつつ、設定項目を一つ一つ確認して、自分がサイトをどう運営したいのか、ユーザの自由度を高めるか、それとも少し縛るのか、考えながら設定していってほしい。もちろん、最初はデフォルトの設定に任せて、人が集まるようになってデフォルトではちょっとまずいなという部分が出てきてから改めて設定してみるというのもありだ。
モジュールのインストール、設定に続き、XOOPSのシステムの設定が終わればもうサイトは一般公開していいレベルに達したといっていい。近しい人に声を掛けて試運転を始めてもいいだろうし、見た目などにこだわりがないのなら本格的な運用をしてもいいだろう。いろいろな人に使ってもらって、もし、自分だけでは気がつかなかった問題などが出てきたらこれまでに行ったモジュールの選択、設定、システムの設定を見直してサイトをチューニングしていってほしい。
利用者が秘密のやりとりを行える“プライベートメッセージ” [Permalink]
さて、ここまではXOOPSでサイトを“構築”していく流れを書いたが、ここから先はXOOPSでサイトを“運営”していくために知っておいた方がいいことを簡単に記していきたいと思う。
以前、XOOPSはファミコンのようなもので“カセット”にあたるモジュールがないとなにもできないというようなことを書いたが、実はXOOPS単体でも面白い機能、コミュニティサイトを運営する場合、あなたの手助けになるような機能が存在している。いくつか紹介していこう。
まず、一番始めに気づきやすい機能として「プライベートメッセージ(PM)」がある。インストールしてトップページを見ると、ユーザメニューの一番下に「受信箱」というリンクがあるのがわかると思う。
mixiのユーザだったらそれほど目新しくは思わないだろうが、XOOPSはサイト運営者を含むユーザ同士でメッセージのやりとりをすることができるのだ。もし、メッセージを送られてきたら、この受信箱をクリックすることで読むことができる。私が思うに、静的ファイルで構成されたサイトなら作ったことがあるという人にXOOPSを紹介する時、一番、感心するのがこの機能ではないだろうか。
自分のサイト内で、読者同士がメッセージのやりとりをする
というのは、普通、サイトを作るにあたって想像もしていないことであり、そんなことが実現してしまうというのは、作成者からすれば自分のサイトが特別な力を持ったようで気持ちがいいと思う。
ユーザ側、特にmixiのユーザでもある人からすると、「へえ、個人サイトでもこういうことできるんだね」ぐらいの感動しかなく、積極的に使おうとはあまり思わないかもしれないが、作者宛だったらEメールよりもなんとなく出しやすいし、なにより、メールアドレスを開示する必要がないため、フォーラムを通じて仲良くなった人にも気軽に私信を送れるというのは便利だ。また、自分宛のメッセージをサイト上で読めるということで、サイトの存在がより身近に感じられるだろう。また運営者であれば、管理画面のユーザ検索から最近ユーザ登録した人の一覧を出して、その人たちにPMでウェルカムメッセージを送信するという使い方もできる。
メッセージ送信画面。このフォーマットは掲示板と共通である。
メッセージを受け取った場合、その旨が画面に表示される。
開封すると、メッセージを読むことができる。フェレットの画像は「アバター」である。ユーザが好きな画像をアップロードして自分のプロフィールの一部として使うことができる。
この機能が他のXOOPSサイトでどれぐらい使われているのかよくわからないが、ブログにはない、独特の魅力を持つ、制作者にとってのキラーコンテンツの一つではないかと私は考えている。
なお、XOOPSデフォルトのプライベートメッセージ機能はポップアップしたウインドウを通して使わなければいけないなどいろいろと不便な部分があるので、もし、XOOPS Cube Legacyを使っているのならPM Moduleの導入をおすすめしたい。
フィードを吐かないコンテンツでも「イベント通知」で更新状況をお知らせ [Permalink]
プライベートメッセージほどは「お」と思う機能ではないかもしれないが、地味に活躍しそうな機能として「イベント通知機能」がある。名前の通り、“なにかが起きたら知らせてくれる”機能だ。
たとえば、ユーザが「フォーラムで新しい投稿があったときやブログで新しい文章がアップされたときにメールで知らせてね」と設定すると、そのイベントが発生したときに通知が届く。運営者がモジュールごとに機能を使うかどうか決められ、ブログを更新してもメールでは知らせたくないと思えば、機能自体を外すというのもありだが、特にこだわりがなければ、ブログ、フォーラムにはイベント機能を設定すると親切だろう。
イベント通知機能を使用するかどうか、どういったイベントを通知するのかということはモジュールの一般設定から決められる。
かなり前の方で書いたが、CGIやPHPで作られた掲示板にも似たような機能はある。しかし、通知は限られたユーザ(運営者と書いた人)にしか届かなかった。だが、XOOPSは全員がメールアドレスを登録しているので、まったくの第三者も逐一フォーラムの状況をチェックすることが可能になる。
d3forumにイベント通知を設定した例。
また、この機能は単に「便利だね」ということ以外にも、トラブルを防ぐということにも大きな効果を持っている。
運営者といえども、そう毎日毎日自分のサイトにログインして、書き込みをチェックできるわけではない。そうなってくるとフォーラムでユーザ同士がトラブルを起こしていたりしたとき、介入できずにトラブルを大きくしてしまう場合もある。また、ユーザからの質問や要望を無視してしまい、結果、ユーザを失うということもあり得る。
このようなケースを防ぐために、管理者自らイベント通知を設定(たとえば携帯に通知するように)しておいて、不測の事態にも対応できるようにしておくといいだろう。
メールマガジンの発行も可能な「ユーザ宛メール送信機能」 [Permalink]
XOOPSでサイトを作る目的はいろいろあると思うが、「ユーザを視覚化し、囲い込みたい」というのはそれほど少なくないと思う。囲い込むというのは言葉があまりよくないかもしれないが、たとえば、自分宣伝チラシを配るのに、駅に出入りするエスカレーターの前に立ってというのはいまいち効率が悪いので、広場で「すみませーん、私に興味がある人は集まっていただけませんか？」と手を挙げて、集まってくれた人に「今度、こんなものを作ったんですよ」と自分の作品を紹介すれば不特定多数の人に片っ端から声をかけるよりは反応がいいはずだし、トラブルが起きる確率も少ないはずだ。
そういう目的で活きてくる機能が「ユーザ宛メール送信機能」である。システム管理画面から「ユーザ宛にメール送信」というリンクをクリックし、「最終ログイン日時が○日前以上」や「登録日時が下記の日時よりも後」といった条件を決めていくと、該当ユーザに一斉にメール(PMで送ることも可能)を送信することができる。
XOOPS 2.0.16aのメッセージ送信画面。
つまり、最後にログインしたのが三カ月以上前のユーザに「今度、こんなことを始めるので、もしよかったらまたログインしてください」というメールを出したり、つい最近登録したユーザに「当サイトに登録していただいてありがとうございました(以下、サイトの使い方など)」といったメールやPMを出したりできるというわけだ。また、メール配信を希望しているユーザだけに定期的にメールマガジンを送るというのもありだろう。
XOOPS Cube Legacyではいろいろと便利になっていて、「メールジョブ」と機能にちゃんとした名前がつけられており、送信履歴を見ることができる。
メールジョブの送信メール確認画面。
この機能はうまく使えればかなり便利なのだが、送信するユーザの数とサーバによっては問題が生じるかもしれない。メール配信を希望しているユーザが10万人いるとして、その人たちにメールを送る運営者の労力は送信ボタンを一回押すということだけ。しかし、当然のことながら10万人いるということはメールを10万通送るということなので、「じゃあ送っておいて」と命令されたサーバはてんてこ舞い確実である。その上、携帯メールのノリで、「あ、付け足し(以下略)」なんてのを間を置かずに送信したら一気に20万通処理することになる。
ただでさえ、メールを大量送信する人間はスパマー(スパムをばらまく人)の疑いをかけられるわけで、この調子だと毎回数十万通だとすぐにサーバに不具合が出て、多分即日警告かアカウント停止だろう。数万通でも廉価なレンタルサーバであれば多分似たようなもので、数千でもエラーなしに全員に送りきれるかというとなんともいえない。
数百ユーザ宛(数百通)ぐらいだったら多分どのサーバでもエラーなくいけると思うが、何通送るにしろ、できるだけ、朝9時、昼の12時、夜11時といったネットが混雑している時間は避けたほうがいいだろう。
最後に、個人サイトがユーザを10万人集めることも、大量のユーザを抱え込む大企業サイトが廉価なレンタルサーバを使うことも考えづらいのでここに挙げた心配の大部分は杞憂だろうが、とにかくメールの大量送信には様々なリスクがあることを頭の片隅に入れておいてほしい。
XOOPSサイトに個性を持たせる第一歩――トップページのカスタマイズ [Permalink]
ブログが表示されるようになって、それなりに形になってきた。XOOPSというシステムに対しての興奮というか熱気のようなものがだんだんと落ち着いてくると、見た目が気になり始める。サイトのイメージがどうにも暗いのだ。始めの方でも書いたが、XOOPSのデフォルトテーマは暗い。そして、最初の頃は新鮮に感じるデザインも、XOOPSで作られているあちこちのサイトを見て回っているうちに、いかにもXOOPSだなと感じるようになってしまう。ツール臭いデザインとか、いろいろな言い方はあると思うが、XOOPSっぽさを感じさせてしまうのはやはり配色とブロックの存在だろう。
多分、世間一般の人が頭に思い描いている“XOOPSっぽい”サイトのイメージ。3カラムでブロックが敷き詰められているというのがポイントかもしれない。
ただ単にイメージを変えるためだけなら、気に入ったフリーのテンプレートを使うという方法が一番簡単だが、XOOPSっぽさを微塵も感じさせたくないとか、俺色に染めたいとか、以前やっていたサイトのトップページのデザインに近づけたいという場合は、スタイルシートとテンプレートに相当手を入れる必要がある。
XOOPSはスタイルシートでデザインされている部分が多く、スタイルシートを書き換えれば色はどうにでもできる。スタイルシートの書き方がわからない人は、GoogleやYahoo!で「スタイルシートの書き方」などの言葉で検索してみると、いずれ自分にあったスタイルシート講座サイトが見つかると思う。
以下、トップページのデザインを変更する場合。
/theme/default/ にあるstyle.cssをメモ帳などのエディタで開くと、アルファベットと数字がびっしりと敷き詰められている画面が表示される。
.item {border: 1px solid #cccccc;}
.itemHead {padding: 3px; background-color: #2F5376; color: #FFFFFF;}
.itemInfo {text-align: right; padding: 3px; background-color: #efefef}
.itemTitle a {font-size: 130%; font-weight: bold; font-variant: small-caps;
color: #ffffff; background-color: transparent;}
.itemPoster {font-size: 90%; font-style:italic;}
.itemPostDate {font-size: 90%; font-style:italic;}
.itemStats {font-size: 90%; font-style:italic;}
.itemBody {padding-left: 5px;}
.itemText {margin-top: 5px; margin-bottom: 5px; line-height: 1.5em;}
.itemText:first-letter {font-size: 133%; font-weight: bold;}
.itemFoot {text-align: right; padding: 3px; background-color: #efefef}
.itemAdminLink {font-size: 90%;}
.itemPermaLink {font-size: 90%;}
なにがなにやら区別がつかない画面を見ていると、ゲームショップでバイトをしていた時に、
美少女戦士セーラームーンが3本、
美少女戦士セーラームーンRが1本、
美少女戦士セーラームーンS こんどはパズルでおしおきよ！が4本、
美少女戦士セーラームーンS 場外乱闘！が1本、
美少女戦士セーラームーンS くるっくりんが2本、
美少女戦士セーラームーン アナザーストーリーが2本、
美少女戦士セーラームーンSS ふわふわパニックが1本、
と、頭がこんがらがった状態で棚卸しをしていた日々を思い出してしまうが、私事はどうでもいいとして、ポイントとなる箇所を挙げるなら、
body(全体の幅、背景色、文字色など)
table td(ブロック内の文字FONTの指定)
td#headerbanner(一番上の、ロゴがある辺り)
.itemHead(掲示板など、多くのブロックで小見出しを表示している部分)
td#leftcolumn div.blockTitle(左にあるメニュー部分のタイトル)
td#centercolumn(中央ブロックの中の文字の大きさ)
td#centerCcolumn legend.blockTitle(中央ブロックの内枠。外枠はtheme_blockcenter_c.htmlにある<legend>を削除すれば消える)
大雑把にこの辺だろうか。特にtd#headerbannerの部分はもっともXOOPSをアピールしている所なので、XOOPSっぽさを消したいという時にはstyle.cssと同じフォルダにあるtheme.htmlをいじってバナーを外し、背景色をいったん白(#ffffff)にしてみるといろいろなイメージが湧いてくると思う。
ここで注意しておきたいのは、theme.htmlなどのテンプレートファイルに日本語を直接書き込む時は、EUCが扱えるエディタ(メモ帳は駄目)を使い、EUCで保存するということ。いろいろな文字コードを扱えるエディタであっても、なにも設定しなければ、ShiftJISで保存してしまう可能性が高い。XOOPSは文字をEUCで表示するので、ShiftJISで書かれた日本語を挿入してしまうとその部分だけ文字化けしてしまうということになる。
そしてもう一つ、theme.htmlをいじる場合、システム設定から一般設定に入り、「themes/ ディレクトリからの自動アップデートを有効にする」というところを「はい」にしておくこと。
ここが「いいえ」になっていると、テンプレートをいじってもなにも変わらない。
最後に一言だけ添えておくならば、XOOPSのデザインを俺色に染め上げるというのは、かなりの労力を強いられる。しかも、手を入れた箇所が多ければ多いほどバージョンアップ時に地獄を見る可能性が高くなる。
譲れるところは黙って譲る、譲れないところだけ手を入れる、このぐらいの大らかな心で取り組まないといずれウンザリしてしまうかもしれない。
[コラム]カスタマイズする際の注意点など [Permalink]
EUCで保存する
本文の方でも書いたが、テーマに日本語を書き込んで保存し、それをアップしたとき、書き込んだ部分だけ文字化けしてしまうのは、metaタグで、
<meta http-equiv="content-type" content="text/html; charset=EUC-JP" />
と、ブラウザにEUCで表示するようにお願いしているのに、実際の文字コードはShiftJISなので、ブラウザが混乱してしまったというケースが多い。
たとえるなら、「俺、彼女と別れると思う」と言って女性の気を惹いた男が、次の週、別れると言っていたはずの恋人と三泊四日の沖縄旅行に出かけてしまい、残された女性が混乱しているようなものである。人間でさえ言っていることとやっていることが違う人に遭遇すればわけがわからなくなってしまうのだから、コンピュータならなおさらだ。文字コードは確実に合わせること。
普段は閉じないタグを閉じる
XOOPSのテーマは、最初に「俺、XHTMLで書かれてますから」と言っているので、タグをXHTMLのルールで書く必要がある。ホームページビルダーで作る場合、マークアップ言語の初期設定は「HTML 4.01 Transitional」というものだが、「XHTML」の書式は「HTML 4.01 Transitional」の書式といろいろな部分で違う。
デフォルトテーマに書き込む可能性のあるタグでは、<br>と<img> この二つの書き方が微妙に違う。「XHTML」では「/」を用いて閉じなければならない。
<br>
↓
<br />
<img src="～～～.jpg" alt="">
↓
<img src="～～～.jpg" alt="" />
実は閉じなくてもブラウザでは普通に表示されるのだが、未来のブラウザが厳格にルールを適用してきた場合、表示されなくなるかもしれないし、将来のウェブサイトは「XHTML」で記述されるケースが多くなってくるだろうから、今のうちに慣れておく方がいいだろう。
例のおまじないを書き込んでみる
EUCで書かれたHTMLのヘッド部分に、謎の単語、あるいは文章が書かれていることがある。
たとえば、Yahoo! JAPANのトップページのソースを見てみると、
<!--京-->
こんなものが書かれている。詳しく説明すると長くなるので割愛するが、これは、別にサイト自体にはおかしな部分はないのにどういうわけか文字化けしてしまうという場合の文字化け回避方法の一つであり、書き込んでも意味がないとか単なる迷信とかいろいろ言われているものの、このような文字列を挟むことで実際に文字化けが解消したケースを目撃したことがあり、なかなか侮れない。
有名どころでは、他に<!-- 美乳 -->とか<!-- 雀の往来 -->、<!-- 有朋自遠方来 -->がある。うちのサイトは全ページの<head>のちょい下辺りに<!-- 雀の往来 -->を挟み込んでいる。時間に余裕があれば是非。
[コラム]XOOPSの言い回しを自分好みにカスタマイズしてみる(簡易なテンプレートハック方法) [Permalink]
デザインを自分好みに変更できたとして、次に気になるのはXOOPSが紡ぎ出す数々の文面ではないだろうか。たとえば、「パスワード紛失」というリンクをクリックすると、
という枠が出てくるが、すべてのサイトにおいて、ここにある言い回しが妥当ということはまずない。仮に、「自分のお小遣いでサーバーを借りて、主に学校の友人がアクセスするファッションをテーマにしたXOOPSのサイトを運営」という女子中学生がいたとして、彼女からすれば、“パスワードを紛失されましたか？”とか“ご心配なく”という言い回しはちょっと堅いだろう。もうちょっと、普段自分たちが書いているような言葉にならないだろうかと思っても不思議はない。
こんなとき、どのファイルを開いて書き直せばいいのか。PHPファイルはバケツリレーのような感じであっちこっちからパーツを引っ張ってくることが多く、開いているファイルがindex.phpで、そこに「こんにちは」と書かれてあったとしても、index.php自体に「こんにちは」と書かれているとは限らない。
膨大なファイル群から該当ファイルを探す一番簡単な方法は、自分のハードディスク内にあるサイトのミラー(＝バックアップ。レンタルサーバにアップロードしてある構成とまったく同じもの)から文章置換ソフトなどを用いて片っ端から検索することだ。スマートではないが、話としては一番早い。
私は『Devas』というソフトを愛用している。使い方は非常に簡単で、仮に「パスワード紛失」の「ご心配なく」を「心配なぃょ☆」にしたい場合、
該当文字列が含まれているファイルがありそうな場所を指定(思い浮かばなかったらルートから)
どの種類のファイルを検索するかを設定(htm、html、php、tpl辺り)
検索文字列「ご心配なく」を入力し、検索ボタンを押す
見つかったら「置換文字列」に「心配なぃょ☆」を入力して置換ボタンをクリック
該当ファイルをアップロード(上書き)後、無事に変更される
でＯＫ。文章だけではなく、ここの<b>を<strong>にしたいとか、HTMLを変更したい場合に該当場所を探すのにも非常に役に立つ。文章置換ソフトは、XOOPSを思い通りにカスタマイズするため、どのファイルのどこら辺を書き換えればいいのかという“当たりをつける”ユーティリティとして、パソコンにインストールしても決して無駄にはならないだろう。
データベースにあるデータのバックアップと復元 [Permalink]
トップページのカスタマイズまで済めば、XOOPSで構築したサイトを立ち上げるという段階(初級編)はほぼ終了ということになるが、一応最後、MySQLに格納された文字データのバックアップの方法を書いておきたいと思う。
私はこれまで、サーバのハードディスクがクラッシュしてサイトのデータを全部失ったという事故に遭った経験は幸いにもない。が、家のパソコンのハードディスクがクラッシュしたことは3回ある。そのうち1回は前兆現象がまったくない状態でいきなり壊れたため、本家サイト更新停止時に読者の皆さんから送られた「お疲れさまでした」という慰労のメールがほぼすべて消失した。
このような悲惨な出来事がレンタルサーバでも起こりうる可能性は誰にも否定できないし、現実に存在する。特に安価でレンタルできるサーバはコストの問題でバックアップを取っていない可能性が高く、クラッシュが起きたとき、客商売だから復旧に全力を尽くしてくれるとは思うが、「ごめん、駄目でした」で終わる可能性もある。XOOPSでサイトを構築する場合、文字データをブラウザから書き込むため、自身のハードディスクにはまったくデータが残っていないことが多く、「ごめん、駄目でした」という言葉は本当に駄目ということを意味するので定期的にバックアップを取っておきたい。
始めの方にも書いたが、XOOPSのデータはHTMLファイル、画像ファイル、CGI(掲示板などのデータ)と違い、基本的にデータベース(MySQL)に入っている。
完全にバックアップするためにはデータベースのデータも落とさなければならないが(言い換えると、データベースのデータがなければサイトの復元はできないということ)、FFFTPのようなクライアントソフトはデータベースの中身を取り出すということはできないので、バックアップしたいときは別のツールを使うことになる。
もっとも簡単にデータベースのデータをバックアップできるツールは、XOOPSではやはりモジュールということになる。バックアップ専用モジュール(後述)もあるが、もともとインストールされている可能性が高い「Xoops Protector」にもバックアップ機能が付いているので、簡単にバックアップ方法を説明しておこう。
まず、XOOPSの管理メニューより「protector」を選択し、「PREFIX マネージャ」をクリックする。
すると上のような画面が出てくる。一番右の項目に「ACTION」という項目が存在するので、この下にある「backup」ボタンをクリック。すると「***_*****(ここは人によって異なる).sql」といった感じの名前のデータベースのデータファイルをダウンロードすることができる。
Firefoxでのダウンロード画面。
非常に簡単な作業なのでサイトの更新ペースなどを考慮に入れて、一日一回、あるいは週一、月一ごとにバックアップしておくといいだろう。ちなみにこのファイルはテキストエディタで開くことができる。興味のある人は一度見てみるのもいいと思う。
では、バックアップしたデータを戻したいときはどうすればいいのか。たとえばサーバを移転したとき、前の環境とまったく同じにするにはどうすればいいのだろうか。ここで紹介したいのは、一般的なレンタルサーバにおいて、データベースのデータの管理を行うツールとして必ずといっていいほどインストールされている『phpMyAdmin』というソフトだ。一応、phpMyAdminのみでバックアップ、及び再構築を行う手順を書いておきたいと思う。
初期画面は例によってなにを意味しているのかわからない言葉の羅列で、初めて見たときは圧倒されるかもしれないが、バックアップの手順はそれほど難しいものではないので、機械的に覚えてしまおう。
phpMyAdminの初期画面。もし英語で表示されたらLanguageで日本語(Japanese ja-euc)を選ぼう。
1. まず、左のフレームからバックアップしたいデータベースの名前を選ぶ。データベースなんてXOOPSでしか使っていないということであれば、一つしかないので簡単。
2. 右のフレームに出てきた『エクスポート』というところをクリック。
黒く塗りつぶしている部分はデータベースのユーザ名。
3. DBのダンプ(スキーマ)表示という項目の左下の『エクスポート』のところにある、『全選択』をクリックする。
SQLオプションは初期設定でいいかも。
4. 右フレーム下にある『ファイルで保存する』にチェックを入れ、右下にある実行ボタンをクリックする。
実行ボタンが隠れているが、この右下にある。
5. *****(データベースのユーザ名).sqlという名前と共に、「このファイルを保存しますか？」と出てくるので、保存をクリック。
一見すると複雑な画面で頭がくらくらするが、バックアップの手順はこれだけなので、恐れることなくこまめにバックアップしよう。
復元の方法は更に簡単で、バックアップの手順の1同様、データベースの名前を選んでから、右のフレームに出てきたメニューバーで、今度は『SQL』をクリック。
「テキストファイルの場所」というところで、参照ボタンを押し、バックアップしてあった「*****.sql」を選択して、実行ボタンをクリック。これだけ。しばらくの間、うんともすんとも表示されずにし～んとしているので、本当に大丈夫かと不安になるが、やがてデータがすべて展開される。以上の方法は、Xoops Protectorでバックアップしたデータの復元にも対応している。
すぐには展開されないので、パニックを起こしてブラウザを閉じたりはしないように。
XOOPSを構築するのは自分だが、実際に運用するのは比較的経験の浅い人で、phpMyAdminなどの専門的ツールは触らせたくない、でもバックアップの取り方と再構築はできるようにしておきたいというような理由があるのなら、バックアップ専用モジュールを使うといいだろう。代表的なモジュールとしては『MyX_BackUp』『Bluemoon XOOPS Backup/Restore』などが挙げられる。
MyX_BackUp ダウンロードページ
Taq's xoops laboratory(トップページ)
Bluemoon XOOPS Backup/Restore ダウンロードページ
bluemoon.XOOPS(c)(トップページ)
これらのモジュールはデータベースのデータのバックアップと復元を単体でこなせるので、操作方法を教えるのもphpMyAdminの説明よりはずっと簡単なはずだ。
[コラム]PREFIXマネージャの使い方 [Permalink]
せっかくデータベースのことを書いたので、ついでと言ってはなんだが、わりと謎扱いされている、『Xoops Protector』の機能の一つである『PREFIXマネージャ』の使い方について記しておきたい。
XOOPS本体のインストール時、PREFIXをXOOPSのままで行って(なんのことを言っているのかわからないということであれば、ほぼ間違いなく該当している)、その後、XOOPS
Procterをインストールしてセキュリティガイドという項目をクリックすると、
'XOOPS_DB_PREFIX' : xoops 非推奨
という表示がされるはず。いったい、なにが非推奨なのか、どうすればokに変わるのか戸惑っている人が多いと思う。
XOOPSのデータは、すべて接頭語(PREFIX)を付けられてデータベースの格納されている。たとえば、アバターについてのデータがしまわれている場所は、
xoops_avatar
こんな風に名付けられている。xoopsの部分がPREFIXだ。で、PREFIXがxoopsであること、つまりデフォルトの状態だとなにがまずいのかと言えば、攻撃者がどのデータがどういう名前の場所にしまわれているのかわかってしまうということである。もし、アバターに関するデータをどうにかしたいと思ったら、『xoops_avatar』という部分に的を絞ればいいと調べなくてもわかるわけだから、攻撃者にとってこんなに楽なことは、逆に言えば運営者にとってこんなに危険なことはない。
だが、PREFIXの部分を変更してあれば、攻撃者は管理者権限を乗っ取りでもしない限りは(乗っ取られたらどういう対策をしてあっても無駄だけど)、アバターのデータがどこにあるのかわからなくなる。よって、セキュリティのためにPREFIXを変更しておくのは有効なのだ。
『PREFIX マネージャ』というのは、PREFIXを簡単に変更できるもので、『copy』に任意の接頭語を入れて、copyボタンをクリックし、あとはその下にあるようにmainfile.phpの記述を書き換えて上書きアップロードして、PREFIXがxoopsのデータをdeleteボタンで削除するだけ。
とにかく手軽に書き換えられるので、xoopsという接頭語に特にこだわりがないのならさくっと変更してしまおう。
おわりに [Permalink]
長々と書いたが、XOOPSができることを100とすると、多分、1も伝え切れていないように思う。というか、はっきり言ってまだ導入部分も終わっていない。改めて底が深いなぁと感心してしまった。
XOOPSに限らず、CMSというのは使う人が無限の可能性を引き出せる素晴らしいツール。この文章を読んだ人が「へえ、こんなことができるんだ」と思って、CMSを使い、いろいろな人を幸せにしてくれるサイトを作ってくれたら感激である。
この後は、XOOPSで構築したサイトを“使える”ようにするために「XOOPS Cube Legacy カスタマイズ 文系出張所」でお会いしましょう。
2005年1月6日執筆 2008年10月22日加筆修正