２０１７年度のEC-CUBE関西UGで使用した資料です。 （一部公開できないものは削除済）

1. 株式会社ロックオン 永橋剛
EC-CUBE 関西UG 勉強会
～EC-CUBE2系から3系へ移行にまつわるエトセトラ ～

2. 本スライドの注意点
本スライドの内容について、
ロックオンが公式に推奨しているものではありません。
実体験に基づく経験則であるため、あくまで１意見として参考にしてくだ
さい。

3. 本日の内容
1. 案件の苦労話
2. つまずきポイント
3. プラグイン開発 VS 本体カスタマイズ
※ あくまで、個人の見解です。

4. 自己紹介
永橋 剛
株式会社ロックオン ＥＣ-ＣＵＢＥ開発部
t-nagahashi
大阪府出身
業務系アプリケーション開発（force.com）
→ EC-CUBE 受託開発
→ EC-CUBE 本体開発 （3.0.14PM）

5. 案件苦労話

6. 管理画面の項目が多すぎて、すっごい画面縦
長。。。
1. ３系は、１つ１つの画面項目が大きくなったため、
縦長になる傾向がある。
2. エラーが発生した時に、スクロールする必要がある場合、
どこがエラーかみつけづらい
3. レスポンシブ使ってるので、レイアウトを工夫しづらい。

7. 管理画面の項目が多すぎて、すっごい画面縦
長。。。
1. ３系は、１つ１つの画面項目が大きくなったため、
縦長になる傾向がある。
→ 全体のフォントを小さくして対応。
2. エラーが発生した時に、スクロールする必要がある場合、
どこがエラーかみつけづらい
→ 一番上のエラー箇所へジャンプ （本体反映済#2173
3. レスポンシブ使ってるので、レイアウトを工夫しづらい。
→ レスポンシブ辞めちゃう？
でもでも、小規模のサイトオーナーからは、
スマホ・タブレットでも見ることができ、
フォントも大きくなったので見やすいとの声も。

8. プラグイン開発をやめ、本体カスタマイズに変更した案件もあり
1. 2系にあって3系にない機能がある。機能がたりない。バグっている。。。
本体のバグを、プラグインで吸収するのは大変。。
高度なSQLないし、購入端末判別してくれないし、受注に商品追加して
も在庫減らないし。。。
2. テーブルを分割しまくることのえげつなさを実感。。。
（プラグイン毎に、テーブルを分けるとテーブルが半端ないこと
に。。。）
3. 機能がそれぞれ絡み合ってて、プラグイン毎に依存しないようにできな
い。。
本体へ反映済、反映予定の機能もあり

9. バッチのSQLが複雑すぎて、移植できない。。。
→ プラグイン開発でなくなったため、生のSQLをそのまま移植。

10. デザイン組み込み時の注意
～ 前提 ～
今回、フロントデザインをデザイン会社へ発注。
その後、システム側で、デザインの組み込みを実施。
1. Form/Typeでは実現できないデザインがある。
(Form/Typeの機能で自動的にCSSがあたるので、そのまま組み込めない。）
→ form/typeを使用しないというのも、一つの手？
→ EC-CUBEのHTMLをベースに、CSSのみでデザインしてもらう？？
2. レスポンシブになったという安心感から、明示的にスマホ画面PC画面とレイアウトを
チェックし忘れた。。。
3. グリッドシステムとするのか、2段階の切替とするのか？
2段階にしてしまったために、組み込みの段階でエンジニアが苦労することに。。。

11. ログイン周りの実装ではまる。。。
1. ログイン状態で、外部サイトから購入した場合、カート情報を残す場合、残さない場
合があるなどなど。
2. 管理画面のログインとフロント画面のログインを一つに
管理ユーザがフロント画面を表示した場合、ログインしたことにしたいとの要望が
あったが、
工数の関係で対応できず。
→ EC-CUBEはSymfonyのログイン機能を使用しているため、
そのあたりをカスタマイズするのは難易度高

12. つまずき
ポイント集

13. つまずきポイント集 フロント -1-
• 購入確認画面でのロード時間
• モバイル非対応
• ログインまわり
• デザイン（デザイン会社へ依頼するときの注意点
• 商品詳細URLの変更
• dtb_order_tempの廃止
• 受注番号が歯抜けになることがある
• 和暦表示
解決方法： https://github.com/EC-CUBE/ec-cube/issues/1938#issuecomment-286027070

14. つまずきポイント集 フロント -2-
• パスワードの最低桁数が４→８になっている
• 商品、受注、顧客の項目が減っている
• 商品画像のサイズが１種類になっている
• 選択された決済方法を、セッションで持たないので離脱した時にクリアされる

15. つまずきポイント集 管理画面
• 管理画面のデザイン（項目数が多いので、場合によっては使いづらくなってしまってい
る。。。）
• 検索機能のパフォーマンス
• 顧客数が多い場合、受注編集の顧客検索機能がフリーズする
→ ページング、検索条件の追加（本体に取り込まれる）
• 受注CSVが受注単位でなく、明細単位になっている
→ 解決策： http://xoops.ec-
cube.net/modules/newbb/viewtopic.php?topic_id=18237&forum=11
• 商品などの編集画面において、
カスタマイズ部分のみ更新した場合、dtb_productの更新時間が更新されない
• 受注データの明細を更新しても在庫数が増減しない
• CSVアップロード、ダウンロードのフォーマットが一致していない
→ 次期バージョンで解消予定

16. つまずきポイント集 共通
• お届け先のデータの持ち方
• 2系に存在している機能が3系にない。たりない。バグっている。。。
• 2系にあるプラグインが、3系にあるかどうか
• プラグイン開発では難しい。（機能ごとが絡み合っていて、難しい。）
• 複雑なバッチ。
• 管理画面のデザイン（項目数が多いので使いづらくなってしまっている。）
• データ移行について（プラグイン開発だとデータ移行が難易度高）
→ テーブル構造の違い、データ量（事前に移行しておくなどの対策）
• リダイレクトすると、Doctrineのメモリ上で保持していた情報が引き継がれない。（会員
登録、受注登録を1トランザクションで実施したい場合）
• そもそも現行システムが複雑になっており、整理するのに時間がかかる

17. プラグイン開発
VS
本体カスタマイ
ズ

18. プラグイン開発 VS 本体カスタマイズ
■ とり得る選択肢
1. ベーシックな、プラグイン開発
2. 本体カスタマイズ
3. 強引にプラグイン開発

19. プラグイン
プ
ラ
グ
イ
ン
プラグイン
ベーシックな、プラグイン開発
• 各機能の結合度が低い場合 （プラグイン同士が依存しない状
態）
• カスタマイズ領域のテーブル数が少ない場合
• 汎用的にプラグインを利用する場合
機能
B
機能
C
機能
D
機能
F
機能
E
機能
A

20. 本体カスタマイズ
• 本体自体のロジックを大幅に変更するような機能改修/追加の場
合
• EC-CUBEに強いエンジニアがいて、今後も運用保守できる場合
• 費用を安く抑えたい場合
→ EC-CUBEのmaterをフォークし、開発。
バージョンアップの際は、
Gitのバージョン管理を使い、差分を確認・修正
機能
B
機能
C
機能
D
機能
F
機能
E
機能
A

21. 強引にプラグイン開発
• 標準機能の改修は少なく、機能追加が多い場合
（独立した機能が多い場合）
• 本体バージョンアップを楽に行いたい場合
• オーナーズストアのプラグインと共存させる場合
→ 大きなプラグインを数本作成
プラグイン
プ
ラ
グ
イ
ン 機能
B
機能
C
機能
D
機能
F
機能
E
機能
A
機能
K
機能
L
機能
J
機能
G
機能
I
機能
H

22. まとめ

23. まとめ
• 現状との差分をきちんと把握してから着手する
• できるだけ初期段階で、開発方針（プラグイン開発かどうか）を決
定する
• 改善してほしい問題点は、
issue登録/PR申請を行えば取り込まれることもある
（一時的に、一部本体を修正するのもあり）
• 3.1.0で、カスタマイズ性がより強化されるので乞うご期待！！
フレームワークに慣れれば、
生産性は上がる！！
（想定の2/1以下になった場合も）

24. 株式会社ロックオン 永橋剛
ご清聴ありがとうございました。