本日、phpTrafficA2.0の状況を確認して気づいた問題が１つ発覚。

前回書いた通りに移転後のサーバのPHPは、5.2.5の最新なんだけどそれが問題。
過去記事でTextWikiで書いてた記事の内容が表示されないことが発覚。
サーバ間コピーの何かトラブルでもあったのかと入れ直したりしてはみたものの直らないので、PEARのTextWikiのページをみて最新版が出てないかと探ってみた。
が、TextWiki自体は更新されてない模様・・・しかし、バグ報告を発見！
どうやら、htmlspecialchars/htmlentitiesの関数でcharsetの引数にUTF-8を指定すると戻りの文字列が空になるという結構致命的なPHP5.2.5のバグのようです。
案の定、このSerendipityもNucleusもUTF-8で構築してるし、TextWiki使っているのでこの問題で記事内容が空っぽになってしまうということになるわけです（＞＜）

しょうがないので、この部分のソース（xHtml.php）を修正して上記関数を使わないように暫定対処をば施しました。
早めに修正版を出して欲しいような、パッチは出ているのでパッチを充てれば解決なんですけど、ちょっと困った状況です。
5.2.5の修正履歴には、この関数のセキュリティ強化がなされたようなんですが問題のない文字コードでも弾かれてしまったつうことなんでしょうか？
パッチのソースを見れば分かることなんでしょうけど・・・。
XREAさんに頼めば、パッチ充てたPHPにしてくれるかなぁ・・・・。

結構、この関数類を使うものが多いような気がするんですけど、、大騒ぎになってなさそうなんで局地的な不具合ってことですかねぇ。

とりあえず、ちょっとアップデートされるまでは気をつけて使わなきゃです。

CIにPEARのCache_LiteをさらにLiteにしたような自作のキャッシュクラスを作って楽天WEBサービスのXMLデータのキャッシュとして使っていたんですが、DBのキャッシュも兼ねようかと考えていたところ、Zend_Cacheを使うことを思い立ちました。

CIのでDBキャッシュの仕組みでもよかったんですが、仕組みとして有効期限がなかったり、URI毎にキャッシュしちゃうんで作っていたアプリには不向きな仕様だったんです。

で、Zend_Cache・・・・結構いいっすぅ。

自作のキャッシュクラスを破棄決定っす！ タグを付ければ、指定タグのキャッシュファイルは全部消えるし、有効期限も対象ごとに設定できるので便利！

ファイル名自体に有効期限が入っているので、本当の意味での指定ごとの対応になるわけです。
Cache_Liteだとそのときにクラスに指定されている有効期限でファイルのタイムスタンプと比較しちゃうので、自作キャッシュロジックではZend_Cacheみたいな感じに対応してたんですけど、パフォーマンスはZend_Cacheの方が優秀でしたわ。
キャッシュクリアの処理が特に速いような、readdir使ってないので速いのかもです。
実際書き換えて作ってみた感じとしては、かなり使い勝手のよいキャッシュクラスだと思います。

ということで、必要に応じてZendFrameworkのクラスを利用するのはよい感じですねぇ。
というよりもCIよりZendFrameworkそのもので作った方がよいかも・・PHP5の環境ならですけど。

次はZend_RestかZend_Service_Amazonとかと組み合させてみようかなぁ

Helperとして、SJIS出力を行う関数を用意して、各コントローラの中に_output関数を追加して、そこでSJIS出力ヘルパーに渡しているという超簡単な対応です。

コード書くまでもありませんねぇ。

_output関数の引数には、出力するコンテンツデータが渡されますのでこれを単にSJIS変換してechoで吐き出せばOKなんです。

実際のHelper関数ではheaderとしてContent-Lengthを出してからecho出力をしています。

ほかにも色々とCSSのキャリアごとの対応とか、HEADER部もキャリアごとにやってたりもするんですが、SJIS出力とは関係ないので割愛。

基本的には、SJIS出力さえできればキャリアごとの対応はViewのテンプレートかコントローラ側でキャリア対応をすればいいってことになります。

ついでに絵文字対応をするなら、下記のライブラリがオススメです。

MobilePictogramConverter 絵文字変換ライブラリ

上記のSJIS出力時にこのライブラリと組み合わせて絵文字出力化をしてみれば、バリバリな携帯サイトの出来上がりです。

あ、入力がある場合には絵文字入力対応が・・・それも探せば手立てはあるはず・・ですね。（探してみます、今度）

MyDiaryを作り直そうとか思っていて、以前に紹介したFrogのフレームワークを利用して作り始めてから気がついたんですが・・。

多少なりとも旧MyDiaryを使ってくれている方々がいらっしゃるとすると、多分そこの環境はPHP4。

であれば、置き換えてもらう予定の新バージョンがPHP5専用っていうのは問題かも・・と、思い始めました。

FrogはPHP5専用なんですよね。

ということで、現在、軽量でよさげなフレームワーク探しの旅に出ています。
今のところ、ちいたん、moonyのどちらかなぁと思いつつも、ほかにはないかなぁと探しまくったり。
いっそ、自分で作るって・・・っていう手もあるんですけど、せっかくなので良い旅を過ごしてみたい今日この頃。

ちょっと変わった感じで、とても面白そうな感じなのがrhaco、少し試しに作ってみたんですがとても面白いっす。
CIよりは軽量な感じにも思えるんだけど・・・もうちょっと作ってみて考えようかなぁ。

ちいたんは、テキストファイルをDB化するクラスがあるんでちょっと心を惹かれてはいるんですけど。
Routerクラスを追加してCIライクにしてみるとか、まあ、別にそのままでもいいともいえるんですけど、もうちょっと色々と試してから決定しようかなと思います。
moonyでもちょっと作ってみたいし・・。

PHP4/5両方動くのがいいなぁと思っています、確か今年で終わりだったよねぇ、PHP4。

CodeIgniter関連で色々と巡回していたら、見つけたのがFrog CMSの作者さんが作ったFrog Framework。

RubyのRadiant CMSのPHP版としてphpRadiantって名称で最初はリリースされたようです。
現在は、Frog CMSっていうようです・・・いわゆるシンプルなCMSで、MODxと比較してはいけないとは思いますが、CMSのベースとなりえそうな感じですね。

で、その作者が１つのファイルでFrameworkのコアを作っちゃったつうことで、そのページが以下のアドレス。

意識しているのがCIで、Welcomeのサンプルを比較してFrogのシンプルさが分かる感じになっています。

Frog+Framework