XOOPSのモジュールには要注意

というわけで、なぜかXOOPSネタです。

仕事でやっているからですね。わかりやすいです。

同窓会ネタでも書こうかと思いましたが、見つかると微妙になりやすいので書きません。

XOOPS系すべてに当てはまる大変な問題

XOOPS本家以外にもXOOPS CubeやImpressCMSも対象になる話です。

というよりもXOOPS以外でも同様の問題が出る可能性が大きい話ですが。

その現象とは「そもそもモジュールが正しくインストールできない、モジュールが正しく動作しない」という致命的な物です。

特にレンタルサーバーでやっていると訳がわからなくなる現象の一つです。私の場合は実験用のさくらのレンタルサーバーでもやっちゃっている現象です。

内部テスト用のサーバーでも起こっていますし。XOOPSモジュールの実装段階でもちょっと気をつけたことの一つです。

MySQLを対象としたモジュールすべてで起こってしまう大変な現象です。

つまり、XOOPSのモジュールなどでインストールしようとすると、テーブル種類を「ENGINE=」ではなく「TYPE=」で記述しているためにテーブル種別をMySQLに受け入れてもらえず、テーブルが作成できない、という物です。

単にモジュールのインストールなどでインストールできない程度ならいいのですが、XOOPSのバックアップモジュールであるBackPackではこれがもろに決まってバックアップしたSQLをリストアしようとすると復旧に失敗してデータベースが空っぽになるという大変なことが起こります。

データベースが空っぽになるとさすがのXOOPSでも動かないですからね。画面が真っ白です。

復旧するときにはバックアップされたSQLデータを一度SQL文を出して置換を行った上でデータベース上に直接展開するしかないと思います。

XOOPSのモジュールの場合は、SQL文があるならモジュールのtrustpath内にsqlというディレクトリがあり、その中に使用するSQLファイルがありますので先に置換してしまうといいと思います。

なお、置換するときにはエディタに要注意で、UTF-8を使うときにはBOMが残らないようにしないとインストール時に別のエラーが発生することがあります。

エディタでの保存時にBOMを消すか、FTPソフトでBOMが残らないように変換して転送するかどちらかでがんばる必要があります。

なお、BackPackの場合ですが、モジュールの修正でこの現象をなんとかする方法があります。

patchコマンドで当てられるようにしようかと思いましたが、それだとほとんどの人が当てられない(linux系の動作をしないような環境でやっているだろうし)と思いましたので作成しませんでした。

必要なようでしたら後でコメントか何かに書きます。

仕事でやっているのにそういう疑問を言ってはいけないと思います・・・。