PHP: 2010年12月アーカイブ

いや、まあ、もう「汎用データベースモジュール」は使わないことにしたので、どうでも良いっちゃ良いんだけど、この間"GDモジュールが「画像の読み書きをサポートしてない」と言われるのだが"というエントリーに書いたように、PHP でちゃんと gd モジュールのセットアップをしても、

gdモジュールがGIF/JPEG/PNG画像の読み書きをサポートしていません。このモジュールで画像を処理するには、gdモジュールがGIF/JPEG/PNG画像の読み書きをサポートする必要があります。

と「汎用データベースモジュール」の管理画面で怒られちゃう件。

今日、たまたまソースを見てみると、このエラーを出しているところは、admin/index.php の

    if (!$gd_infos['GIF Read Support'] || !$gd_infos['GIF Create Support'] || !$gd_infos['JPG Support'] || !$gd_infos['PNG Support']) {
        $errors[] = constant('_AM_' . $affix . '_GD_NOT_SUPPORTED_ERR');
    }

この部分だった。

「JPG Support」なんて添字の gd 情報をチェックしているよ。
それは、古いバージョンの PHP が戻してくる値でしょうが。今のバージョンだと、「JPEG Support」って項目名なんすけど。

こんなしょうもないことのために、どれだけ PHP の再インストールをしたことか(^^;。俺の貴重な時間を返せ。（ま、その時、自分の PHP のインストール手順ではなく、すぐにソースを疑えばよかったんだけどね(^^;）

つーことで、「坊主憎けりゃ袈裟まで憎い」ではないが、ますます XOOPS が嫌いになった俺なのであった。

いやぁ、ちょっとハマって無駄な時間を過ごした。(^^;

例えば、db_user と db_shop というディレクトリ名で、XOOPS 汎用データベースモジュールを元にした外部モジュールをアップしてインストールをしようとすると、どちらの外部モジュールも一覧に同じ名前で表示されてしまうのだ。

modinfo.php の中で、db_user は「ユーザ検索」、db_shop は「お店検索」と名前を付けているのに、どちらも「ユーザ検索」と表示されてしまう・・・という具合だ。

結局、問題なのは db_user と db_shop というディレクトリ名であった。

XOOPS 汎用データベースモジュールは、ディレクトリ名を変えれば複数設置出来るようになっているのだが、そのため、モジュール名に添字（affix）を付けてモジュールを区別出来るようにしているみたい。

その添字の作り方が

$affix = strtoupper(strlen($dirname) >= 3 ? substr($dirname, 0, 3) : $dirname);

という具合にディレクトリ名の頭 3文字だけを取っているのが問題のようである。

ということで、db1_user、db2_shop のように先頭 3文字を抜いても問題の無いディレクトリ名にしてやれば問題ないのであった。

なんか、もう、いちいちこういう細かい仕様で引っかかって、全然本来の開発のところにたどり付けんな。

複数のプログラマ仲間が「今更 XOOPS？PHP のバージョンアップにもまともに対応出来てないのに？XOOPS に手を出すなんて 3～4年遅いよ。」と言うてたのは本当だな。今更 XOOPS なのである(^^;

う～む・・・お手上げだ。(^^;

うちのテスト用サーバで、XOOPS Cube Legacy の外部モジュール

汎用データベースモジュール
http://xoopscube.jp/module/413

の検証をしようと思ったんだけど、インストールを終えて管理画面を開くと、

gdモジュールがGIF/JPEG/PNG画像の読み書きをサポートしていません。このモジュールで画像を処理するには、gdモジュールがGIF/JPEG/PNG画像の読み書きをサポートする必要があります。

なんてエラー（？）が出ちゃう。う～ん？

確かに、phpinfo() で見てみると、

という具合に gd の情報に JPEG Support enabled が出ていない。

どうも、PHP のバグなのか、configure する時に、--with-gd オプションを最後に指定しないと駄目らしい。

./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-mbstring --enable-zend-multibyte --with-pgsql --with-mysql --with-gd -with-jpeg-dir=/usr/local/lib --with-zlib --with-png-dir=/usr/local --with-zlib-dir

という具合に configure していたんだが、

./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-mbstring --enable-zend-multibyte --with-pgsql --with-mysql -with-jpeg-dir=/usr/local/lib --with-zlib --with-png-dir=/usr/local --with-zlib-dir --with-gd

みたいにしないと駄目なようである。

確かに、これで configure し直して make すると、ちゃんと JPEG Support enabled が表示されるようになった。

今回使っている PHP のバージョンは 5.3.3。少なくとも、5.2.11 の時には、

./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-mbstring --with-mysql --with-gd --with-zlib --with-jpeg-dir --with-pdo-mysql

のように --with-gd が前の方にあっても問題なく JPEG が使えた。

PHP のバージョンアップをずっと追いかけているわけではないのでわかんないのだが、どっかの段階で --with-gd より前に -with-jpeg-dir を置かないといけなくなったということだよな？

ま、何か気持ち悪いが、JPEG もこれで使えるようになった。

さぁ、GIF も JPEG も PNG も全部サポートよぉ～！と汎用データベースモジュールの管理画面を開くと、

gdモジュールがGIF/JPEG/PNG画像の読み書きをサポートしていません。このモジュールで画像を処理するには、gdモジュールがGIF/JPEG/PNG画像の読み書きをサポートする必要があります。

なんだ、これ。わけわからん。お手上げだ。

なんか、こんなことを繰り返してて、全然 XOOPS の検証が終わらん。
XOOPS なんか使わずに、素直に CGI とかで組んでサイト作った方が今回の案件は確実に早いよなあ。
ま、ユーザのご指名なので、XOOPS Cube Legacy を使うしかないのだが・・・

「お手軽」と言われるシステムは、いざ「動かん」という時の調査／対応がほんと大変なのだ・・・

おっ。General Settings（全般設定）で Default language（使用言語）を japanese に、Debug mode（デバッグモードを有効にする）を Off（オフ）に設定したら、ちゃんと画面が日本語表示になって、画面下部に大量に出ていた

Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file modules/legacy/preload/InstallerChecker.class.php line 32

といったメッセージも出なくなった。

インストール中に日本語画面から英語画面に切り替わってしまったのは、ワーニングがぼろぼろ出ていた状態で、実は正しく設定が保存されていなかっただけってことなのか。（どうやら設定の問題だけだったようでよかった）

最初に、php.ini の display_errors を Off にしてからインストールを開始するようにしたほうがよさげじゃね。

ちなみに、よく見たら、

Powered by XOOPS Cube Legacy 2.1.8© 2001-2006 XOOPS Cube Project

って表示されてるな・・・
XOOPS Cube Legacy って 2006年から更新されてないの？
お客さんがコレ使うって言うからインストールしてみたんだけど・・・
このご時世に、4年も更新されてないものを使うのは怖いんですけど？？？

＜追記＞

2.1.8 が出たのが 2010年3月27日のようだ。よかった。:-)

取りあえず、XOOPS Cube Legacy のインストールは終了したのだが、ログイン画面でも、画面の下の方に、

Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file modules/legacy/preload/InstallerChecker.class.php line 32
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file modules/legacy/preload/ThemeSelect.class.php line 32
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file modules/legacyRender/preload/Cacheclear.class.php line 26
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file modules/legacyRender/preload/Cacheclear.class.php line 29
Unknown Condition [8192]: Assigning the return value of new by reference is deprecated in file modules/pm/preload/Preload.class.php line 10

みたいなメッセージが延々表示されていやな感じ。
こりゃ、何なのかね？エラーでもワーニングでもないようだが。

で、どうも、悪いのは XOOPS Cube Legacy のようだ。
ググってみると、「PHP 5.3 対応ができてないやんけ！」という情報がぽろぽろヒットした。う～む・・・もうバージョンは 5.3.3 になってるのに？
もしかして、あまり最近は活性がよくないのかね？Cube のプロジェクトって。

取りあえず当方の環境は以下のとおり。

XOOPS: XOOPS Cube Legacy 2.1.8a
OS: FreeBSD 8.1-RELEASE
HTTPD: Apache 2.2.17
MySQL: 5.1.48
PHP: PHP 5.3.3

まあ、取りあえず、テスト用のサイトなので、上記メッセージが出てても「まともに動けば問題ない」んだけどね。

取りあえず、管理者メニューの設定画面とかがまともに動くか見てみて、どうするか見極めよう。

XOOPS Cube Legacy がらみの案件があるので、当社サーバ上にもテスト環境を作ってみようかと思ったのだが、どうもうまくいかんねえ。

インストール中もずっと、

Deprecated: Function set_magic_quotes_runtime() is deprecated in /hogehoge/hosts/www/xp/install/class/textsanitizer.php on line 32

Warning: Cannot modify header information - headers already sent by (output started at /hogehoge/hosts/www/xp/install/class/textsanitizer.php:32) in /hogehoge/hosts/www/xp/install/include/functions.php on line 82

・・・てなワーニングが出続けてたんだけど、これは XOOPS インストール時の既知の問題ということだったのでそのままインストールを続けたのだが、

・何故か、アクセス権のチェック画面から英語表示に変わった。（それまではちゃん日本語表示）
・The 2nd Step Installation（インストール第２ステップ）に進む「Next」ボタンを押しても、ログイン画面に進まない。
・直接、http://localhost/xp/ にアクセスすればログイン画面は出るけど、実際に管理者IDでログインして見ても、すぐ再度ログイン画面が表示されてしまう。

・・・と。全然駄目じゃん(^^;

取りあえず、第２ステップが終了しない（ログイン画面に移動しない）のは、ワーニングメッセージが出てしまうために、Location ヘッダが正しく処理されないとか、そういうことじゃないかと思い、php.ini を

display_errors = On
　↓
display_errors = Off

に変更してワーニングを出さないようにした。
そしたら、ちゃんとログイン画面には移動したよ。
で、管理者IDでログインしてみたら、インストール第２ステップ：基本モジュールのインストール画面が無事表示された。
（画面の下にはまた、なにやら怪しげなメッセージが沢山表示されているが・・・display_errors を Off にしてても出てくるんだな？）

んで、Install ボタンを押して、無事「Install Complete!」画面が表示された。

む～ん・・・

取りあえず俺の場合は自分とこのサーバなので php.ini を編集出来たが、それが出来ない人は、インストールすら出来ないということか・・・（いや、もちろん、ソースを直接触ってエラーを表示しないようには出来るけど、そんな面倒くせぇこと出来んじゃろ？全てのインストール関連ファイルに対して）