贰颁-颁鲍叠贰関西鲍骋勉强会（贰颁-颁鲍叠贰2系から3系へ移行にまつわるエトセトラ）
- 1. 株式会社ロックオン 永橋剛 EC-CUBE 関西UG 勉強会 ～EC-CUBE2系から3系へ移行にまつわるエトセトラ ～
- 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. 機能がそれぞれ絡み合ってて、プラグイン毎に依存しないようにできな い。。 本体へ反映済、反映予定の機能もあり
- 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トランザクションで実施したい場合） ? そもそも現行システムが複雑になっており、整理するのに時間がかかる
- 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以下になった場合も）