ここ数ヶ月、EC-CUBE3をカスタマイズする仕事をしています。私のカスタマイズ方針について記述します。

/src/以下のEC-CUBE3のソースコードに変更を加えない

いろんなサイトや公式のフォーラムでEC-CUBE3のカスタマイズ方法について語られています。その中に、/src/以下のコントローラやアプリケーションクラス、エンティティを修正すれば良いと解説している記事があります。

私は安易にこれらのソースコードに変更を加える事に反対です。/src/以下のファイルはEC-CUBE3のバージョンアップによって、変更が加えられる可能性があります。EC-CUBE3のバージョンアップはセキュリティの面で必ず行うべきで、EC-CUBE3本体のバージョンアップを行わない事はありえないと考えています。

考えてみて下さい。/src/以下にあるソースコードにカスタマイズを行った後、EC-CUBE3のバージョンアップを行い、カスタマイズしたソースコードが上書きされ、行ったカスタマイズが全て無効になった時の事を。

変更点を洗い出し、またソースコードに実装しなければなりません。そんな無駄な事はやりたくありませんよね。

カスタマイズは全てプラグインで行う

カスタマイズ用にプラグインを作成しましょう。

EC-CUBE3にはフックポイントといった拡張ポイントが用意されています。フックポイントに対する処理をプラグインで実装しましょう。

既存の機能にないページを新規作成する場合は、プラグインにコントローラやフォーム、twigファイル等を作成しましょう。

ルーティングの切り替え

既存のルーティングをごっそり別の処理と置き換えたい場合、Eccube/ControllerProvider/FrontControllerに修正を加えないようにしましょう。

プラグインのServiceProviderクラスでバインドし直しましょう。

こうする事で、既存のルーティングを全く別の処理と挿げ替える事ができます。

サービスクラスに機能を追加

既存のサービスクラスに機能を追加したい場合、既存のサービスクラスには修正を加えないようにしましょう。

プラグインに既存のサービスクラスを継承したサービスクラスを作成し、プラグインのServiceProviderクラスで、/src/Eccube/ServiceProvider/EccubeServiceProviderクラスでサービスを登録しているキーを用いて登録し直しましょう。

こうする事で、EC-CUBE3本体のソースコードを汚染せずに、既存のサービスクラスへ処理を追加できます。フックポイントでどうしても対応できないカスタマイズを行う際に、この手法を用いました。

EC-CUBE3のテーブル構造には変更を加えない

データベースについて。

例えば、会員をカスタマイズして何か保存したい値を追加したい場合、会員テーブルには変更を加えないようにしましょう。

会員拡張テーブルを新しく作成して、会員IDと保存したい値を保持する為のカラムを用意し、doctrineのエンティティ定義ファイルで関係性を定義し、会員テーブルを参照するようにしましょう。

こうする事で、将来的にEC-CUBE3がバージョンアップし、テーブル構造に変化があった場合に、追加したカラム名が衝突するようなトラブルを回避できます。

最後に

基本的に、このような方針でカスタマイズを行っています。簡潔にまとめると、こういう事です。

”EC-CUBE3のソースコードやデータベース構造に修正は行わない。修正は全てプラグインを作成し、それに行う。”

今後、EC-CUBE3のカスタマイズに関する記事を書いていこうと思っています。