サーバーをMySQL5.0から5.5に変えたら、symfony1.2+propelでbuild:allした際に生成されたSQLがエラーで動かなくなりました。

このようなエラー

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘Type=InnoDB’ at line 13

MySQL5.1以降で、テーブルのエンジン指定でtype=が使えなくなり、engine=と書かなければいけなくなったようです(table_optionのところ)。propel1.4以前のジェネレーターでは”type=InnoDB”のようなSQL文を生成しているので、古いpropelを使っているsymfony1.xではMySQLを5.1以上に変更した際にテーブルが生成できなくなってしまいます。

symfony1.2がpropel1.3-devを更新することはなさそうなので、これを回避するには、自分でpropelにパッチをあてることになります。

(symfony)/lib/plugins/sfPropelPlugin/lib/vendor/propel-generator/classes/propel/engine/builder/sql/mysql/MysqlDDLBuilder.php

163行目の

$script .= “Type=$mysqlTableType”;

を、

$script .= “Engine=$mysqlTableType”;

に修正。

by @akky
symfony1.x+propel1.3+MySQL5.1/5.5で生成したSQLのCreate TableがType=InnoDBで失敗する場合の対処法

mongodはデフォルトで、port 28017 にアクセスすることでブラウザから動作をモニターできる、というのをSymfony2勉強会で教えてもらいました。

このHTTPインタフェースは、/etc/mongodb.conf に

nohttpinterface = true


のように設定することで止められます。(設定できる項目についてはここ)

しかし、Windowsの場合は? mongodb.conf をmongod.exe と同じ場所においてみましたが、別に読み込んでくれません。

> mongod --config mongodb.conf

と明にファイルを指定することはできましたが、デフォルトのconfファイルの場所というのがあるかはわかりませんでした。

また、このWeb UIからRESTで格納されたデータを参照するためには、

> mongod --rest

のオプションをつけて起動する必要がありました。(デフォルトでオフ)

by @akky
Windows版MongoDBの設定ファイル指定と、Web UI無効化

第一回Symfony2勉強会のために、WindowsマシンにSymfony2の開発環境を構築したメモ [2011-10-14 もろもろ更新]

Windows版のPHP, MongoDBでSymfony2

メモリやディスクがふんだんにある場合は、VMWare等の仮想環境を使ってLinuxなりをインストールする方がいいかと思います。理由は、

• デプロイ先の実機サーバはどのみちLinuxとかが多いだろう
• 上にも関連するけど、各コンポーネントでWindowsでの実績が少なかったり、Windowsだけ動かないバグがあったりするかもしれない

対象は、仮想環境とか動かすといっぱいいっぱいな非力なノートPCでなんとかしたい人ぐらい。

ちなみにこの手順は2004年に買ったLet’s note R3E, Pentium M 1.1GHz, メモリ768MB, HDD40Gに、Windows XP SP3で動作確認しました。

Xamppで手っ取り早く環境を作る

Xampp使います。既にApacheやMySQLが単体で入ってたら、アンインストールか最低でも止めてください。

[更新 2011-01-31] Xampp 1.7.4が正式公開されました。以下の手順の一部の作業は不要となりました

[更新 2011-10-14] Xamppは1.7.7になってますね

Symfony2にはPHP5.3.2以上が必要ですが、最新のXampp1.7.3のPHPは5.3.1です。動きません。しょうがないので、Xamppの次のバージョン1.7.4のベータ版を入れます。これならPHPは5.3.3

> cd \xampp
> setup_xampp.bat
適当なキーを押してインストール完了

xampp for windowsからXamppのインストーラをダウンロードして、実行

> xampp-control.exe
Apacheの[Start]を押す

ブラウザでhttp://localhost/にアクセス。xamppのページが出たらOK。「MySQL動いてないけどいいの?」みたいなことが出る。マシンに余力あればMySQLも[Start]してもよい

Symfony2のダウンロード

Sandboxのzipをダウンロード

[更新] symfony.comドメインに移っているので、Symfony.comのdownloadページからダウンロード

適当な場所に展開(c:\xampp\sandbox)

> cd \xampp\sandbox
> \xampp\php\php.exe check.php
不足している設定がエラー・警告で表示されるのでこれをつぶしていく

Apacheからsandboxを呼べるように

sandboxというドメインでアクセスすることにする。

Apacheの設定ファイルで、バーチャルホストを扱うファイルを編集

> \xampp\apache\conf\extra\httpd-vhosts.conf

NameVirtualHost *:80

# sandboxでアクセスしてきたらC:/xampp/sandbox/webにまわす
<VirtualHost *:80>
  ServerAdmin postmaster@sandbox
  DocumentRoot "C:/xampp/sandbox/web"
  ServerName sandbox
  ServerAlias www.sandbox
  ErrorLog "logs/sandbox-error.log"
  CustomLog "logs/sandbox-access.log" combined
</VirtualHost>

# ファイルへのアクセス権を与え、.htaccess等が効くようにする
<Directory "C:/xampp/sandbox/web">
  AllowOverride All
  Order deny,allow
  allow from all
</directory>

Apache再起動

ブラウザからsandboxでApacheにつながるように

hostsファイルを編集

> notepad \Windows\system32\drivers\etc\hosts

# 追加
127.0.0.1 sandbox

# Windows Vista/7とかだと、管理者として実行とかしないと書き換えられないかも

ブラウザからチェックスクリプトを実行

http://sandbox/check.php

水色で表示されたウォーニングを片付けていく

short_open_tagをオフに

“<?”のこと。これはオフにすべき。

# Xamppのデフォルト設定って…

> \xampp\php\php.ini

short_open_tag = Off
;short_open_tag = On

APCを有効にする

APCについても、Xampp 1.7.4の正式版で同梱されているので簡単になりました

ビルド済みのWindows版dllをphp_apc-3.1.5-5.3-vc6-x86.zip からダウンロード、展開

php_apc.dllをc:\xampp\php\ext にコピー

c:\xampp\php\php.ini を開いて、[PECL]の後ろに

extension=php_apc.dll

XSLTを有効にする

Propel使わないととりあえず不要っぽいけど。php.iniで、

# 追加
extension=php_xsl.dll

posix_isatty() CLI出力に色をつける

PHPのposix関数はWindowsでは使えないとマニュアルにあるので、この警告は消せない

正しいタイムゾーンの設定

何か設定してあれば警告は出ないのだけれど、実はXampp Betaのphp.iniはドイツのベルリン時刻になっている。そこで、php.iniを修正

# date.timezone = Europe/Berlin
date.timezone = Asia/Tokyo

その後ろのデフォルトlatitude/longitudeも自分の緯度経度にしておいても良い。どこで使うか知らないけど

sandboxについてきたアプリの実行

クイックツアー参照

http://sandbox/index_dev.php/

Hello, Fabienアプリ

http://sandbox/index_dev.php/hello/Fabien

MongoDBインストール

ダウンロードページ Windows 32bit

説明

今のstable最新は1.6.3。これをダウンロード (どこでもいいんだけど)c:\xamppに展開

> cd c:\xampp\mongodb-win32-i386-1.6.3
> cd bin
> mongod.exe

おっとエラー。DB置き場は手で掘らないといけない

> md \data
> md \data\db
> mongod
Windowsの警告→ブロック解除

MongoDBクライアントから確認

もういっこコンソール開く

> cd \xampp\mongodb-win32-i386-1.6.3\bin
> mongo
> 1+2
3
で良し
> Ctrl+C

PHPからMongoDBを使えるようにする

説明ここ

PHP MongoDBドライバはpeclなので、自分でビルドするか誰かがビルドしたものを持ってくるかしないといけない。ここは当然後者。ここからダウンロードする

VC6でts(スレッドセーフ)なバイナリをダウンロード mongo-1.0.10-php5.3vc6ts.zip

展開

php_mongo.dllをc:\xampp\php\ext にコピー

c:\xampp\php\php.iniを編集 [PECL]の後ろに

extension=php_mongo.dll

PHPから動作確認

Xampp-controlからApacheを再起動([stop]-[start])

http://localhost/ のxamppからphpinfo()を表示

“mongo”でページ内検索。設定が出てればOK

PHPから動作確認

適当なphpファイルを作る(mongo.php)

<?php

$mongo = new Mongo('localhost:27017');
$fuga = $mongo->hoge->fuga;
$fuga->insert(array('1' => 1));
echo $fuga->count();

実行

php mongo.php

実行のたびにエラー無く、表示される数が増えれば動いている

あとやること

Apache, (MySQL), MongoDBをWindowsサービスとしてインストールすると、PC再起動したときに動くようにできる。Apache/MySQLについてはc:\xamppの下にサービスにするコマンドがあるのでそれらを実行。

by @akky
Windows+XamppでSymfony2開発環境を作る

PHPのフレームワークsymfonyの新しいバージョンがでました!

リリース文

主な変更点はFivestarさんが簡単にまとめられてます。

1.2のメンテナンス期間の終わりを根拠に1.0を使い続けるという人がいて最近悲しかったですが、これで堂々と「新規プロジェクトは1.4で」「1.2は1.3で(可能なら1.4)」とできますね。

メールライブラリとしてSwift Mailer 4が同梱されていますが、まだJISメールの問題が直ってないので、ご注意ください。

単発でsymfony1.3/1.4からメールを送りたいだけなら、日本語JISメールに対応した他のメールライブラリをlib/vendorに突っ込んで呼ぶとかでいいと思います。symfonyとSwift Mailerが用意しているいろいろな技をJISでも活用するには、もう少しお待ちください。

symfonyの導入は、新しい1.3/1.4でも日本語のマニュアルが既に用意されています。

by @akky
symfony1.3/1.4がリリースされましたね

PHPの文字エンコーディングの入力チェックを改善する方法について日本語のブログで議論があり、そのパッチを本家に提案したが、却下された、という話が盛り上がっているようです。

バグレポートされた岩本さん自身や、コメント欄やはてなブックマークでは、

• PHPの開発陣がダメだ
• マルチバイトに理解がない外国人がダメだ
• 残念だ

みたいな意見があまりに大勢をしめているので、そのバグレポートを見てみた上で、思ったことを述べたいと思います。

岩本さんのバグレポートを訳すと、こんな感じです

要約:
------------
セキュリティ的な要件により、htmlspecialchars()はバイト列をもっと
厳密にチェックすべきです。XSSするコードが見つかりました。
http://d.hatena.ne.jp/t_komura/20091004/1254665511 [日]

原始的なパッチを書きました。

http://iwamot.com/misc/html.c.patch.20091006

使えるかどうか知りませんが(笑)

再現コード:
---------------
// 越長 UTF-8 列
echo htmlspecialchars("A\xC0\xAF&",     ENT_QUOTES, 'UTF-8');
// 不正な Shift_JIS 列
echo htmlspecialchars("B\x80&",         ENT_QUOTES, 'Shift_JIS');
echo htmlspecialchars("C\x81\x7f&",     ENT_QUOTES, 'Shift_JIS');
// 不正な EUC-JP 列
echo htmlspecialchars("D\x80&",         ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("E\xA1\xFF&",     ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("F\x8E\xFF&",     ENT_QUOTES, 'EUC-JP');
echo htmlspecialchars("G\x8F\xA1\xFF&", ENT_QUOTES, 'EUC-JP');

予期する結果:
----------------
何も出てこないこと

実際の結果:
--------------
A_&B_&C&D_&E__&F__&G___&
("_"は不正なバイトを意味します)

もしあなたが日本語でオープンソースのプロジェクトをやってて、他にも毎日バグレポートを受けているような状態で、こんな感じのバグレポートが来て、「問題の詳細はこのURL、アラビア語ですけど」みたいに書かれていたとして、この問題について調査を始めたり、優先してこの問題に取り掛かったりするでしょうか? 僕ならしないと思います。

ましてや、”I don’t know whether it is useful though ” 「使えるかどうか知りませんが(笑)」ですよ? こういうのは日本的な謙譲の美徳として日本のコミュニティでは通じても(どこでも通じるかはわかりませんが)、およそ真剣に「この問題について知ってほしい、興味を持ってほしい」という態度とは受け取られないと思います。

それまで、複数のブログでいろいろな人がしっかりした問題点の検証や議論を、かなりの長文の日本語でされていて、日本語でそれらを読んでいる人にとっては問題は自明なのかもしれません。

しかし、PHPの開発は英語でコミュニケーションされてますし、彼らが英語で上のバグレポートに出てくる断片からウェブを検索したとしても、日本語での議論のようなまとまった情報は見つからないかもしれません。

日本語で議論されている皆さんの努力にはとても敬意を払っていますが、最終的な問題がPHP本体を直すことにあるのであれば、英語に持っていって相手を説得するときに尻すぼみになっているのは残念です。

僕も英語でバグレポートするのは大変ですし、岩本さんのレポートも、パッチもあるし問題の背景が共有されているなら十分だとは思いますが、何が問題で、直さないとどういう問題が起こるか、起こったとして被害の大きさはどれぐらいか、修正がこれまでの他アプリにどんな副作用を起こしうるか(あるいは起こさないか)、といったことを書かないと、むしろ取り合わないのが普通じゃないかと思います。

はてなブックマークのコメントで書いたところ、岩本さんからこう追記をいただきました。

id:AKIMOTOさんに限らず、私のレポートの仕方が悪かったせいだと思われる方、ぜひ本件を引き継いでいただけないでしょうか。私の望みは htmlspecialchars の文字エンコーディング妥当性チェックが改善されることであって、どなたかが達成されるのであれば、それで万々歳です。採用されるレポートの書き方もそれで分かるでしょうし。

他人の英語について何かコメントしたら、こういう返しをされるだろうな、というのはわかっていました。

しかし、それぞれの人はそれぞれの優先順位があります。この問題が無視できる問題だ、とは僕は思いませんが、僕自身がこの先解こうとしている他の問題に比べれば、自分で引き継ぐほど差し迫った不利益を受けていませんし、また、議論されているみなさんほど、この問題について精通してもいません。英語が書けるというだけで、誰もが替われるような話ではないでしょう。少なくとも僕にはこの件の翻訳ボランティアになる動機がありません。

ただ、それが「自分に取って優先順位の高い問題で、どうしても通したい」ときにどうしてるか、は紹介できるかと思います。

ちょうど昨日、僕も一本のバグレポートを書きました。主な興味の対象のレイヤーが違うのですが、PHPのメールライブラリSwift Mailerのバージョン4に関するもので、日本独自仕様の提案に関係するものです。

具体的には、NTT Docomoなどが過去に間違って導入した、RFC違反の形式でピリオドを持つメールアドレスを受け付ける特別なモードを導入してほしい、というものです。

PHPとSwift Mailerではレイヤーも規模も、何もかも違いますが、

- 何が問題なのか
- その問題に他のアプリケーションはどう対処しているのか
– mail addressの場合、iPhoneやGmailが日本市場向けに何をしているか書きました
– 文字エンコーディングの入力チェックの場合、他の言語や処理系でどう扱っているか、というような話になるかと思います
- その変更を採用することで、既存のユーザーに影響するか
– 今回は影響するもの、影響しないものを合わせて複数の取りうる修正案を併記しました

といったことをまとめ、何が問題で、どうしてこんなばかばかしいRFC違反のメールを受け付けられることが日本の一部のユーザーにとって(ひいてはSwift Mailerの日本での普及にとって)大事か、というのを伝えようとしたつもりです。なんといっても、こんな修正日本以外のユーザーには何のメリットもないですからね。

# ちなみにこのレポート書くのに何日もかかってます。英語でブログ書いてるからといって、複雑な内容を一瞬で書けるわけではもちろんないです。

このメールの件は、いわば「悪い仕様を追認する」汚い修正なので、念入りにiPhoneなど他社の対応状況も添えましたが、PHPのエスケープで起こる問題が本当に筋のいいものであれば、これまでの日本語での議論をきっちりまとめて伝えることで、それよりは受け入れやすいのではないかと思います。

英語でバグレポート書くのも大変でしょうし、却下されれば凹みもするでしょうけれど、それを日本語に持ち帰ってきて「残念だ、残念だ」と騒いでも、それは決して相手に伝わらないですよ。

はてブコメントで「残念」と書いている人の中に、そのバグレポートを開いて見てみた人がどれぐらいいるんでしょうか。

「いつもの同じ問題」じゃないとわからせるには、わからせるだけの証拠を積み上げて見せないといけないし、バグレポートで届かないなら、(英語の)ブログを書いたりサイトを立ち上げたり、メーリングリストで問題提起したり、却下した本人にメールしたり、いろいろとあるのではと思います。

この問題で議論されているみなさんの努力、バグレポートまで書かれてチャレンジされた岩本さんの努力には(一PHPユーザーとして)たいへん感謝していますが、努力することが重要なのじゃなくて、どうやって自分(達)の意を通すかが大事ではと思います。それが「PHPのせい」「コアチームのせい」「英語のせい」「外国人のせい」で終わってしまうとしたら、僕はそれが残念です。

# あと、↑途中書いた僕自身のスタンスをよく読まずに「じゃあお前やれば」とコメントしないでくださいね。僕の次のバグレポートは、Swift Mailerでのiso-2022-jpサブジェクト行のエンコード&行分割に関するものになる予定です

[追記 2009.10.09]

徳丸浩さんが、PHPが今すぐ直らないとしても実施できる、このセキュリティホールが起こりうる条件と、その回避法についての解説をまとめられています。

[追記 2009.10.09]

moriyoshiさんが最初のバグレポートをcomitしてくださいました。ありがとうございます。

将来のマイナーアップデートリリースでこの問題は解消されるでしょう。実際に今このセキュリティホールが有効になる条件下のアプリケーションを運用されている方は、個別にパッチをあてたPHPをビルドして差し替えるか、上の徳丸さんの対策を行なう必要はあります。

by @akky
外国語ならなおさら、できる限りのことをしないと伝わらない

PHPカンファレンス当日でいろいろと連絡が滞っていてすみません。

6(日)昼の「symfonyのFabienさんと東京観光」は予定通りやります。これまで参加を表明された方は、朝10:00に四谷に集まると思っていてください(途中から参加とか遅れる人のために、あとでメールで詳細は送ります) まだ人数増やせると思うので参加表明はこちらを読んでください。

6(日)の夜、こちらも四谷近辺で、Symfony Meetupをやります。懇親会です。いい機会なのでsymfony使いで集まってゴハンを食べましょう。

申し込みフォーム

Symfony Meetup Tokyoは盛況のうちに終了いたしました。参加くださったみなさま、ありがとうございました!

by @akky
Symfony Meetup Tokyoやります

PHPカンファレンスの開催がいよいよ明日・明後日となりました。

今回は、10周年ということで海外からも3名の講演者をお呼びしての充実したカンファレンスとなっています。(参加は両日とも満員で締め切っています)

symfonyのリーダーFabien Potencierさん、FacebookのBrian Shireさん、台湾PHPユーザー会の江 明宗さんのお三方は、なかなか東京で話せる機会もないと思いますので、ぜひ取材等いかがでしょうか? (拙いですが通訳できます)

特に、カンファレンス当日はPHPカンファレンスのメディアスポンサー各社(スポンサーありがとうございます)のみなさまに、ぜひ取材いただければと思います。

ご興味ありましたら、ぜひPHPカンファレンスでお声をかけていただくか、akimotoアットgmailかtwitter.com/akkyまで御連絡ください

by @akky
技術メディアのみなさん、symfonyのFabien Potencierさんへの取材どうでしょう?

symfonyユーザーの皆様

きたる5日(土)のPHPカンファレンス2009テックデイでは、symfonyのプロジェクトリーダー兼Sensio社の社長であるFabien Potencier(ファビエン・プートンシェ)さんがはるばるフランスから初来日し、symfonyプロジェクトについて講演されます。

今回が初来日、また講演の翌日6日(日曜日)がオフということで、Fabienさんと一緒に日本のsymfonyコミュニティ(ユーザー/開発者)のみなさんとめぐる東京一日観光を行ないます。

二日間のPHPカンファレンスの直後でお疲れかもしれませんが、symfonyの今後についてやプロジェクトの要望などについて直接Fabienさんと話せる貴重な機会になるかと思います(通訳は有志2,3名でお手伝いしますが、ちょっと勇気を出して直接英語で、あるいは仏語でお話してみるのもよいかと)。

ツアー名: (仮)symfonyについて語りつつ一日東京観光
日時: 2009年9月6日(日) 朝から夜まで
場所候補(検討中): 浅草寺・秋葉原・皇居・明治神宮/原宿・まだ大地に立ってればお台場ガンダム・都庁展望台・他に面白いところあれば
移動手段: 電車/徒歩メイン
参加資格: symfonyを使ってる、使いたい、これを機に○○○○○○○から切り替えてみようかな、という人。あと昼食夕食場所の手配とかもろもろ手伝ってくれる人
予定人数: 多くて10人ぐらい? そこまで居ないと思いますが、20人とか30人とかになったらたいへんかもと思いますがどうでしょう?

申し込み: 「a k i m o t o あっと gmail どっと com」へ、サブジェクトに「symfony東京観光参加希望」と入れてください。金曜夜締め切り

by @akky
symfonyのFabienさんと東京一日観光

symfonyでsuper cacheを実現するsfSuperCachePluginの、symfony1.2での使い方について。

super cacheは、動的にページを生成するWebアプリケーションにおいて、ほとんどの場合にWebサーバの仕組みを使って静的に作成したhtml(等)を直接クライアントに返すことでサーバの応答を早くし、サーバの負荷も軽減する手法です。

よく知られているのはWordPressのSuperCacheプラグインです。これを正しく設定すれば、動的生成でありながら静的生成のパフォーマンスを持つブログを運営することができます。

これまで自作でsuper cache相当の仕組みを作ったことはあるのですが、symfonyのプラグインがあるのでこれが使えるかどうか調べてみました。

とりあえず、READMEにあるように進めてみます。

プラグインのインストール

まず、プラグインはsymfony1.0にしか対応していませんので、普通にsymfonyコマンドでインストールしようとするとエラーになります。

コマンドインストールで失敗したときはいつもそうですが、パッケージを持ってきて自分で展開してみます。バージョンチェックが入ってるだけのことも多いので、これで動いてしまうプラグインも多いです。

> wget http://plugins.symfony-project.org/get/sfSuperCachePlugin/sfSuperCachePlugin-1.0.5.tgz

展開したら、sfSuperCachePlugin-1.0.5 というフォルダを、symfonyの作業フォルダ以下の plugins/sfSuperCachePlugin というフォルダにリネームしつつコピーします。

あとは、pluginsの下のプラグインを全部読むようになっていればsymfony ccするだけで自動的にロードされます。なってなければ、config/ProjectConfiguration.class.php のsetup()で、enableAllPluginsExcept()等を使って読み込まれるプラグインに指定してください。

このまま先へ進んでいくと、1.0と1.2の非互換でエラーになります。先に修正箇所を示すと、sfSuperCacheFilterの次の行


$uri = sfRouting::getInstance()->getCurrentInternalUri();


を、以下のように変更する必要があります。


$uri = sfContext::getInstance()->getRouting()->getCurrentInternalUri();


キャッシュ格納ディレクトリの用意

(symfonyアプリ)/web 以下に、静的ファイルの置き場を作ります。READMEにならって”cache”ディレクトリにします

> cd web
> mkdir cache

Un*xの場合はオーナーやパーミッションも調整してください

フィルタを噛ませる

プラグインの中に入ってるphpは、フィルタファイル一個だけです。これを(frontend)/filters.yml の # insert your own filters here のところに追加します。

supercache:
  class: sfSuperCacheFilter
  param:
    cache_dir: cache
    with_host: false

ホスト名を複数持たないならwith_hostはfalseでいいです。持つ場合、この後の設定も準じて変わるのでREADMEを読んでください。

リクエストがまず静的ファイルを見に行くように、.htaccessを修正

web/.htaccess を書き換えます。以下の2行のところを、


RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]


たとえば、以下のように書き換えます。


RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{DOCUMENT_ROOT}/symfony_apps/sandbox/web/cache/supercache/%{PATH_INFO}.php -f
RewriteRule ^(.*)$ cache/$1.php [L]


この書き換え、READMEについてきたREQUEST_URIを使ったものが動かなかったので、自分で動くものを探してこんな風にしました。サブディレクトリにアプリを置いたりしなければREADMEのままのでも動くのかも。mod_rewriteは難しくてよくわからんです。

mod_rewriteが思うように動かないときは、とにかくhttpd.confの設定でrewrite logを取り、出たログを読みましょう。

やってるのは、


web/cache/ほげほげ/ふがふが.php


というファイルがアクセスされて、もしそれがあったら、そのファイルを直に実行して表示してしまう、という処理です。

もしファイルが無かったら、mod_rewriteの処理は下方のルールに落ちて行って、いつものフロントエンドコントローラ(web/index.php)を呼ぶようになっています。

これで、staticファイルが出来てればそのまま表示、出来てなければsymfonyを普通に実行(し、filters.ymlで挟んだフィルタがstaticファイルを生成)、というsuper cacheが完成となります。

super cacheを動かす条件

フィルタファイル sfSuperCacheFilter.class.php の中を読むとわかるのですが、super cacheが発動するには、いろいろな設定がされている必要があります。そうしないと、super cacheを動かしてたつもりが普通のキャッシュされたファイルを見てたりすることにもなります。

• sf_cacheがtrue/onであること
• $_GETや$_POSTのパラメータが無いこと
• sf_debugがfalseであること、つまりデバッグモードでは呼ばれません
• sf_no_script_nameがtrueであること
• エラーコードが200(正常)であること。エラーページとかを403で返しているなら、それはsuper cacheの対象外です
• そのmoduleのdefault cacheが enable: on であること
• そのmodule/actionの cacheが enable: on であること
• そのmodule/actionの with_layout: がtrueであること

キャッシュを使うことになってるページで、ページ全体をキャッシュして問題無く、GET/POSTパラメータも渡ってこない(パラメータが違えば普通ページ内容も変わりますから)という条件。

これ全部満たして、はじめてsuper cacheフィルタが効きます。

sfSuperCacheFilter::execute()のチェック文を、デバッガ等で確認しながらsettings.ymlやcache.ymlの設定を変え、(symfony ccもして、)動く設定になってることを確かめてください。

superキャッシュの動作確認

この状態でモジュールをつくり、適当にアクセスしてください。

frontend_dev.phpとか呼んじゃダメですよ。debug offなのでprodである/ (= index.php)を呼びます。


web/cache/(アプリ名)/(モジュール名)/(アクション名).php


などとファイルが出来ていたら、まずフィルタによるstaticファイル生成は合格です。

次に、もう一度アクセスしたときにこの生成されたファイルが開いてるのか、それともsymfony標準のcacheが開いてるのかを確認します。これは、cache/frontend/prod/template/… 以下の標準のキャッシュファイルを手で消してから、ブラウザでアクセスしてみるとわかります。staticなファイルが呼ばれて開かれていれば、標準のキャッシュは作られないはずです。

super cache完成か?

とまあ、プラグインで用意されているのはここまでです。しかし、生成されたstaticなファイルは拡張子が.phpなんですね。そこでそれらのファイルをエディタで開くと、先頭にphpのコードが一行入ってます。


<?php if (time() > 1241771234) { unlink(__FILE__); header('Location: '.$_SERVER['REQUEST_URI']); exit; } ?>


これで、自身のキャッシュ寿命を計りつつ、もし寿命が来ていたら自分自身を削除してもう一度同じURLにリダイレクト、とすることで、expireの処理を行なっているようです。

と、いうことは、このsuper cache、phpを回避してないのですね。厳密には super cacheと言えないのではと思います。たとえ一行とは言え、phpインタプリタをファイル毎に起動しているのです。

このプラグインはここまでなので、PHPを完全にスルーするsuper cacheの実現には、もう一手間かける必要があります。

生成するのは.phpじゃなく.htmlにし、もちろん先頭にphpコードは入れません。.htaccessの定義も.htmlに変えます。

そうなると、キャッシュのexpire判定は自分でやらせるわけには行きません。別のトリガーでこのキャッシュファイルを消すことになります。

たとえば、cronで動かしたスクリプトで定期的にこのcache/以下を見て、ファイル生成時を見つつ古すぎるものを消す、が一案。

もう一つは、CacheManagerで明示的にキャッシュをクリアされるタイミングで、このcache/以下の該当する静的ファイルも削除することです。

super cacheで用意したcache/以下のキャッシュファイルは、先頭行のPHPでexpireを自己診断した際しか消えないので、どのみちCacheManagerでのクリアをどうするかというのは検討しないといけないですね。

by @akky
symfony1.2でsfSuperCachePluginを使う

変なスクリーンセイバーを愛用してると、プレゼンテーションで大恥かくかもしれませんよ。ご注意!

Embarrassing porn screensaver during a presentation. [NSFW] – The Next Web

by @akky
プレゼン中にすごいスクリーンセーバーが発動する動画

syfony1.2系のアップデート1.2.6が出ました。

セキュリティリリースということで、唯一件のバグ修正となっています。

1. symfonyのアドミンジェネレータを使っている人で、
2. unset()を明示的に呼ばずに
3. generator.ymlに書かないことでフィールドを隠すような使い方をしていた場合に、

攻撃を受ける可能性がある、というのをコアチーム内のレポートで発見し、修正したということです。

上記に当てはまるようなコードを書いた人で1.2.x系全部と次の1.3系ブランチを使っている人は、アップデートするか、パッチを当てるか、unset()を必ず呼ぶコードに直すか、するべきだということです。

# で、あってると思いますが、必ず原文にも当たってください

by @akky
symfony1.2.6セキュリティリリース

なかなか思うようにいきません…

by @akky
Google App EngineでPHP

ここのところ普段と違うパソコンを使っているのですが、そこでPHP/symfonyの開発環境を構築する必要があり、ひさしぶりに、Windowsの簡単ウェブ開発環境インストーラXamppを使ってみました。

# 普段はビルド済のPHPとMySQL, Apacheをダウンロードして入れています。これでも手抜きと言われるかもしれませんが

xamppのサイトから、Windows版 1.7.0 ベーシック版 インストーラ(xampp-win32-1.7.0-installer.exe)というやつをダウンロードして実行するだけです。

それで、xamppについてくるサンプルや静的なページは問題なく動くのですが、symfonyで作ったアプリケーションを呼び出そうとすると、PHPがApacheを巻き込んで落ちてしまいます。

Apacheのログにはこんなエラーが

いったいこれは何だ、ということで類似の問題が起こってないか検索してみたところ、このフォーラムにたどり着きました。XAMPP 1.7.0のインストーラが展開するdllが、XAMPPの中のMySQLと合致していないために起こると読みました。

フォーラムに書かれているとおり、

c:\xampp\php\libmysql_5.0.51a.dll

c:\xampp\php\ext\php_mysql_5.0.51a.dll

c:\xampp\php\ext\php_mysqli_5.0.51a.dll

を、それぞれ”_5.0.51a”のない方に上書きすることで、エラーは無くなりました。問題が解決するdllまで一緒に配布しているということは、原因は把握されてるんじゃないかと思うのですが、なんでこうなってるんでしょう。今これをやってるのがWindows 2000なので、XPやVistaでは問題ないのかしら。

というわけで、XAMPPで簡単にPHP開発環境ができることは確認できたのですが(上記の問題で何時間も使ったので簡単でもないという話も)、XAMPPの設定するphp.iniはいくつか微妙ですね。いまどきmagic quoteオンとかshort tagオンとか。E_NOTICEがオフになってたのでオンにしたら、XAMPP自身のトップページが警告を出しちゃうし。

WindowsのXAMPPでそのまま本番環境にする人はあんまりいないだろうとは思いますけど、万一自宅サーバとかでそういうことをするなら、php.iniは上から下まで読んで設定しなおしたほうがよさそうです。

[追記] Windows XPでも同様のエラーになるそうです

by @akky
XAMPP 1.7.0でMySQLアクセス時にApacheが落ちるとき

symfonyで、キャッシュが効いているページを強制的にクリアしたいとき、

  $cacheManager = $this->getContext()->getViewCacheManager();
  $cacheManager->remove('quiz/index?id='.$quizIdToRemove);

とかやってたのですが、デバッグ環境でエラーが出てしまいました。

Fatal error: Call to a member function set() on a non-object in ...

実環境でエラーにならないのでうんうん悩んで調べてみたら、デバッグ環境ではcache: off にしてました。getViewCacheManager()はキャッシュ使ってなければnullを返すようです。

# 考えてみたら当たりまえか

問題は、これがfatal errorで止まっていたためにトランザクションが完了していなかったことです。

cacheManagerを取得したときは、必ずnullチェックして、キャッシュが使われてるときだけ呼び出しましょう。 > 自分

by @akky
symfonyのキャッシュマネージャーが取れないとき

先月の第40回PHP勉強会@関東は、スペインからDelphi for PHPの作者Jose Leonさんを迎えてのスペシャルだったわけですが、Joseさんの日本滞在の感想等が彼のブログで上がっていたのでご紹介しておきます。

Delphi for PHP » Developer Summit 2009 – Japan

デブサミ初日の感想。参加者の多さと熱心さに感心されているようです

Delphi for PHP » Developer Summit 2009 – Japan (II)

デブサミ二日目。彼自身のセッションがあったことの報告です。そのあと、各メディアとのインタビューに臨んだようです。

Delphi for PHP » PHP Camp

PHP勉強会とそれに続く泊まりでのハッカソンの感想。勉強会で発表されたOpenPear等にも言及されてます。

Delphi for PHP » Developer Camp 2009 and Open Source Conference at Japans Electronics College

オープンソースカンファレンス(OSC)の感想。写真が「日本」ですね。カメラ量販店の技術書棚も印象に残った様子。

Matzことまつもとゆきひろさんとのツーショット写真も。Delphi for Rubyの可能性について話したとか。

最後は、取材を受けて日本で記事になったページをそれぞれ紹介しています。

by @akky
Delphi for PHP作者の来日記まとめ

本家ブログでの発表から。symfony APIの検索フォームが、OpenSearch APIで提供されるようになりました。

syfony公式ページに行くと、ブラウザ右上のサーチボックスが変化して、OpenSearchに対応していることを示してくれます。Firefox3ではこんな感じ。

symfony API 1.2を追加

すると、このあと、サーチボックスでsymfony APIが選べるので、ここにsymfonyフレームワークのクラス名や関数名を入れると、

APIマニュアルの該当ページにジャンプします。

by @akky
symfony APIがブラウザから直接検索できるように(OpenSearch API)

エラーメッセージでは

Could not create directory ‘/home/(ユーザ名)/.ssh’.

とか出ますが、cygwinが認識するあなたのホームディレクトリはC:ドライブのルートとかではなくてcygwinのインストールディレクトリなので、たとえば、

C:/cygwin/home/akky/.ssh/

というディレクトリを作れば、そこにsshの設定を書き込んでくれます。

‘.ssh’というドットで始まるディレクトリの作り方は、.htaccessとかのファイルの時と同様ですが、GUIでは作れない(エラーになる。ムキー)ので、”ssh”とでもして作っておいて、コマンドプロンプトでその”ssh”があるディレクトリへ移動して、

> ren ssh .ssh

でその名前にできます。

cygwinの設定ファイルを変更してまったく別のディレクトリを使う手もあると思います。あくまで一例。

symfonyのsync(1.0の場合)、project:deploy(1.2の場合)がsshを呼び出す場合に上のエラーが気になる場合の対処でした。

by @akky
Windows+cygwin+sshで”Could not create directory”が出るとき

symfonyのプラグインはPEARのパッケージシステムを使っているのですけど、PEARのパッケージングって結構面倒で、僕はあまり好きではありません。PEARにもパッケージを作るためのツールがあるのですが、PHPのスクリプトを書くことになります。

symfony1.2には、symfonyのパッケージを作ることに特化したタスクがsfTaskExtraPluginという名前で提供されています。

まだalpha版なので、alphaを明に指定してインストールします


$ symfony plugin:install -s alpha sfTaskExtraPlugin


このプラグインの中のパッケージ作成コマンドを呼ぶと、plugins/ディレクトリの下にある特定のプラグインを、PEARパッケージにしてそこに作ってくれます。


$ symfony plugin:package sfFaqPlugin


これだけで、plugins/sfFaqPlugin/sfFaqPlugin-1.1.0.tgz ができます。(プラグイン名やバージョン番号はサンプル)

プラグインになっていれば、symfonyコマンドでinstall/uninstallを管理できます。


$ symfony plugin:install /sandbox12/plugins/sfFaqPlugin/sfFaqPlugin-1.1.0.tgz


そこにあるpackage.xmlを使ってパッキングしてくれるので、xmlを開いて適度に編集することでバージョンや含むファイルを変えることができます。package.xmlが無い場合は、対話形式でpluginの説明や開発者の名前などが尋ねられるので、順番に入れていくとpackage.xmlも作成してくれます。

なので、たとえば、symfony1.0でしか動かないとpackage.xmlに書いてあるせい「だけで」symfony1.2にインストールできないpluginがあったとしたら、それをtarでplugins以下に展開して、package.xmlのrequire versionだけ1.3未満までオッケーにし、このタスクでパックすれば、1.2対応のpluginができるということです。

もしそういう風に1.2非対応のプラグインを1.2で使って、実績もあるなら、前のエントリで書いたように開発者になって公式サイトにアップするのもいいでしょう。

sfTaskExtraPluginには他に、pluginsの下に一からプラグインを作るためのgenerate:plugin、pluginの中にmoduleを追加するgenerate:plugin-moduleがあります。これらで生成したスケルトンには、テストコードの枠組みも最初からついてきます。

by @akky
[symfony] プラグインを簡単に作るためのプラグインsfTaskExtraPlugin

symfony公式サイトの”Plugins”に行くと、数百個のプラグインが提供されています。これらは、インストールするだけでsymfony製のサイトに新しい機能を付け加えるものです。

プラグインを作って登録したり、既にあるプラグインの開発に参加したり、バグ報告をするには、まずsymfony-projectサイトのユーザ登録をする必要があります。メールアドレスだけあれば、右サイドバーの”Create an account”から誰でもユーザ登録ができます。

ログインした状態でプラグインの個別ページ(例 sfFaqPlugin )へ行くと、”Contribute(貢献する)”というタブがあります。ここで、

• developer: svnにアクセスできる開発者
• packager: developerに加えて、プラグインの新バージョンをリリースできる開発者
• leader: 全権限を持つプラグイン開発のリーダー

のどれになりたいかを選び、下のコメント欄には「何をどう直したいか」を書き込んで送信すると、既存の開発者に連絡が行きます。

symfony1.0でしか動かないプラグインは、元の開発者がメンテナンスを止めている場合もあるので、パッケージの1.2対応をしたいと思ったら、ここからどんどん申請して開発チームに入ることができるようです。

by @akky
[symfony] 既存プラグインの書き換えを手伝うには

symfony1.2の管理画面自動生成機能を使うと、

$ symfony propel:generate-admin backend Post


だけで、Postクラスのオブジェクトを一覧して追加表示更新削除する画面を作ってくれますが、なぜか画面にデフォルトの管理画面のデザインが適用されず、アイコン類も出ないというのでつまりました。

呼べていない画像に/sfPropelPlugin/というパスがついてるので、それで検索をかけたら、同じ問題ではまってる人が公式フォーラムに。しかし、二人居て二人ともすぐに自己解決してます。

「脚注じゃなくて本文に書いてよ」とボヤかれていたので、マニュアルを見返したら、ちゃんとマニュアルに書いてありました。

$ symfony plugin:publish-assets


これを呼ばないと、generatorで作られた管理画面から呼ばれるCSSや画像ファイルがアプリの/web以下にコピーされないんですね。プラグインに含まれているCSS, 画像, Javascriptなんかを見える場所に移してくれるのがこのコマンドでした。

by @akky
[symfony] admin generatorでデザインがあたらないとき