PEAK XOOPS - EMLH and Error Log !!
Hello Gijoe I used Emlh hack of my xoops site. Now created Error_log file on rmdp,news modules wite 3 Gigabyte of size. I Downloed error_log file and open wie notepad: this errors is appears: [12-Oct-2007 16:20:59] PHP Warning: preg_match() [<a href='function.preg-match'>function.preg-match</a>]: Empty regular expression in /home/.../public_html/include/easiestml.php on line 181
PEAK XOOPS - XOOPSにおけるPHPエラーハンドリング問題
XOOPS2.0.4から導入されて「しまった」XoopsErrorHandler。 私自身、ことある毎にこれについて批判してきましたが、その理由は明確です。 (1) phpの設定によらず、PHPエラーがHTTPボディとしてechoされてしまう (2) fatalエラーなどで止まる場合は、ハンドラの上書きが効かない (3) mainfile.phpを通過するケースとそうでないケースで、設定を一致させる術がない (1)は、実稼働サイトでエラーを確認する術がないことを意味します。XoopsErrorHandlerは一応XOOPS_URLを隠蔽してくれますが、PHPデバッグがONの間、すべての訪問者にエラー内容を送出してしまう、という根本的な問題が解決されていません。 (2)も大きな問題です。mainfile.phpなどの記述ミスで、fatalエラーとなる場合、error_reporting()や
PEAK XOOPS - 本家版XOOPS 2.3.2の構造的欠陥
世界的にXOOPSの本家とは xoops.org ってことになり、本流は2.3系列って事になっているようです。 そこの最新版である xoops-2.3.2b というアーカイブをダウンロードしてみてあきれました。 htdocs/ の中に、xoops_lib というフォルダがあって、その中に、XOOPS_TRUST_PATHに置かれるべきファイルが詰まっているのですから。 しかも.htaccessすらなし。 思わず目が点になりました。 mamba氏が、XOOPS_TRUST_PATH内のファイルにLFIがある、という不思議なレポートをしてきて、その意味が理解できなかったのですが、アーカイブ構造を見て納得しました。 つまり、彼らはXOOPS_TRUST_PATHの意味を一つも理解していないのです。 XOOPS_TRUST_PATHを、xoops_lib なんて名前に勝手に変更しているのも、彼らが
PEAK XOOPS - cubeUtilsをEMLH互換とするpreload
EMLHはXCL2.1でもまったく問題なく動きますが、いろいろな意味でcubeUtilsの方がより使いやすい多言語処理と言えるでしょう。前者は一応Hackで、後者はモジュールだ、というのもあります。 ただ、この手の多言語処理は、ob_filterを利用しているので、メール送信処理などで、言語タグが未処理のまま送られてしまうことはままあります。 そのあたりの経験を積んでいるモジュール作者であれば、メールを送信する前、本文などに言語タグ書き換え処理を入れます。 実際に私が作ったモジュールにも、このようなコードを沢山使ってます。 ただ、このロジックでは、EMLHを入れている場合は良いのですが、cubeUtilsを入れている場合に効きません。そのため、例えばpicoのフォームメール機能を言語タグを利用して記述した場合、タグが未処理のままメール本文になってしまいます。 というわけで、cubeUtil
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
