スタッフブログ
HD1.0.3のリリース準備やら、OSC2009 Tokyo/Springの準備やらで、オーバーフロー気味なgusagiです
（来週のセミナーの準備をしている弊社のRyujiやhaltの方がもっと忙しいと思いますが^^;）
さて、今日のタイトルですが、何を今更と思われる方も多いかも知れません。
実は、今日の終業後、弊社のなおとやargonと携帯モジュールにこれから必要な機能って何だろう、という話をしていました。
その際に、「確かに、それは必要かも」という機能から「それって、自分としては使わないんだけど、本当に必要？」と思う機能まで、色々とアイデアを貰ったのですが、その際にふと思ったことが「自分がサービスを作る立場だったら、どんな機能が欲しいか」というものでした。
実は、RYUSに入社する前後から、あるサービスのアイデアをプライベートで練っていたりするのですが、その開発にXOOPS CubeとWizMobileの組み合わせを用いてみようと思っていたりします。
サービスを自分で作って運用してみることで、開発者としての目線だけでは思いつくことが出来ないアイデアが浮かべば、と期待していたりします。
もちろん、そこで開発した機能はWizMobileにも反映させて行くつもりですが、「それだったら、こんなサービス作れるの？」などといった関心のある方は、機会がありましたら声をおかけ下さい
（来週のセミナーの準備をしている弊社のRyujiやhaltの方がもっと忙しいと思いますが^^;）
さて、今日のタイトルですが、何を今更と思われる方も多いかも知れません。
実は、今日の終業後、弊社のなおとやargonと携帯モジュールにこれから必要な機能って何だろう、という話をしていました。
その際に、「確かに、それは必要かも」という機能から「それって、自分としては使わないんだけど、本当に必要？」と思う機能まで、色々とアイデアを貰ったのですが、その際にふと思ったことが「自分がサービスを作る立場だったら、どんな機能が欲しいか」というものでした。
実は、RYUSに入社する前後から、あるサービスのアイデアをプライベートで練っていたりするのですが、その開発にXOOPS CubeとWizMobileの組み合わせを用いてみようと思っていたりします。
サービスを自分で作って運用してみることで、開発者としての目線だけでは思いつくことが出来ないアイデアが浮かべば、と期待していたりします。
もちろん、そこで開発した機能はWizMobileにも反映させて行くつもりですが、「それだったら、こんなサービス作れるの？」などといった関心のある方は、機会がありましたら声をおかけ下さい
こんにちわ、なおとです。
今日の話題は、よく使う bulletin（ニュース）モジュールの問題点を修正したことについてです。
問題の状況
- Windows環境で作成したDBのデータをUNIX環境に持って行った場合
- windowsでXOOPSを運用していると、この現象は顕在化しない
- ルート側のdirnameに大文字を混在させてインストール/利用している
- テーブル名は小文字で作られる
- しかしテーブル名にアクセスするとき、〜$xoopsDB->prefix($mydirname.'_topics')〜というコードでテーブル名をつくってクエリを生成している
- $mydirnameには大文字が含まれていて、内部的にはそのテーブル名は存在しない、というエラーが起こる
影響を受けるバージョン（調べた部分のみ）
- bulletinHD 2.16（PEAK配布バージョン）
- bulletinHD（HD1.0.2 以前）
- bulletinを元にした派生版
解決方法
prefix()を呼んでいる箇所を全てチェックし、必要に応じてstrtolower()を挟む
他の解決方法も検討しましたが、今回は上記対応を行いました。
修正用の差分ファイル
bulletin テーブル名不正規問題修正パッチ （ダウンロード）
2008.12.26 13:40 追記：この現象は、 Windows環境で作成したDBのデータをUNIX環境に持って行った場合に限定されます。
通常の環境の場合、上記の差分ファイルパッチを当てると、逆に動作しなくなります。
ただ、WARPなどの環境でデータを作成してから、UNIX環境にデータを移行して運用なんてケースも考えられるので、その場合は上記パッチを適用して頂いた方が良いと思われます。
XOOPS の携帯対応についてよくご相談をうけます。
実際に WizMobile を導入して携帯から利用してみると、細かなところで気になるところがでてきたりするものです。
そんな気になるところの一つが、ログインフォームなどでユーザ名やパスワードを入れるときに、テキスト入力フォームへの入力モードがデフォルトだと全角文字入力になってしまうことです。
できたら、最初から半角英数の入力モードになっていて欲しいですよね。
携帯での入力モードの指定ですが、デフォルトで半角英数にするときは、次のように input タグの属性を指定すると良いそうです。
なので、XOOPS のログインフォームのテンプレートをこのような形に修正してやればできそうな気がするのですが、ログインフォームのテンプレートを見ると次のようになっていて、istyle や format という属性を追加しても、出力される HTML では、この属性が削除されてしまいます。
これを下記のように書き換えてもダメなんですね。
何故かというと、 xoops_input プラグインのコードを見ると、xoops_input プラグインは特定の属性だけを HTML に出力するようになっているようで、プラグイン呼び出し時に想定外の属性をつけても無視されるようになっているからです。
istyle や format, MODE というのは想定外の属性になっちゃうんですね。
# 余談ですが、これはサンデープログラマがうっかりテンプレート上で XSS を作り込まないためにこうなってたんだと思います。
さて、そこで xoops_input プラグインをちょっといじって、指定された属性（ほんとうはプラグインに渡すパラメータですが）を全て出力するように書き換えてみました。
・ パラメータ全部出力型 function.xoops_input.php
これを XOOPS_ROOT_PATH/class/smarty/plugins/function.xoops_input.php と入れ替えても良いですし、ホダ塾ディストリビューション「HD」でしたら、XOOPS_TRUST_PATH/libs/smartyplugins/ に置いても OK です。
これで、先ほどのように istyle,format, MODE の属性を追加すれば、携帯でユーザ名やパスワードを入力しようとしたときに、デフォルトで半角英数の入力モードになります。
WizMobile をご利用の方は、是非おためしください。
実際に WizMobile を導入して携帯から利用してみると、細かなところで気になるところがでてきたりするものです。
そんな気になるところの一つが、ログインフォームなどでユーザ名やパスワードを入れるときに、テキスト入力フォームへの入力モードがデフォルトだと全角文字入力になってしまうことです。
できたら、最初から半角英数の入力モードになっていて欲しいですよね。
携帯での入力モードの指定ですが、デフォルトで半角英数にするときは、次のように input タグの属性を指定すると良いそうです。
<input type="text" name="pass" istyle="3" format="*x" MODE="alphabet" />
なので、XOOPS のログインフォームのテンプレートをこのような形に修正してやればできそうな気がするのですが、ログインフォームのテンプレートを見ると次のようになっていて、istyle や format という属性を追加しても、出力される HTML では、この属性が削除されてしまいます。
<!-- こんなふうに input タグを使わないで Smarty プラグインで input タグを出力しています -->
<{xoops_input type=password name=pass size=12 maxlength=32
id="`$smarty.const.XOOPS_INPUT_DEFID_PREFIX`block_pass"}>
<{xoops_input type=password name=pass size=12 maxlength=32
id="`$smarty.const.XOOPS_INPUT_DEFID_PREFIX`block_pass"
istyle="3" format="*x" MODE="alphabet"}>
何故かというと、 xoops_input プラグインのコードを見ると、xoops_input プラグインは特定の属性だけを HTML に出力するようになっているようで、プラグイン呼び出し時に想定外の属性をつけても無視されるようになっているからです。
istyle や format, MODE というのは想定外の属性になっちゃうんですね。
# 余談ですが、これはサンデープログラマがうっかりテンプレート上で XSS を作り込まないためにこうなってたんだと思います。
さて、そこで xoops_input プラグインをちょっといじって、指定された属性（ほんとうはプラグインに渡すパラメータですが）を全て出力するように書き換えてみました。
・ パラメータ全部出力型 function.xoops_input.php
これを XOOPS_ROOT_PATH/class/smarty/plugins/function.xoops_input.php と入れ替えても良いですし、ホダ塾ディストリビューション「HD」でしたら、XOOPS_TRUST_PATH/libs/smartyplugins/ に置いても OK です。
これで、先ほどのように istyle,format, MODE の属性を追加すれば、携帯でユーザ名やパスワードを入力しようとしたときに、デフォルトで半角英数の入力モードになります。
WizMobile をご利用の方は、是非おためしください。
こんばんは。
プライベート携帯を最新機種に変更してウハウハのgusagiです
今日は、XOOPS Cubeで構築したコーポレートサイトの携帯対応について書かせて頂きます。
『ケータイ白書 2009』によれば、企業のモバイルサイトは、「開設数」「PCサイト開設済み企業のモバイル版開設比率」ともに昨年より増加しているそうです。
実際、携帯の3G化やパケット定額制の導入、Googleを始めとするモバイル検索の一般化に伴い、公式以外でもモバイルサイトの認知度は格段にあがってきています。
しかし、モバイルサイト開設に対しては、
XOOPS(XOOPS Cube)の場合、コンテンツの更新などは管理画面から行うことが出来るので、PC用のコーポレートサイトとして導入されている企業も多いと思います。
このXOOPSの利点をモバイルサイトにも活かしたサンプルを兼ねて、RYUSのサイトを携帯にも対応させました。
これで、[お知らせ]や[スタッフblog]など、RYUSサイトのコンテンツを携帯でも見て頂くことができます。
興味を持って頂けましたら、画面左に表示されているQRコードを利用して、携帯電話でもご確認下さい
携帯対応モジュールをインストールして、ヘッダ部分の画像を差し替えるなど、モバイル用のテーマを若干編集して頂ければ、XOOPS Cubeで構築したサイトのモバイル版となります。
なお、RYUSでは、XOOPS Cubeで構築したサイトの携帯対応や、携帯にも対応したサイトの新規構築なども行っています。
モジュールの導入だけでなく、オリジナルテーマの作成やテンプレートカスタマイズも含めて対応可能ですので、宜しければRYUSにご連絡下さい
プライベート携帯を最新機種に変更してウハウハのgusagiです
今日は、XOOPS Cubeで構築したコーポレートサイトの携帯対応について書かせて頂きます。
『ケータイ白書 2009』によれば、企業のモバイルサイトは、「開設数」「PCサイト開設済み企業のモバイル版開設比率」ともに昨年より増加しているそうです。
実際、携帯の3G化やパケット定額制の導入、Googleを始めとするモバイル検索の一般化に伴い、公式以外でもモバイルサイトの認知度は格段にあがってきています。
しかし、モバイルサイト開設に対しては、
- 専任の担当者がいない（専任にする余裕がない）
- PC版とモバイル版の個別更新が煩雑である
XOOPS(XOOPS Cube)の場合、コンテンツの更新などは管理画面から行うことが出来るので、PC用のコーポレートサイトとして導入されている企業も多いと思います。
このXOOPSの利点をモバイルサイトにも活かしたサンプルを兼ねて、RYUSのサイトを携帯にも対応させました。
これで、[お知らせ]や[スタッフblog]など、RYUSサイトのコンテンツを携帯でも見て頂くことができます。
興味を持って頂けましたら、画面左に表示されているQRコードを利用して、携帯電話でもご確認下さい
携帯対応モジュールをインストールして、ヘッダ部分の画像を差し替えるなど、モバイル用のテーマを若干編集して頂ければ、XOOPS Cubeで構築したサイトのモバイル版となります。
なお、RYUSでは、XOOPS Cubeで構築したサイトの携帯対応や、携帯にも対応したサイトの新規構築なども行っています。
モジュールの導入だけでなく、オリジナルテーマの作成やテンプレートカスタマイズも含めて対応可能ですので、宜しければRYUSにご連絡下さい
XOOPS Cubeオフィシャルサイトのメニューに「開発」という項目がありますが、ご覧になったことはありますか？
この「開発」に、最近の開発についてのトピックがコンパクトにまとまっています。
・開発 - XOOPS Cube
この記事をかいた時点で
・XOOPS Cube Legacy 2.2 の開発で、FCKEditorの組み込みをxpWikiのnao-ponさんが担当されてる
・XOOPS Cube コアの1.0の開発もしている
・XOOPS Cube Legacyとは別のベースモジュールの開発もしている
というような状況がわかります。
あと、開発ページにあるリンク先を見てるうちに気がついたのですが、なんとXOOPS Cube Projectに日本語のフォーラムがありました！
・XOOPS Cube オフィシャルサイト日本語フォーラム
これまでも、XOOPS Cube Project外では日本語でディスカッション出来る場があったのですが、XOOPS Cube Project 内で日本語でやりとりできるフォーラムができてたのは、私にとっては非常に嬉しいことです。
私自身、英語の壁に苦しんで、PostNukeからXOOPSに移行した人間だったので、英語中心のXOOPS Cube Project って、きつかったんです(^^;
というわけで、早速XOOPS Cube Project の日本語フォーラムの投稿をメールで受け取るようにしました。
あ、フォーラムがあるといっても、ユーザサポートフォーラムじゃないですよ。開発のためのフォーラムですからね。
XOOPS Cube Project に何か貢献したいと思ってたのに、英語はちょっとなって感じで躊躇してた方は、是非 日本語フォーラムに参加して、あなたにできることをやってみましょう！
この「開発」に、最近の開発についてのトピックがコンパクトにまとまっています。
・開発 - XOOPS Cube
この記事をかいた時点で
・XOOPS Cube Legacy 2.2 の開発で、FCKEditorの組み込みをxpWikiのnao-ponさんが担当されてる
・XOOPS Cube コアの1.0の開発もしている
・XOOPS Cube Legacyとは別のベースモジュールの開発もしている
というような状況がわかります。
あと、開発ページにあるリンク先を見てるうちに気がついたのですが、なんとXOOPS Cube Projectに日本語のフォーラムがありました！
・XOOPS Cube オフィシャルサイト日本語フォーラム
これまでも、XOOPS Cube Project外では日本語でディスカッション出来る場があったのですが、XOOPS Cube Project 内で日本語でやりとりできるフォーラムができてたのは、私にとっては非常に嬉しいことです。
私自身、英語の壁に苦しんで、PostNukeからXOOPSに移行した人間だったので、英語中心のXOOPS Cube Project って、きつかったんです(^^;
というわけで、早速XOOPS Cube Project の日本語フォーラムの投稿をメールで受け取るようにしました。
あ、フォーラムがあるといっても、ユーザサポートフォーラムじゃないですよ。開発のためのフォーラムですからね。
XOOPS Cube Project に何か貢献したいと思ってたのに、英語はちょっとなって感じで躊躇してた方は、是非 日本語フォーラムに参加して、あなたにできることをやってみましょう！
先日、当社haltがこのBLOGに書いた WARP ですが、誰でも簡単にWebアプリケーションを試せるだけでなく、Web屋さん、システム屋さんにとっては、実際に動いてクライアントさんにどんな感じで使えるのかを体験してもらえる、「動く提案書」としての使い方もあります。
動く提案書の作り方ですが、例えば XOOPS Cube でのサイト構築を提案するとしたら、
Step1．WARPをダウンロード
WARPのダウンロードページに、XOOPS Cube Legacy 2.1.6インストール済みのパッケージ（WARP_XC216_20081124.zip）がありますので、これをダウンロードするとよいでしょう。
・WARPダウンロード
Step2．モジュールのインストールと設定
提案予定のモジュールを別途ダウンロードしてきて、WARP上の XOOPS Cube にインストールしましょう。
モジュールを選ぶときは、先日このBLOGに書いた「XOOPSモジュールを選ぶときの3つのポイント＋1」も参考にしてください。
モジュールをインストールしたら、実験的にサイトをつくる気持ちで、設定を行ったり、ダミーの記事も登録しちゃいます。
Step3．WARPを圧縮しなおす
ある程度クライアントさんに見てもらえる程度までできあがったら、WARPのフォルダを圧縮しましょう。
インストールするモジュールにもよりますが、圧縮しても数十Mバイトのファイルになると思います。
Step4．クライアントに渡す
圧縮してもファイルサイズが非常に大きいので、メールに添付はやめましょうね。
宅ファイル便で送るなど、どこからかダウンロードしてもらうか、USBメモリやCD-Rにコピーして渡しましょう。
クライアントさんに渡したファイルをクライアントさんのところで、解凍してもらい、あなたがWARPを起動したときと同様にServer_start.batをダブルクリックしてもらえば、Step3で圧縮する直前と同じサイトをクライアントさんも見ることが出来ます。
これで、実際にあれこれ試せる、触れる、動く提案書をお客さんに見せることが可能です。
ちなみに、RYUSで作成した WARP with XOOPS Cube for Corporateも、この手順で作成しています。
動く提案書の作り方ですが、例えば XOOPS Cube でのサイト構築を提案するとしたら、
Step1．WARPをダウンロード
WARPのダウンロードページに、XOOPS Cube Legacy 2.1.6インストール済みのパッケージ（WARP_XC216_20081124.zip）がありますので、これをダウンロードするとよいでしょう。
・WARPダウンロード
Step2．モジュールのインストールと設定
提案予定のモジュールを別途ダウンロードしてきて、WARP上の XOOPS Cube にインストールしましょう。
モジュールを選ぶときは、先日このBLOGに書いた「XOOPSモジュールを選ぶときの3つのポイント＋1」も参考にしてください。
モジュールをインストールしたら、実験的にサイトをつくる気持ちで、設定を行ったり、ダミーの記事も登録しちゃいます。
Step3．WARPを圧縮しなおす
ある程度クライアントさんに見てもらえる程度までできあがったら、WARPのフォルダを圧縮しましょう。
インストールするモジュールにもよりますが、圧縮しても数十Mバイトのファイルになると思います。
Step4．クライアントに渡す
圧縮してもファイルサイズが非常に大きいので、メールに添付はやめましょうね。
宅ファイル便で送るなど、どこからかダウンロードしてもらうか、USBメモリやCD-Rにコピーして渡しましょう。
クライアントさんに渡したファイルをクライアントさんのところで、解凍してもらい、あなたがWARPを起動したときと同様にServer_start.batをダブルクリックしてもらえば、Step3で圧縮する直前と同じサイトをクライアントさんも見ることが出来ます。
これで、実際にあれこれ試せる、触れる、動く提案書をお客さんに見せることが可能です。
ちなみに、RYUSで作成した WARP with XOOPS Cube for Corporateも、この手順で作成しています。
argonです。
今回はXOOPSの簡単にできるTipsについて書いてみようと思います。
[内容]
ユーザーメニューブロックにユーザのアバターを表示させる。
[効用]
SNS風な感じにログインしていることが一目でわかりよりパーソナライズ
されたCMSを雰囲気を演出できる。
管理者や開発社は複数のアカウントを使用している人もどのアカウントで
ログインしているか一目でわかって便利。
[やり方]
テンプレートファイルを編集します。
編集するテンプレートは互換モジュールのlegacy_block_usermenu.html
になります。このにファイルにアバターを表示するために1行追加します。
以下の例ですと4行目になります。
(必要な部分だけ抜粋。実際のテンプレートファイルはもうちょっと長いです)
以上のように1行追加するだけで作業は簡単です。
ですが、わりと実用的なTipsではないかなと思います。
ブログのタイトルで「その1」としましたが、持ちネタが少ないので、次に何か良いネタが
できたら「その2」を書こうと思いますので、よろしくお願いします。
[謝辞]
suinさん貴重なアドバイスありがとうございました。
今回はXOOPSの簡単にできるTipsについて書いてみようと思います。
[内容]
ユーザーメニューブロックにユーザのアバターを表示させる。
[効用]
SNS風な感じにログインしていることが一目でわかりよりパーソナライズ
されたCMSを雰囲気を演出できる。
管理者や開発社は複数のアカウントを使用している人もどのアカウントで
ログインしているか一目でわかって便利。
[やり方]
テンプレートファイルを編集します。
編集するテンプレートは互換モジュールのlegacy_block_usermenu.html
になります。このにファイルにアバターを表示するために1行追加します。
以下の例ですと4行目になります。
<table cellspacing="0">
<tr>
<td id="usermenu">
<img src="<{$block.uid|xoops_user_avatarize}>" />
<a class="menuTop" href="<{$xoops_url}>/user.php">
(必要な部分だけ抜粋。実際のテンプレートファイルはもうちょっと長いです)
以上のように1行追加するだけで作業は簡単です。
ですが、わりと実用的なTipsではないかなと思います。
ブログのタイトルで「その1」としましたが、持ちネタが少ないので、次に何か良いネタが
できたら「その2」を書こうと思いますので、よろしくお願いします。
[謝辞]
suinさん貴重なアドバイスありがとうございました。
satoです。
弊社では、CubeCakeという、CakePHPでXOOPS開発ができるモジュールを配布しております。
CakePHPの手軽さをモジュール開発にそのまま利用できる便利なものではあるのですが、いくつか癖がありますので、そのあたりを紹介したいと思います。
（その１ と書いてありますが、その２があるかは未定です）
・ユーザ認証
CakePHP側のACLは使うのが難しいと思います。
手軽なのは、controllers/app_controller.phpに
のようなのを用意しておくと、手軽に利用できると思います。
同様に、app_controller.phpやapp_model.phpに、XOOPSでよく使うものを組み込んでおくだけでかなり楽になります。（xoops_redirectとか）
・シェルから叩く場合
CakePHPには、vendors/shellsに、Shellクラスを継承したクラスを置くことで、シェルから叩くプログラム（バッチ処理など）を簡単に作れる機構が存在します。
しかし、これを普通にCakePHPの方法で実行すると、CakePHPだけで完結しようとしてしまうため、XOOPSの各種設定が読み込まれずにいろいろ問題が起きます。（DBの情報を取得できない等）
この場合、以下のコードをvendors/shellsに置くスクリプトの先頭に記述すると綺麗（？）にXOOPSを初期化してくれます。
（もう少しスマートな書き方にできると思うので、整備して後日本体に反映したいと思います）
---
紹介できる内容が用意できたらまた紹介したいと思います。
まだいくつか問題がありますが、便利なので是非試してみてください。
弊社では、CubeCakeという、CakePHPでXOOPS開発ができるモジュールを配布しております。
CakePHPの手軽さをモジュール開発にそのまま利用できる便利なものではあるのですが、いくつか癖がありますので、そのあたりを紹介したいと思います。
（その１ と書いてありますが、その２があるかは未定です）
・ユーザ認証
CakePHP側のACLは使うのが難しいと思います。
手軽なのは、controllers/app_controller.phpに
protected function getUser()
{
global $xoopsUser;
return $xoopsUser;
}
のようなのを用意しておくと、手軽に利用できると思います。
同様に、app_controller.phpやapp_model.phpに、XOOPSでよく使うものを組み込んでおくだけでかなり楽になります。（xoops_redirectとか）
・シェルから叩く場合
CakePHPには、vendors/shellsに、Shellクラスを継承したクラスを置くことで、シェルから叩くプログラム（バッチ処理など）を簡単に作れる機構が存在します。
しかし、これを普通にCakePHPの方法で実行すると、CakePHPだけで完結しようとしてしまうため、XOOPSの各種設定が読み込まれずにいろいろ問題が起きます。（DBの情報を取得できない等）
この場合、以下のコードをvendors/shellsに置くスクリプトの先頭に記述すると綺麗（？）にXOOPSを初期化してくれます。
（もう少しスマートな書き方にできると思うので、整備して後日本体に反映したいと思います）
if (!isset($_SERVER['REMOTE_ADDR'])) {
$_SERVER['REMOTE_ADDR'] = '127.0.0.1';
}
if (!isset($_SERVER['REQUEST_METHOD'])) {
$_SERVER['REQUEST_METHOD'] = 'GET';
}
$xoopsOption = array();
$xoopsOption['nocommon'] = true;
require_once(APP.'../../mainfile.php');
if (!isset($_SERVER['REQUEST_URI'])) {
$_SERVER['REQUEST_URI'] = XOOPS_URL.'/modules/cubecake/';
}
require_once XOOPS_ROOT_PATH . "/include/functions.php";
require_once XOOPS_ROOT_PATH . "/class/xoopsobject.php";
$root=&XCube_Root::getSingleton();
if(!is_object($root->mController)) exit();
$root->mController->_setupFilterChain();
$root->mController->_processFilter();
$root->mController->_setupErrorHandler();
$root->mController->_setupEnvironment();
$root->mController->_setupLogger();
$root->mController->_setupDB();
$root->mController->_setupLanguage();
$root->mController->_setupTextFilter();
$root->mController->_setupConfig();
$root->mController->_setupDebugger();
$root->mController->_processPreBlockFilter();
//$root->mController->_setupSession();
//$root->mController->_setupUser();
$root->mController->setupModuleContext();
$root->mController->_processModule();
$root->mController->_processPostFilter();
---
紹介できる内容が用意できたらまた紹介したいと思います。
まだいくつか問題がありますが、便利なので是非試してみてください。
XOOPSによるサイト構築のお手伝いをこれまでにいくつもやらせてもらいました。
XOOPSでサイト構築する際につきものなのが、どのモジュールを利用するかという、モジュール選びです。
私なりに、こんな基準で選んでるというのを今日は書いてみたいと思います。
■1．開発された方が、セキュリティ面に気をつかっているか？
PHPプログラムは、セキュリティについての知識無しでつくると、簡単にセキュリティホールだらけのプログラムができてしまいます。
XOOPSで利用するモジュールにセキュリティホールがあると、攻撃されたときに、被害はそのモジュールだけにとどまらず、XOOPSサイト全体、サーバ全体にまで被害がひろがることがあります。
だから、開発された方自身が、セキュリティ面に気をつかっているかどうかも、モジュールを選択するときに評価するようにしています。
これはXOOPSコミュニティを観察するとか、モジュールの更新履歴にセキュリティホール修正についての記述がちゃんと記載されてるかなどで判断出来ると思います。
■2．長期間更新がとまっているようなことはないか？
XOOPSは、PHPスクリプトですが、PHPはバージョンアップしたときに、下位バージョンとの互換性のない変更がされることがちょくちょくあります。
長期間更新がとまっているモジュールだと、最近のPHP環境で動かそうとしたときに、なんらかの不具合が発生することがあります。ここでハマらないように、数年更新がとまってるようなモジュールは避けるようにしています。
■3．良く使われているモジュールか？
多くのサイトで使われているモジュールほど、早く不具合発見→修正のサイクルが早くまわりますので、使ってみたときに何かのバグではまってしまうということが少なくなります。
また、何かわからないことがでてきても、利用者が多いモジュールの場合、検索してみると解決方法が見つかることが多くて助かります。
これも各XOOPSコミュニティサイトで、使ってみようかなと思うモジュール名の投稿を検索してみると、利用者が多いか少ないかある程度判断できるかと思います。
最後に。。。
RYUSでは、既存のモジュールをカスタマイズすることも多いのですが、カスタマイズをするときは上記3点にくわえて
■4．多機能過ぎないか？
というのも考慮するようにしています。
多機能なモジュールは、プログラムを改造しなくても、かなり幅広いニーズに応えてくれるので非常に便利です。
しかし、どうしてもプログラム改造が必要になったときは、多機能ゆえに、ほんのちょっとだけ改造したいだけなのに、あちこちに手をいれるはめになりやすいので、避けるようにしています。
これ、XOOPSモジュールのハック（改造のことですよ）にチャレンジしたことがある方なら、よくわかると思います(^^;
多機能なモジュールは、モジュールの管理画面で設定できることが非常に多かったり、モジュールのファイルサイズをみたときに、他のモジュールと比較してあきらかにファイルサイズが大きかったりするので、このあたりをみてカスタマイズするかどうか判断すると良いかと思います。
XOOPSでサイト構築する際につきものなのが、どのモジュールを利用するかという、モジュール選びです。
私なりに、こんな基準で選んでるというのを今日は書いてみたいと思います。
■1．開発された方が、セキュリティ面に気をつかっているか？
PHPプログラムは、セキュリティについての知識無しでつくると、簡単にセキュリティホールだらけのプログラムができてしまいます。
XOOPSで利用するモジュールにセキュリティホールがあると、攻撃されたときに、被害はそのモジュールだけにとどまらず、XOOPSサイト全体、サーバ全体にまで被害がひろがることがあります。
だから、開発された方自身が、セキュリティ面に気をつかっているかどうかも、モジュールを選択するときに評価するようにしています。
これはXOOPSコミュニティを観察するとか、モジュールの更新履歴にセキュリティホール修正についての記述がちゃんと記載されてるかなどで判断出来ると思います。
■2．長期間更新がとまっているようなことはないか？
XOOPSは、PHPスクリプトですが、PHPはバージョンアップしたときに、下位バージョンとの互換性のない変更がされることがちょくちょくあります。
長期間更新がとまっているモジュールだと、最近のPHP環境で動かそうとしたときに、なんらかの不具合が発生することがあります。ここでハマらないように、数年更新がとまってるようなモジュールは避けるようにしています。
■3．良く使われているモジュールか？
多くのサイトで使われているモジュールほど、早く不具合発見→修正のサイクルが早くまわりますので、使ってみたときに何かのバグではまってしまうということが少なくなります。
また、何かわからないことがでてきても、利用者が多いモジュールの場合、検索してみると解決方法が見つかることが多くて助かります。
これも各XOOPSコミュニティサイトで、使ってみようかなと思うモジュール名の投稿を検索してみると、利用者が多いか少ないかある程度判断できるかと思います。
最後に。。。
RYUSでは、既存のモジュールをカスタマイズすることも多いのですが、カスタマイズをするときは上記3点にくわえて
■4．多機能過ぎないか？
というのも考慮するようにしています。
多機能なモジュールは、プログラムを改造しなくても、かなり幅広いニーズに応えてくれるので非常に便利です。
しかし、どうしてもプログラム改造が必要になったときは、多機能ゆえに、ほんのちょっとだけ改造したいだけなのに、あちこちに手をいれるはめになりやすいので、避けるようにしています。
これ、XOOPSモジュールのハック（改造のことですよ）にチャレンジしたことがある方なら、よくわかると思います(^^;
多機能なモジュールは、モジュールの管理画面で設定できることが非常に多かったり、モジュールのファイルサイズをみたときに、他のモジュールと比較してあきらかにファイルサイズが大きかったりするので、このあたりをみてカスタマイズするかどうか判断すると良いかと思います。
ときおり、リアルで話を聞いたりすると XOOPS Cube に対して、ビジネス的にあーしたらいいとか、こーしたらいいなんて意見をお聞きすることがあるのですが、XOOPS Cube でモジュールを作成したりテーマを作成して公開されてて居る方たちの多くは、ホビー、fun! の気持ちで楽しいからやっているのであって、ビジネス的な意義を見いだしてやっているわけではありません。
XOOPSは、楽しんで作ったものが公開されて、それが結果的にビジネスでつくられた CMS （ライセンス料だけでうん百万とかってCMSですね）にも対抗できるソフトウェアになっただけなんですね。
これって、面白いとおもいませんか？
XOOPSは、もともとモジュールやテーマデザインをつくるうえで、「必ずこうしなきゃいけない」とか「こういうやり方でないとXOOPSの流儀にあわない」というのが無い、比較的自由になんでもやれるオープンソースCMSだったので、多くの人が気軽に「作る人」になれたオープンソースでした。
この「自由になんでもやれる」ことが、XOOPS普及の原動力にもなったと思ってます。
XOOPSから派生した、XOOPS Cube プロジェクトでは、この「自由」「楽しむ」という部分がXOOPSプロジェクトよりも強くなってます。
自由に楽しみながらつくっているソフトウェアなので、ビジネス的な視点でみたときに、「あー！なんで、モジュールごとに操作感が微妙に違うんじゃ！」とか「こうしてくれたら、もっとお客さんにすすめやすいのに」とか思うこともあると思います。
でも、ビジネス上でそういうところが気になるなら、ビジネスでXOOPSに関わる会社（RYUSもそうですし、XOOPSを利用されてる企業さんも）にがんばってもらって、XOOPS Cubeの世界は、今のまま自由であってほしいと思ってます。
そのために、XOOPS Cube に対するビジネス的な要求は、RYUSを含めXOOPSをビジネスに利用しているところが受け止めるような形にしていきたいなっておもってます。
XOOPSは、楽しんで作ったものが公開されて、それが結果的にビジネスでつくられた CMS （ライセンス料だけでうん百万とかってCMSですね）にも対抗できるソフトウェアになっただけなんですね。
これって、面白いとおもいませんか？
XOOPSは、もともとモジュールやテーマデザインをつくるうえで、「必ずこうしなきゃいけない」とか「こういうやり方でないとXOOPSの流儀にあわない」というのが無い、比較的自由になんでもやれるオープンソースCMSだったので、多くの人が気軽に「作る人」になれたオープンソースでした。
この「自由になんでもやれる」ことが、XOOPS普及の原動力にもなったと思ってます。
XOOPSから派生した、XOOPS Cube プロジェクトでは、この「自由」「楽しむ」という部分がXOOPSプロジェクトよりも強くなってます。
自由に楽しみながらつくっているソフトウェアなので、ビジネス的な視点でみたときに、「あー！なんで、モジュールごとに操作感が微妙に違うんじゃ！」とか「こうしてくれたら、もっとお客さんにすすめやすいのに」とか思うこともあると思います。
でも、ビジネス上でそういうところが気になるなら、ビジネスでXOOPSに関わる会社（RYUSもそうですし、XOOPSを利用されてる企業さんも）にがんばってもらって、XOOPS Cubeの世界は、今のまま自由であってほしいと思ってます。
そのために、XOOPS Cube に対するビジネス的な要求は、RYUSを含めXOOPSをビジネスに利用しているところが受け止めるような形にしていきたいなっておもってます。
