PHP のブログ記事

PHPを使ってGoogleショッピングAPIを叩きたく、調べていたら、
ZendFrameworkの「ZendGdata」で比較的簡単に出来る。
 
が、、、いかんせんドキュメントが少ない上に、
公式が英語のみでいろいろわけわからんかったけど、なんとかできた。
その覚書。
 

<?php
require_once( 'Zend/Gdata.php');
require_once( 'Zend/Gdata/ClientLogin.php');
require_once( 'Zend/Gdata/Gbase.php');    

//クライアントのインスタンス作成。ログインIDとパスワードを設定
$client = Zend_Gdata_ClientLogin::getHttpClient( 'ログインID(メアド)', 'パスワード', Zend_Gdata_Gbase::AUTH_SERVICE_NAME );
$service = new Zend_Gdata_Gbase($client);    

//新たなエントリーを作るためのインスタンス作成
$newEntry = $service->newItemEntry();    

//商品名(タイトルだけど商品名として扱われる)
$newEntry->title = $service->newTitle('商品名');    

// データの登録先を定義(Googleショッピングの場合はProducts)
$newEntry->itemType = "Products";
  
//概要(コンテンツだけど概要として扱われるらしい
$content = "概要概要概要概要";
$newEntry->content = $service->newContent($content);
$newEntry->content->type = 'text';    

//品番
$newEntry->addGbaseAttribute("id", "品番", "text");    

//状態 new|used|refurbished
$newEntry->addGbaseAttribute("condition", "New", "text");    

//商品ページURL
$newEntry->addGbaseAttribute("link", "URL", 'url');    

//価格
$newEntry->addGbaseAttribute("price", "値段 JPY", "numberUnit");    

//対象国(これを忘れるとチェックが通らない。忘れがちなので注意。
$newEntry->addGbaseAttribute("target_country", 'JP', 'text' );    

//データ挿入実行(テスト実行は2番目の引数をtrueにする。
$createdEntry = $service->insertGbaseItem($newEntry, false);    

?>

 
だいたいこんな感じ。
これ以外のフィードアイテムについては、
Googleのフィード仕様の説明をご覧になればわかるかと思います。

なお、注意点として、ZendGdataはAPIでエラーが出たとき、FatalErrorとなります。
エラートラップなどの必要性がありますので、そのへんの実装は各自行ってくださいね。
 
私はこれを直で使うわけでなく、XMLのフォーマットを知りたかったから。
同じ様にAPIのXMLのフォーマットを知りたいという人は、
Zend/Gdata/App.phpのpost()の中で、「$requestData['data']」をecho()すれば幸せになれます。


追記:2010/12/28
上記の方法は「ClientLogin」を利用しています。
ClientLoginの場合、ログイン失敗などするとCaptcha認証が必須となり、
ログインしようとするとHTTPエラーコード403が戻りますが、
ZendGdataでは、これをハンドリングする仕様にはなってないようです。
実際の利用時は、ZendGdataに含まれるHTTPクライアントオブジェクトを拡張するなどして、
Captcha必須のエラーハンドリングを行えるようにしたほうが良いでしょう。
 

seezoo cms(http://seezoo.org/)が楽しい。
プログラマ的に言って拡張がかなり楽!!
 
a-blog cms(http://www.a-blogcms.jp/)といい、
名古屋の人が作るツールは楽しい物ばかりだ。
 


昨日、seezooの開発元の音生さん(http://neo-navi.net/)に伺った際に、
色々話を聞かせていただいて、
その内容をもとにseezoo用のブロックを作ってみた。
 
前々からほしいと思っていた、wiki記法ブロックを作った。
パーサーを自分で書くのは大変だったので、
PEARのText_wikiに頼っている。

ダウンロードはこちらからどうぞ。


【インストール方法】

1)まず、PEARのText_wikiをインストールします。
PEARコマンドが使える場合は、
通常通りコマンドでインストールしてください。
 
使えない場合は、

・PEAR(ベースシステム)

http://pear.php.net/package/PEAR/download

をダウンロードして、解凍してできる、
PEAR.phpとPEARディレクトリを
system/application/libraries/ディレクトリに置きます。

・Text_Wiki

http://pear.php.net/package/Text_Wiki/download

をダウンロードして、解凍してできる、
Textディレクトリを同じく
system/application/libraries/ディレクトリに置きます。
 
 
2)ブロックを置く。
先ほど上記にてDLしたWikiブロックを解凍してできる、
kiyowikiディレクトリを、
blocksディレクトリに置きます。
 
3)ブロックを有効にする。
管理画面のブロック管理にいくと、
「インストール可能なブロックのリスト」に、
「Wiki記法ブロック」というのが追加されているので、
それを有効します。

あとは、通常のブロックと同様、
ページ編集画面で「Wiki記法ブロック」を追加して、
表示されるテキストエリアにWiki記法を書けばOKです。
使える記法については、
http://pear.reversefold.com/dokuwiki/text_wiki:samplepage
ここを参考にしてください。


 
ここまで来て気づいた。。。
Text_WikiのインスタンスをいちいちViewで有効にしてる…orz
動くには動くけどスマートじゃないし、色々無駄。。。
そのうちヘルパとして用意したバージョンを公開しますね。
とりあえず、利用される場合は、
完全自己責任の名のもとに使うベータ版として利用してくださいね。
あくまでも、これは私のお勉強のためのものですから!!

あ、そしてもう一個気づいた、wiki記法ブロックにidとclass付けれるようにしたほうがいいな、、、カスタムCSSで自由に操作できるもの。
 


追記:バージョアンアップ 2010/12/29

・作成したブロックを<div>で囲み、そこに任意のidとclassを付与できるようにしています。
 これにより、CSSやカスタムCSSで、そのブロックに任意のCSSを適用できます。
 
・初版では、wikiブロックにHTMLコードを入れた場合、自動サニタイズされる仕様になっていましたが、
 それを回避しています。<script>などもそのまま出力されてしまうので、
 セキュリティホールを作らないようにしてください。

昨日、音生さんに伺った際に、
「PHPでヘンなHello,world出力とか面白いよね」
みたいな話があったのを思い出した。
 
MIME64エンコードから出力とか、
16進数から出力とか考えたけど、あるよなー多分。
って思って、もうちょっと考えて「BrainFuck」で出力したら面白いんじゃね!?
とか思って、調べたら、もうやってる人がいた(^-^; なんちゅー。。。
 


 
BrainFuckとは、冗談言語と呼ばれる種類のプログラミング言語で、実用性は皆無。
基本的にメモリのポインタ増減だけで命令を表現する、難読言語です。
 
BrainFuckでHello,world!を表現すると、
 

+++++++++[>++++++++>+++++++++++>+++++<<<-]>.>++.+++++++..+++.>-.
------------.<++++++++.--------.+++.------.--------.>+.

 
、、、、当然意味がわからん、、、、
 
まぁ、これを使ってPHP上で何か出力仕様という魂胆だ。
 


 
「PHP BrainFuck」でググったら、
なんと、PHP用のBrainFuckインタプリタがあった!
http://daniel.lorch.cc/projects/brainfuck/ 
 
ここにすでにサンプルとして、Hello,wordl!がある!!
 
が、あえて自分で書く!
 
インタプリタをダウンロードして解凍してできる「brainfuck.php」をrequire/includeして、
brainfuck()にBrainFuckの命令を引数として渡してやると、
返り値にインタプリタの実行結果が帰るので、それをecho()する。
 

<?php
include_once('brainfuck.php');
echo( brainfuck('+++++++++[>++++++++>+++++++++++>+++++<<<-]>.>++.+++++++..+++.>-.
------------.<++++++++.--------.+++.------.--------.>+.'));
?>

 
こんな感じです。


 
まったく使えないTipsですねwwww

前の記事でCodeIgniterを使うことを決めたと書きましたが、
ダメな所ももちろんたくさんあります。
 
http://oddwit.com/blog/2007/coming-to-hate-code-igniter 
 
こんな記事もありますし。
 
私は個人的にテンプレートが生PHPなのがうーん。だったのが、最初躊躇した理由です。
PHP自体がテンプレートエンジンのオーバーテクノロジー(だと、PHP開発陣ですら公言している)なので仕方ないですが。
とはいえ、phpタグをHTMLコーディングする人に書いてもらうのはどうしてもいやだ。
 
という理由で、EthnaかSoyCMSのフレームワークかで悩んだのですが、
 

@kiyotchi CodeIgniterの事であれば僭越ながら色々お話できるかもです。SeezooもCodeIgniterで作ってるので、プラグイン作り放題ですよーwあと、Smartyプラグインは http://bit.ly/eWYqAC とかを参考にドゾー。less than a minute ago via web


 
という情報をいただく。
 
ただ、Cakeとかも一応Smartyつかえるけど、かなりCakeの良さをそぎ落として使うことになるのは、よく知られたはなし。CodeIgniterではどうかな?と思って、寝ずにやってみた。
 
うん。かなりいい感じ。無理なく使えるって感じです。各ライブラリの独立性が高いのと、コントローラーが柔軟なおかげですね。
 


 
上記のTipsだと、CIのライブラリフォルダにsmartyを突っ込みましょうとかいてありますが、
CI → Apache/BSD
Smarty→LGPL
と、真っ向からぶつかる訳ではないですが、
やっぱりライセンス的に切り分けておきたいので、
SmartyはSmartyのみで、PEARディレクトリか、include_pathの通っているパスへインストールして使うことに。
 
その場合、CodeIgniter/system/libraries/Smarty_parser.php の
 

require "smarty/Smarty.class.php";

は、インストールの仕方で、パス指定が変わるので注意。

来春からひとり立ちをして生きて行くことになったわけですが、
それに伴い、高速開発というのも視野にいれて行動しなくてはいけなくなりました。
 
かなりECに特化したフレームワーク(Perl|PHP)を自作して使っているのですが、
自作フレームワークだとそれ自体をUPGRADEする時間も必要になって大変だ。
 
というわけで、PHPのものだけ、オープンのものをさがすことに。
有名どころから
 


 
・CakePHP http://cakephp.jp/
RoRをお手本にしたフレームワーク。
PEARなどの既存ライブラリに依存せず、かなり広汎なサイト構築に対応。
「なんでも屋」な印象。
既存ライブラリに依存してないのはいいけど、
ちょっとカッチリしすぎていて、自分の設計思想には合わず。
 


 
・Symfony http://www.symfony-project.org/
こちらもきれいなMVCパターン。
かなり堅牢なアプリケーションが開発できる。
規模という意味ではおそらく、一番広く対応できる。
こちらもかっちりしすぎていて、自分の設計思想には合わず。
 


 
・Ethna http://ethna.jp/
GREEが自社開発用のためにつくったフレームワーク。
MVCながら、緩い制約。コマンドラインがちょっと面倒。
全体的に好みなんだが、DB接続のデフォルトがPEAR_DBなので、ちょっと困った。
日本製っていうのが大きいし、稼動実績は目に見えてわかる。
PEAR_MDB2採用なら飛びつく。そこだけが惜しい。
 


 
・ZendFramework http://framework.zend.com/
PHPの言語エンジンの開発元謹製のフレームワーク。
かなり色んなライブラリが揃ってるのが魅力。言わば第二のPEARみたいな。
各機能はそこだけ切りだして使えるのもPHPっぽくて良い。
が、、、PHP5.2.4以上なのが困った。まだ5.1系沢山抱えているので。。。
 


 
・ちいたんhttp://php.cheetan.net/
cakeに影響をうけながら、フレームワークとしての機能はMVCの分離にとどまっているのが、
いいなぁと思って、1年くらい前からチェックはしていた。
でも、まぁよくも悪くも、何もなさすぎて、、、
 


 
・SoyCMSのフレームワークhttp://www.soycms.net/
フレームワークとして、独立しているわけではないのですが、
SOY CMSはベースに独自フレームワークを使っています。
CMSなのでテンプレートエンジンが素晴らしいとこがいいです。
が、ドキュメントが少なくて、断念。
 


 
・CodeIgniter http://codeigniter.jp/
周りに使っている人が少なくて、いまいちマイナーな感じをうけていたので、
後回しになっていました。
コマンドライン操作がいらない。コーディング規約がゆるい。
MVC分離にはなっているが、ぶっちゃけモデルいらない。
セッションを全てcookieに保存するところがうーん。
これまでの資産が活かしやすい。
 
  


 
ほかに、MapleやMojaviなどもありますね。
 
PHPは言語じゃなくて、ツールやフレームワークだよと思っているので、
その上にガチガチのフレームワークを乗っけるのは好きではない。
これまでの資産が活かしたい。
コマンドラインを叩かず、ぶち込めば基本的に動くものがほしい。
 
という個人的なわがままを一番満たしてくれたのが、CodeIgniterなので、
これを採用することにしました。
 


 
早速、これまでの資産をCodeIgniterに移植する作業をしていますが、
ちょっとの書き換えで済むので、すごくラクです。
良くも悪くもPHPを知ってないと、使いこなせないのかなという印象もありますが。
とりあえず、なんか一個作ります。
 


 
自作フレームワークも並行してさらにEC専用になるように磨いていきます!
 
ちなみに、自作フレームワークは、
・説明書が書けないレベルになっとる。
・あまりにもEC専用で、私の仕事の手の内を見せることになる。
・フレームワークの名前に元カノの名前が付いとる。
ということで、公開はしません。絶対にww。

今日はWordCampNagoyaの開催日
 
9時から名古屋におけるサイト解析第一人者である運営堂森野代表のセッションがあるということで、普段10時起床の私にとっては、かなりの早朝の7時起床でいってきました。

Google Analyticsに関してのセッションでした。
私が生業としているECの世界においても解析は重要なのですが、Google Analyticsは使ったことがありません。
慣れなのでしょうが、とっつきにくくて…。
と、思っていたら、その解析業務を助ける、GreaseMonkeyの存在を話されていて、これがあれば使える!と思いました。行ってよかった。
WordPressに直接関係する内容ではないものの、WordPressをはじめCMS各種って、運営に焦点をあてたシステムにも関わらず、実は制作サイドの意識としてはサイト構築ツールまでで終わっていることが多いですよね。良くも悪くも。
解析の話を通して、運営面に少しでも目が向くのならと思いました。
 


その後、MightyWorksさんの「WordPressとは」というセッション。
Wordopressを紹介するセッション。
かなーりWordPress愛を感じるセッションでした。
 


 
次、WordCampを抜け、ゆるPerlに向かう。
初期メンバーに名を連ねながら、初めての参加。
 
おーい。色々緩すぎるぞ!いつもはこれでいいけど、たまには、目的意識をもった会をやったほうがいいぞー。
 


 
またWordCampに戻る。起きてたのにバスを乗り過ごすという、荒業を成し遂げてしまいました。
 
LTセッションでは、お友達のマイペースクリエーターKさんが話をするということで、まじまじと見る。完全初心者向けのWordPressテンプレートを公開したということで、それについて発表しました。おぉ。なんか、みんな良い反応!
 
横浜のWordCampのUstで見てめちゃ面白かった、め組のメガネさんのセッションもありました、こちらもWordPress愛を深く感じ、なおかつ面白いセッションでした。め組さん。普段お世話になってます。
 


大体こんな感じ。その後懇親会→二次会。
 
全体通じて思ったのは、WordPressって情報がいっぱいネット上には転がってるんだけど、やっぱりオープンソースゆえ隠れた情報も沢山ある。オープンソースの利用にあたっては、コミュニティに参加することが、情報を集める上で一番良い手段で、かつ、コミュニティに参加して恩返しをすることへの意識が必要なのではと思った。その辺がプロプライエタリとの大きな差かな。
 
私は、普段一般のWEB制作の世界とは違うところで、サイト制作を行っているので、必ずしも、WordPressが最上位のパブリッシングプラットフォームだとは思っていない。(これは立場の問題なので、この部分を突っ込まれるとちょっと困るので、聞き流してくださいね)
それでも、これだけ沢山のユーザーがいて、これだけ沢山のコミュニティ参加者がいるWordPress。常に選択肢の中には入ってくるとは思う。
 
まぁ、そんなこんなで、WordCampお疲れ様でした。
最後に謝っておきます。若干立場的に微妙な人が参加しててごめんなさい。(分かる人が分かれば良い謝罪)
 


 
あ、ゆるPもまとめなきゃ。
 
参加者の初心者の方に少しだけレクチャーさせてもらったんだけど(WEBでの利用に関して)、PHPに最初に手を出しては理解をせずに、飛び込んで行けてしまうHTTP関連の仕組みや仕様とかを、Perlにおいては、理解を持ちながら勉強をする必要があるなと実感。
諸先輩方がプログラミング初心者がPHPでプログラミングを学ぶことへの批判はこのあたりにあるんだろうなと。
 


そんなこんなで一日終わり。疲れたぞ。

ちょっと野暮用で(という言い方も変だが)、
さくらインターネット(スタンダード)にSeezooCMSをインストールする必要があった。
 
公式のインストール方法を元に設置まで進んで、
いざインストール設定をと思うと進めない。
???
と思い、/index.phpに直接アクセスしたら、
インストーラーを見ることができたので、
なーんだと思ってインストール完了。
 
さぁ、じゃあ使おうじゃないかと思うと、
ここでさっきの問題が何を意味しているかわかった。
mod_rewriteの動作が変!!!orz
 
最初はmod_rewriteの動作がなのかなと、
.htaccess周りをずっと見ていたのだけれど、
どうもなんか違う。.htaccessの書き方は正常だ。。。
 
というようなことをTwitter嘆いていたら、
@longkey1さんが
・ルーティングあたりに問題がある。
・mod_rewrite後PHPにPATH_INFOが渡されないのが問題かも。
とアドバイスを受ける。
 
!!!
 
初めてCGIモードでPHPを触ったのですが、
CGIモードの場合、PATH_INFO周りの扱いが非常に面倒になるのですね…。
知りませんでした。。。
 
でも共有ホスティングではCGIモードがメインの日本では、
知らなかったでは済まされない事態…@longkey1さんありがとうございます。。。
 


 
私が行った対処方です。
 
まず、seezoo CMSデフォルトのサンプルでは、.htaccessは、

RewriteEngine On

RewriteCond $1 !^(index\.php|sitemap.xml|sitemap_ssl.xml|css|js|captcha|uploads|templates|blocks|phpMyAdmin|.+\.gif$|.+\.jpg$|.+\.png$|.+\.js$|.+\.css$|.+\.json$|.+\.ico$|.+\.swf$|.+\.flv$)
RewriteRule ^(.*)$ index.php/$1 [L]

 
こんな感じですが、これを
 

RewriteEngine On
RewriteBase /
RewriteCond $1 !^(index\.php|sitemap.xml|sitemap_ssl.xml|css|js|captcha|uploads|templates|blocks|phpMyAdmin|.+\.gif$|.+\.jpg$|.+\.png$|.+\.js$|.+\.css$|.+\.json$|.+\.ico$|.+\.swf$|.+\.flv$)
RewriteRule ^(.*)$ index.php?__REQ__=$1 [L]

 
こんな風にします。@_tk84さんの情報によると、さくらの場合は、基本的にRewriteBaseの設定は行った方が良いようです。ありがとう!_tk84さん。
 
次に、/index.phpの冒頭に、次のPHPスクリプトを埋めます。
 

if( isset( $_GET['__REQ__'] ) ){
    $_SERVER['PATH_INFO'] = $_GET['__REQ__'];
}

 
ここまでの流れを説明すると、
URLのパス情報を「__REQ__」というリクエストで送信して、
それを受け取ったindex.phpが、
$_GET['__REQ__']を$_SERVER['PATH_INFO'] に代入して、
ルーティングを成功させようという魂胆。
 
 
これでいけるか。と思ったら、まだ変。。。
改めてCodeIgniterのルーティングについて調べる。
すると、CodeIgniterでは、何を基準にルーティングするのかを決める設定があって、
デフォルト状態ではそれが「auto」になっているという話。
それを明確に「PATH_INFO」を基準にせよとすれば、
うまく行くっぽい!
 
/system/application/config/config.php
の次の箇所

$config['uri_protocol']	= "AUTO";

$config['uri_protocol']	= "PATH_INFO";

 
と書き換えた。
 
 
これで成功!めでたしめでたし。
あとはつくるだけ。
 


 
@longkey1さん、@_tk84さん、ありがとうございます!

サイトで、ヘッダ部分やフッタ部分やサイドメニューなど、
サイト全体で共通の表示をおこないたい時に、
昔からよく使うのがSSIの

<!--#include virtual="ドキュメントルートからのパス"-->

 

  

<!--#include file="同ディレクトリ内のファイル、または、下位ディレクトリのファイルのパス"-->

 
でインクルードする方法。
 
 
古い方法ですが、非常に有用。
 
でー。Smartyで同じような機能を実現するのが、{include file=’xxx.html’}の記述。
こちらも有用。
 
SmartyのテンプレートをDremweaverで編集するとき、
やはりインクルードの状態をプレビューしたくて、
編集のときは、SSIの表記を埋め込んで編集。
アップするときは、{include}に置き換え。
というまぁ、とてつもなくめんどくさいことをずっとやってました。
 
よく考えたら、
SSIの記述をSmartyの{include}に置き換える処理を、
Smartyのプリフィルターとして用意しておけばいいじゃん!
ってことに気づきました。
 
ってわけで作成。

function smarty_prefilter_ssi2include($source, &$smarty){
    //<!--#include virtual="ドキュメントルートからのパス">
    $source = preg_replace( 
        '/\<\!\-\-\#include virtual\=\"\/([0-9a-zA-Z\.\/\_\-]*)\"\-\-\>/i',
        $smarty->left_delimiter . 'include file=\'' . $_SERVER['DOCUMENT_ROOT'] . '/' . "$1" . '\'' . $smarty->right_delimiter,
        $source
    );

    //<!--#include file="相対パス" -->
    $source = preg_replace(
        '/\<\!\-\-\#include file\=\"([0-9a-zA-Z\.\/\_\-]*)\"\-\-\>/i',
        $smarty->left_delimiter . 'include file=\'' . "$1" . '\'' . $smarty->right_delimiter,
        $source
    );
    return $source;
}

 
これを「prefilter.ssi2include.php」の名前でプラグインフォルダに保存し(PHPタグを忘れずに)
smartyのインスタンス作成時に読み込むプリフィルターとして「ssi2include」を指定してやれば、OKです。
 
 
なお、インクルードするファイルのパスには半角英数「-」「_」「.」「/」が利用されることを想定しています。
それ以外の文字が入る場合は修正して利用してください。
 
あと、正規表現は実に適当です(^-^;

先日のオープンソースカンファレンス名古屋2010(以下OSC)でキックオフとなった、
seezoo cms
 
OSCで担当の方とちょっとだけ意気投合したので、
帰宅後触ってみたらconcreat5っぽいのでいいなぁと思ったので、
ぜひ、開発(主にEC用のプラグインになるかと思いますが)に参加したい!
と思ったら、
私が普段メインで使っているクララオンラインの専用サーバーのPHPは
Ver5.1.6なので、要件をみたしてない(T_T)
 
とTwtterで嘆いたところ、公式アカウント
json_encode()だけどうにかできれば、5.1でも使えるとのこと!
ありがたい事に、公式ブログでも対応方法を書いていただけた。
ただ、私はマルチバイトを簡単に扱えて、なおかつ、staticでも使えるJsphonのが好きなので、
こちらで対応した(後述)。
 


というわけで、クララオンラインのサーバーにインストールする手順。
 
1)seezoo公式からシステムDL

2)json_encode()を擬似的に作成

3)インストーラーがPHPのバージョンチェックをしているので、これをスキップ

4) 通常通りインストール
 


 
こちらの記事によると、
CodeIgniterのヘルパー関数に擬似的なjson_encode()を作りましょう!
ってなってるんですが、恥ずかしながらCodeIgniterは名前は知ってたものの、使ったことがない!!
 
というわけで、お手軽実装のほうで。
 
まず、JSONエンコードするライブラリ「Jsphon」をこちらからダウンロードして、
解凍してできた
・Jsphon.php
・Jsphonディレクトリ
をsystem/application/libraries/に置きます。
 
次に、system/application/helpers/seezoo_helper.phpを開いて、一番下に
 

if ( ! function_exists('json_encode') ){

    require_once(APPPATH . 'libraries/Jsphon.php');
    function json_encode($data){
        return Jsphon::encode($data);
    }
}

 
を追記。
これで擬似的にjson_encode関数を作れます。
 
upgrade.phpというものもあります。
こっちを使えば、インクルードするだけで使えそうです。(マルチバイトはどうかな…。未確認)
 


次に、インストーラーのバージョンチェックをスキップします。
 
system/application/controllers/install.phpを開いて
 

$viewdata['php_version'] = version_compare(PHP_VERSION, '5.2.0', '>');

 
とされているところを
 

$viewdata['php_version'] = version_compare(PHP_VERSION, '5.1.0', '>');

 
に変更。

ここまでやったら、あとは、普通にインストーラーを走らせれば、
インストールできました。
 
今日はここまで!
これから使ってみながら、開発にも入り込んでいきます!

Pleskで運用しているドメインについて、
各ドメインの設定画面で、
 

 
↑この赤枠のチェックを外せば、PHPのsafe modeをオフにできますが、
Pleskでsafe modeをオフにしても、open_basedirの設定は残ったままです。
 
PEAR MEDB2では、この設定だけではエラーが発生するケースが考えられます。
  
MDB2.phpのfileExists()内を見ると、
拡張機能や各DBへのドライバファイルの存在をチェックするのに、
safe modeがオフのときは is_readable()でファイルをチェックし、
そうでないときは、fopen()でチェックしているようです。
 
MDB2ではsafe modeオフのときのみ、is_readable()が使えないという前提で設計されていますが、
実際はそれだけでは不十分で、is_readable()はopen_basedirの制約もうけますから、
MDB2.phpのインストール場所などによっては、
safe modeはオフであるけれど、open_basedirの設定が残るPlesk環境下では、エラーが発生してしまいます。
 
解決方法は、2つ。
 
1)vhost.confでopen_basedirをno_valueにする。
クララオンラインサイトに説明がありますので、御覧ください。
http://support.clara.jp/clarafaq/index.php?action=artikel&id=45&artlang=ja
 
2)MDB2.phpを改変してしまう。
MDB2.phpの

    function fileExists($file)
    {
        // safe_mode does notwork with is_readable()
        if (!@ini_get('safe_mode')) {
             $dirs = explode(PATH_SEPARATOR, ini_get('include_path'));
             foreach ($dirs as $dir) {
                 if (is_readable($dir . DIRECTORY_SEPARATOR . $file)) {
                     return true;
                 }
            }
        } else {
            $fp = @fopen($file, 'r', true);
            if (is_resource($fp)) {
                @fclose($fp);
                return true;
            }
        }
        return false;
    }

    function fileExists($file)
    {
        // safe_mode does notwork with is_readable()
        if( false ){
             $dirs = explode(PATH_SEPARATOR, ini_get('include_path'));
             foreach ($dirs as $dir) {
                 if (is_readable($dir . DIRECTORY_SEPARATOR . $file)) {
                     return true;
                 }
            }
        } else {
            $fp = @fopen($file, 'r', true);
            if (is_resource($fp)) {
                @fclose($fp);
                return true;
            }
        }
        return false;
    }

に変更する。
 
2のがお手軽かなー。でも、fopenな上に@でエラー制御してるので、パフォーマンスは落ちます。ご注意を。
 
ま、あれですけど、open_basedirとかの制約を受けてる状態で、積極的にPEARを利用しようとするほうが、技術者としては間違っているかもしれませんが(^-^;