<837D A4A94AD8EBA202D B C20584F4F AD68C5782CC8A4A94AD82C582A282EB82A282EB>

Transcription

1 マイサイト開発室 - フォーラム XOOPS 関係の開発でいろいろ 1 / 5 マイサイト開発室 マイサイトの運用テスト マイサイト開発室 - フォーラム有象無象 XOOPS 関係の開発でいろいろ 投稿者 スレッド XOOPS 関係の開発でいろいろ 最近 XOOPS 関係の仕事が増えた ( というかほとんどになってるな ) その辺をメモるスレッドにしてみる 最近リリース版として XOOPS JP が出たので あちこちアップグレードした 大半は問題なく動いているが 自宅で使ってる開発サーバ (NetBSD 3.0) で不具合が発生した メール送信で動かなくなるのだ OS のアップグレードやメールの設定をかなりいじっていたので それらの影響かと思っていたのだが サブジェクトの文字化け問題で phpmailer のバージョンが変わったと言う話を思い出して XOOPS a の phpmailer に戻してみると問題なく動いた 何か非互換な変更が加えられたようである ( 半日つぶれた orz) 今は それらを追求している暇がないのでこれで使うことにした :43 仮想 XOOPS サイト で提供しているサービスは データベースとソフトウェア (XOOPS) をドメイン名で関連付けることで仮想化するアイディアに基づいている サラリーマン時代に ASP 向けの実装として考えた手法だ 同一のコードがあれば 資源の許す限り任意の数のサイトが作成できる 同一のコードなので 一つだけメンテナンスすればよい ファイルによる構成要素を持たないため データベースのバックアップだけで状態保存ができる などのメリットがある ただし 欠点として データベースの関連付けを行うようにソースコードの改造が必要 ファイルアクセスを前提とするコードは手当てが必要 と適合性やカスタマイズへの自由度に問題がある ソースコードの改造が必要なため XOOPS2 への対応をずっと保留 ( 放置 ) してあったのだが 別のアプローチでの実装を思いついた この方式は ソースコードは無改造で使えるようになるため サイトを構成するツールを開発すれば実現できる さらに サイトごとの導入イメージやコードのカスタマイズさえ原理的に

2 マイサイト開発室 - フォーラム XOOPS 関係の開発でいろいろ 2 / 5 は可能である さて 問題はこれを実装するだけの時間があるかどうかだが 作りかけや保留中のアイディアが他にもたくさん :40 メール送信の不具合は... メール送信の不具合は サブジェクトの文字化けの対策パッチで メソッド名の置き換えが不十分だったのが原因だった 親のメソッド呼び出しにあるのを見落としていた orz これで無事 自宅の開発マシンも XOOPS JP にアップグレードできた :36 重たいメインメニュー XOOPS のメインメニューが重たい と言う話がある 構造的に xoops_version.php をなめるからなぁ そこで 実際どのくらい重いのか測ってみた 開発マシンのトップページ 5 つのブロックが並んでいて メインとしては ToDo リストを置いている SQL デバッグモードでブロックをオンオフしてその差を計算してみた ( 単位秒 ) ブロック無し メインメニュー ユーザメニュー ToDo リスト カスタム (PHP) カスタム 噂に違わず メインメニューは断トツの一位の重さである サイトを軽くしたいなら まずはメインメニューを外せ ということだな :12 メールサブジェクトの文字化け Fedora Core 5 な環境で XOOPS a からのメールサブジェクトが文字化けする PHP の mbstring にもまだ問題があるようだ language/japanese/xoopsmailerlocal.php の 146 行目を強制的に false として 旧版のエンコード方法を使うようにして対処した 途中の文字化けは改善したが 文字列末尾が欠けている まだバ

3 マイサイト開発室 - フォーラム XOOPS 関係の開発でいろいろ 3 / 5 グってるのかな? :28 UTF-8 へのエンコード 些細な問題と言うか include/functions.php の 727 行目 xoops_utf8_encode() 関数の実装 - return mb_convert_encoding($text, 'UTF-8', 'auto'); の "auto" は問題がある 内部文字コードは固定されているのだから 入力文字で不安定になる "auto" を使わず _CHARSET 定数を使うのが確実である + return mb_convert_encoding($text, 'UTF-8', _CHARSET); :20 モジュールのバージョン付番 update モジュールを作っている関係で XOOPS モジュールにおけるバージョン番号の扱いを考えた XOOPS のモジュールにおけるバージョン番号は X.YY となる YY は 00~99 の固定で X.10 と X.1 は同じ意味になる 内部表現が 100 倍した整数値として保存されるため この表現に固定されてしまうのだ 個人的には X.Y.Z と言った履歴管理システム由来の形式をよく使うのだが XOOPS のモジュールに限っては あまり相性がよくない ( 某公開モジュールでは 2.0 から付番ルールを変更した ) この付番ルールで困るのは ブランチが表現できないことだ モジュールの改造とか請け負うことも少なくないので 元になったバージョン + 改定版数のような表現を取りたいのだが 残念ながらそれができない 仕方ないので俺ルールで description にでも仕込むのがいいかなぁ :42 アップロードファイルのサイズ制限 ファイルのアップロード関連は リソース不足障害の防止のためいろいろな部分で制限がかけられるようになっている ソフトのパッケージングなどで 既定値が設けられるなどありがた迷惑になる場合もあって困ったものなのだが XOOPS でアップロード機能を持ったモジュールを作る機会が何度かあって 設置で生じる障害がいくつかあったのでそのメモ 障害発生ポイント

4 マイサイト開発室 - フォーラム XOOPS 関係の開発でいろいろ 4 / 5 1. PHP の制限 /etc/php.ini: upload_max_filesize = 2M 2. apache の制限 /etc/httpd/conf.d/php.conf: LimitRequestBody Redhat Linux 9 の設定 他にも quota やファイヤウォールなどでも制限できるだろう :38 Re: メールサブジェクトの文字化け 不定期に登場するのだが eguide の通知でサブジェクトが文字化けする と言う話 eguide では XOOPS のシステムで定義されているメール関数 (XoopsMailer) をそのまま使っており 文字コードに何も加工していない つまり 文字化けが起きるとしたら XOOPS のコアの問題である さて 結論をいうと 問題は PHP の MIME エンコード関数に問題があり 動作が不安定なのだ そこで XOOPS にはそのための回避コードが入っているのだが 特定の PHP バージョンに限定しているため 改訂版でそのバグが残っていると障害につながるわけだ PHP の配布バイナリによっては独自に修正パッチを取り込んでいる場合があるので 同じ版でも問題が出たりでなかったりする そこで そういう場合の安直な対処方法としては 回避コードを有効にしてやることだ 取り敢えず試してみるなら常に回避コードを有効にしてしまえばよい --- language/japanese/ xoopsmailerlocal.php :1 +++ language/japanese/ xoopsmailerlocal.php ,7 } function EncodeHeader ($str, $position = 'text', $force=fal - if (!preg_match('/^4\.4\.[01]([^0-9]+ $)/',PHP_VERSION) + if (false &&!preg_match('/^4\.4\.[01]([^0-9]+ $)/',PHP if (function_exists('mb_convert_encoding')) { //Use if ($this->needs_encode $force) { $encoded = mb_convert_encoding($str, _CHARS :07

5 マイサイト開発室 - フォーラム XOOPS 関係の開発でいろいろ 5 / 5 Powered by XOOPS The XOOPS Project Hosting by MySite Web Service