プラグインがある場合は慎重に

プラグインがある場合は慎重に

　プロジェクトでプラグインを使用している場合は特に注意が必要です。プラグインに含まれるスクリプトがsymfony 1.1でなくなってしまったメソッドにアクセスしていたり、存在しない設定を使用している可能性があります。とりあえずプラグインをインストールしている場合は、該当するプラグインのwiki（http://trac.symfony-project.com/wiki/SymfonyPlugins）を見て、symfony 1.1用のバージョンがあるかどうかを確認しましょう。

　symfony 1.1用のバージョンがあれば、それを使用します。とはいっても、新しいバージョンできちんと動くかどうかはわからないので、情報を探すなどの手間がかかってしまいます。symfony 1.1用のバージョンがないのであれば、古いバージョンでも動くかどうかテストする必要もあります。もし動かなければ、あきらめるか自分で何らかの修正をする必要がありますが、その場合は手間もかかってしまいます。

　例えば、ユーザ管理を行うsfGuardPlugin（http://trac.symfony-project.com/wiki/sfGuardPlugin）の場合はsymfony 1.1用のバージョンが用意されているので、そちらを使用します。古いバージョン（1.1.13）では、エラーが発生して使用することができませんでした。

　また、sfGuardPluginの場合、モジュールが含まれており、そのモジュールのアクションファイルをオーバーライドしている場合はStrict Errorが出るでしょう。これは、symfony 1.1ではアクションの実行メソッド（executeXXX）の引数にリクエストオブジェクトを取れるようになったことが関係しています。

　また、次回に詳しく紹介したいと思いますが、バリデーションの仕組みの変更などもあるので、sfGuardPluginのようなモジュールが含まれるプラグインでは、カスタマイズして使っている場合は、それだけでアップグレードに手間がかなりかかりそうです。

結局アップグレードした方がよいの？

　小さなプロジェクトをアップグレードしただけでも、かなりの手間がかかりました。やはり情報が少ないので、何が原因で動かないのかを判断するのにそれなりに時間がかかります。もしアップグレードする場合でも、情報が出そろった段階で実行した方が既知の問題も増えますしリスクは減るでしょう。

　ただ、今回筆者が手こずったのは、作り方の問題であったり、プラグインでの問題の修正であって、それ以外のドキュメントで説明されている部分に関しては、わりとすんなりと解決することができました。

　現状でアップグレードを考えるのであれば、ある程度の労力をかけて問題を解決し、十分にテストを行うことを覚悟する必要があるでしょう。筆者の感覚としては、現状すでに動いているプロジェクトに関しては、とりあえずアップグレードにチャレンジし、時間がかりそうであればあきらめてsymfony 1.0を使い続けた方がよいと思っています。

　プロジェクトの大きさでアップグレードにかかる労力が変わるか、と言えばそれほどは変わらず慣れてしまえばそれほど時間はかからないでしょう。