目次
- 目次
- Requirements
- ここは、初心者に優しいECCUBE3のページ。
- 環境
- 対象読者
- ECCUBE3 のつらみ
- ECCUBE3 のカスタマイズ
- ECCUBE3を教材にして、Synfony2を学ぶ
- デバッグ
- 参考記事
- 参考文献
Requirements
- [EC-CUBE] EC-CUBE3.0.16
- [レンタルサーバ] さくらインターネット
- [OS] FreeBSD 9.1-RELEASE-p24
- [PHP] 5.6.38
- [データベース] MySQL 5.7.22-log
- [WEBサーバ] Apache
- [ブラウザ] Chrome
ここは、初心者に優しいECCUBE3のページ。
ECCUBE3 のカスタマイズ、機能追加をする開発者向けのガイド。というか私が苦労したので「今ならこうする」という認識や苦労話を書いていきたい。
間違っても私は達人ではないので、もがき苦しんだ話がメインだと思って頂きたい。
環境
- ECCUBE3.0.16
- Symfony2.7.28
- PHP5.6.38
対象読者
過去の私、即ち。
- PHPに関する基本的な理解がある
- WordPress程度のCMSの知識はあり、あのくらいならわけなくカスタマイズできる、と軽く考えている。
- MVCフレームワークの経験があるか、基本的な理解がある
- ECCUBEを触ったことはない(が、これから触らないといけない、 )
ECCUBE3 のつらみ
ECCUBE3を学ぶ上でつらいのは、なんといってもドキュメントが少ないことではないかと思う。
ECCUBE2 は独自のフレームワークを採用していたらしく、あまりECCUBE3にとって参考にならない。
当然、まず頼るべきはECCUBE3の公式になるはずだが、これが少々心もとない。ちょくちょく誤字か仕様変更らしきものがあり、ここから仕様を読み解こうとする試みはだいたい失敗する。
情報の絶対量もWordPressに比べればだいぶ少ない。
しかもECCUB4が発表されて、そっちの方が仕様整理されてて良さそう…。というわけでこれから学ぶ人(がどれだけいるかわからないが)がめげないようにドキュメントを作成してみた。
ECCUBE3 のカスタマイズ
ECCUBE3 のカスタマイズには、およそ5つの段階がある。あなたがどの程度変更したいのか、どの程度スキルがあるか、によって選択すべきカスタマイズが異なる。(しかし実は、上記の対象読者にとってはもうどの段階を選ぶかはおよそ決まっている)
- 管理画面の設定項目でなんとかなる
- CSSやtwig テンプレートをいじってなんとかなる
- 管理画面からデータベースの値をいじってなんとかなる
- MySQL を直接いじってなんとかなる
- 上記4つでうまく行かなさそう → プラグイン開発
というわけで、ほら、あなたが選ぶのは最後の項目になるはずだ。素敵な棘の道である。
幸いプラグインはかなりのことができる(はず)。
本体をいじりたくない
プラグインを開発する理由は、本体(srcディレクトリ以下)をいじりたくないからだ。
本体(srcディレクトリ以下)をいじりたくない理由は、もちろん、本体のバージョンアップでカスタマイズが消え去る可能性があるからだ。他のプラグインとの競合も怖い。本体のバージョンを固定すると、セキュリティなどで問題が出てしまう可能性はあり、痛し痒し。
ただそれでも本体側をいじらなければならない場合はあるかもしれない。なにせ本体で実装されてしまっている項目や機能をプラグインの方で削除したり無効化したりするのは結構な手間なのだ。
ECCUBE3を教材にして、Synfony2を学ぶ
結局のところ、ECCUBE3はSynfony2(Silex)である。クラスファイルやテンプレートを加えてECサイトの体裁を整えてはあるが、駆動部分はSynfony2だと思ってだいたい合っている。
正確にはSilexらしいのだが、SilexはSynfony2をベースに軽量化したマイクロフレームワークなので、ほぼSynfony2でいいようだ。(ちなみにSilexは今ではSynfony4に統合されている)
だから、Synfony2のシステムを理解することがECCUBE3を理解することだ。
個人的には、ECCUBE3の公式ドキュメントがどこか煮え切らない印象なのも、この構造のせいだと思っている。ECCUBE3のサイトがSynfony2について全訳してイチから全部解説するのも変だ。かといってSynfony2の話を全部英語の公式に丸投げして、ECCUBE3の独自部分だけ説明したのでは不親切にすぎる。国産をウリにしているECCUBE3を求めてきた人に英語ドキュメントを強いるのも酷だ。そこで、ECCUBE3の公式ドキュメントはSynfony2の概略をつまみ食いするような感じになっている。そのため、全体像がよくわからない。
もしあなたが私と同程度の初心者なら、すべきことはこうだ。
- Synfony2の全体像、クラスファイルの役割分担を理解する
- ECCUBE3のソースコードを読み、ECの機能がどのように配備されているか知る
- Synfony2 とECCUBE3を理解できたら、自分に必要な機能を考え、プラグインとして設計する。
ECCUBE3を一つの教材にして、Synfony2を学ぶのだと考えた方が、ECCUBE3の理解の近道になる。
ECCUBE4も引き続きSynfonyをベースとしているので、Synfony2を学ぶことも無駄にはならないはずだ。
デバッグ
デバッグモードとdumpについては必ず知っておくべきだ。これを知らないといろいろ遠回りをすることになる。
開発の補助:デバッグ・Tips | EC-CUBE 開発ドキュメント(https://doc.ec-cube.net/guideline_tips#%E3%83%87%E3%83%90%E3%83%83%E3%82%B0%E3%83%A2%E3%83%BC%E3%83%89%E3%81%AE%E6%9C%89%E5%8A%B9%E5%8C%96)\\_
デバッグモードとdump()が使えるようになると、こんな便利がある。
- 自分が開いているページが、どのControllerのどのメソッドで表示されているかわかる
- エラーが起きた時にスタックトレースを見ることができる。
- dump()によって変数の中身を見ることができる
デバッグモードを使えるようにする
html/index_dev.phpを経由したリクエストはデバッグモードとして扱われる。たとえば
your.domain.com/html/
がトップだとすれば、デバッグモードのトップは
your.domain.com/html/index_dev.php
になるし、your.domain.com/html/product/list
のデバッグモードはyour.domain.com/html/index_dev.php/product/list
になる。
ただし、アクセス元のIPアドレスをindex_dev.php
に追記しないといけない。つまりアクセス元のIPが固定になっている必要がある。
Appに渡す配列に値を指定して、デバッグモードにするというやり方もある模様。
EC-CUBE3のデバッグモードへの変更の仕方 - Qiita
デバッグモードでの注意事項
- Twigテンプレートに
{{ dump() }}
を書いた状態だと、デバッグモードでは正常に見ることができるが、通常モードだと「システムエラー:管理者に連絡してください」が表示される。 - うっかり
{% block stylesheet %}の外に書いた
`要素が、デバッグモードでは表示されてしまうが、通常モードでは表示されないため、齟齬が生じる。
ファイルに書き出す
それから、PHPでエラーや変数の中身をローカルのテキストファイルに書き出す方法も、ブラウザに表示されないAPIのデバッグなどで役に立ったので、一応紹介しておく。
file_put_contents ( string $filename , mixed $data [, int $flags = 0 [, resource $context ]] )
$filename
の指定には_DIR_
をつけて明示的にファイルのディレクトリを存在しないと、余所からincludeされた場所にファイルが生成されてしまうので注意。
file_put_contents(__DIR__ ."/debug.log", time().':data1:'.print_r($some_var,true)."\n", FILE_APPEND); //テスト用出力
ファイルに書き出す際の注意
当たり前だが、変数(上記の例では$some_var
)がオブジェクト形式だったりするとエラーメッセージなしでシステムエラーになるため、原因を特定しづらい。
デバッグのために書いたコードが原因でエラーが出て堂々巡りになるので気をつける。
キャッシュを無効にする
ECCUBE3は(というかSymfony2が)サーバー側にキャッシュがあり、FTPなどでアップロードしたファイルがすぐには反映されないという事情がある。これが確認作業、テストなどではいろいろトラブルの元になることが多い。
異論はあるかもしれないが、キャッシュを削除しておいた方がトラブルがないと思う。手順は別の記事にまとめておいた。
参考記事
ECCube3入門者への優しい世界を創るためのTips集 ~ ルーティングとフックポイント編 ~
いきなりですが、彼らの名前を覚えると、とりあえずはどこのソースが動いているかはわかります。
1.FrontControllerProvider 2.AdminControllerProvider
彼らの名前を見れば一目瞭然です、URLのルーティングを定義してくれているProvider様ですね。 名前からわかるように管理画面とフロント画面でさっくりわかっています。 とりあえずここを見れば今皆さんが見ている画面の裏で走っているロジックを 特定することができます。
3.EccubeServiceProvider
参考文献
基本からしっかり学ぶ Symfony2入門