カスタマイズ(拡張編)

EC-CUBE の各ページ(画面)は「Pageクラス」と呼ばれるファイルに処理内容が記述される。 (/data/class/pages/ 配下)

カスタマイズする場合は、前述の「Pageクラス」は変更せずに、拡張用のクラスである「拡張Pageクラス」(/class_extends/page_extends 配下)に実装するのが理想的とされているというアイディアが過去にあった。

サイトのトップ(Home)にランダムに挨拶を表示するという例を説明する。

/data/class_extends/page_extends/LC_Page_Index_Ex.php

      /**
       * Page のプロセス.
       *
       * @return void
       */
      function process() {
+         $arrMsg = array ('おはようございます。', 'こんにちは。', '良い天気ですね。');
+         // ランダムに選んだ挨拶をテンプレート変数「tpl_number」に割り当てる。
+         $this->tpl_message = $arrMsg[array_rand($arrMsg)];
          parent::process();
      }

/data/Smarty/templates/default/top.tpl
※ ファイルの場所は異なる場合がある。参考→ファイルの編集

  <div id="flasharea">
    <img src="<!--{$TPL_DIR}-->img/main/image.gif" alt="EC-CUBEイメージ" />
  </div>
+ 店長からの挨拶「<!--{$tpl_message|escape}-->」

これで、サイトのトップの挨拶文が毎回変わっているように見える(実に無意味な機能です 笑)。

現実的には拡張を使うことで面倒な状況に遭遇することがある。

• バージョンアップが面倒になる。(カスタマイズ部分に相当する箇所の本体ソースが改訂された際に、マージを自動化できないため、状況が面倒になる。また、問題が発生している事自体に気づきにくくなる。)
• (どういったカスタマイズを行っているかが明確となる反面) 本体ソースとの流れが途切れるため、全体を通した流れを把握しにくくなる。
  • 特に grep 等による処理分析では、著しく状況が悪かった。
• EC-CUBE 2.11 では、クラス変数がローカルスコープ変数に変更されている部分があり、拡張に適さない状態が発生している。
• 決済モジュールによって、拡張クラスファイルが上書きされ、いつの間にか意図しない動作となる。
• PHP の仕様により、コンストラクタの動作が分かりにくくなる。
• セキュリティパッチの当て漏れを助長する。(特にメソッド丸ごとコピペとかすると最悪。「ダメ絶対」です。)
• EC-CUBE 本体ソースに拡張クラスの使い忘れが頻繁に見られる。その場合、拡張クラスは利用されず、当該箇所ではカスタマイズ漏れの状態となる。

• http://svn.ec-cube.net/open_trac/wiki/%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA%E3%81%A8%E7%A7%BB%E8%A1%8C%E3%81%AE%E6%89%8B%E5%BC%95%EF%BC%88v2.0%EF%BC%89

• ファイルの編集