EC-CUBE4はここが酷い。
最近、EC-CUBEでの開発保守の仕事をしていますが、EC-CUBEのソースが余りにも酷すぎると感じています。EC-CUBE4を利用する前に長いですが一読してもらい、本当にEC-CUBE4を使用するか考え直して欲しいです。
免責事項
TL;DR
- EC-CUBEのカスタマイズ性は低く、痒いところに手が届かない
- カスタマイズするには、ソースコードを読むしかない
- クソコード、クソ仕様、バグがいっぱいある
対象バージョン
- EC-CUBE 4.1.0
EC-CUBEの嫌いなことろ
クソコード
コードの品種が酷い
EC-CUBEのコードは品種が酷いです。特にCSSは特に酷く、少し漁っただけでたくさん汚いコードが出てきます。
margin: 10px 0 18px ;
.ec-grid--center {
justify-content: center
}
margin-left: percentage((4 / 12));
& &_fooとかもやめて欲しい。
追記 2022-09-19
EC-CUBE4.2より、PHPのコードに関しては、PHP-CS-Fixerが適用されるように改善されました。
ソースコードのコメントに嘘が書かれている
ソースコードのコメントに嘘が書かれれていることが多々あります。コメントを保守できないのであればコメントはない方が良いと思います。
JSでDOMではなく、HTMLの文字列を置換してHTMLを変更しているコードがある
var $img = $(proto_img.replace(/__path__/g, path));
CSSで重複して定義されている箇所がある
CSSで重複して定義されている箇所がある。酷い。
CSSのスタイルが商品ページや購入ページごとに分かれていない(依存関係がある)
CSSのスタイルが商品ページや購入ページごとに分かれておらず、色々干渉し合っているため、一部を変更すると関係ないところまで影響が出てしまいます。Fxxk。
イベントにRepositoryが登録されていないやつがある
イベントにRepositoryが登録されていないやつがあって、プラグインからカスタマイズできない機能がたくさんある。セキュリティ面からとかではなく、単純に漏れだと推測されます。
fromで定義できるのにviewで上書きされていることがある
fromビルダーで定義できるのにviewで上書きされていることがある。プラグインでカスタマイズするには、不必要にviewを変更しないと行けなくなる。
Document rootにソースコードがある
今どき、Document rootにソースコードがあるってイケてないと思います（笑）。
venderディレクトリの外にフレームワークのコアファイルがある
EC-CUBEはvenderディレクトリの外にフレームワークのコアファイルがあります。それによってよ小学者がコアファイルをいじってしまい、不具合を呼び起こしてうことが多々あります。また、不具合が発生する程ではなくても、他人が変更したコードを引き継ぐ際には、コアファイルが変更されていないか確認する必要があります。
Dockerがクソ重い
Dockerがクソ重い。原因はvenderディレクトリにあるようだけど、LaravelやWPでvenderを使用しても重くなった経験はない。Symfonyが原因？??
公式のDocker composeは、venderディレクトリを非同期にしているくせにデプロイ時のためにvenderディレクトリを同期させる方法をドキュメントなどに書いていない。Docker composeファイルなどを読めないとプロダクト環境などへのデプロイ時にEC-CUBEが動かなくて積みます。
v4.1.0よりDocker composeのファイルが分割されて分かりづらい
v4.1.0よりDocker composeのファイルが分割されて分かりづらいです。初期の状態だとファイルを同期しなかったり、.envが使用できなくなっていたりで意味不明です。開発環境で.envを使用しなかったら、いつ.envを活用すれば良いのでしょうか？
twigでjsonを作成している
本来は、PHPで配列を作成して、それをjsonへ変換するべきです。
参考:
ファットコントローラー
基本的にEC-CUBE4の決済関係以外のビジネスロジックは、コントローラーに開かれておりファットコントローラになっている。
仕様・バグ
EC-CUBEはバグ(仕様)がかなりあります。
バージョンの記法がセマンティックじゃない
EC-CUBEのバージョン記法は一見セマンティック・バージョニングのように見えますが、セマンティック・バージョニングではありません。
先日、4.1がリリースされましたが、依存フレームワークのバージョンが上がっており、セマンティックバージョニングで言うv5.0.0になっております。
EC-CUBEのバージョニングは実際には、<スーパーメジャーバージョン>.<メジャーバージョン>.<マイナーバージョン> のような形になっています。
セマンティック・バージョニングが一般的になった今、初見殺しなので速くLaravelの様に改善して欲しいです。
また、v4.0.6のときの脆弱性の時は、v4.0.6-p1としてリリースされましたが、EC-CUBEには、パッチバージョンが基本ないため、バグがあっても次のマイナーバージョンがリリースされるまで、バグが修正されないため、バグの修正スピードも遅いです。
メールアドレスの設定項目が嘘
管理で送信専用メールアドレスを設定する項目があるが、設定したメールアドレス宛にお問い合わせメールなどを送信している。
オプションのキーをemail01, email02とかにしているのが完全に悪い。DBを変更できなくてもエイリアスメゾットを使用して、セマンティクスにするべきだと思います。
2023年6月26日 追記
v4.2.2より、下記のプルリクエストによって、メールアドレス設定が修正されました。
基本設定のメール設定のラベル名が直感的でない · Issue #5937 · EC-CUBE/ec-cube · GitHub
.envが非推奨と謳っていながら、.envに依存したコードになっている
EC-CUBEは.envが非推奨と謳っていながら、.envに依存したコードになっています。例えば、GUIからテーマを変更するとPHPで.envを書き換えるコードが走ります。EC-CUBEで.envを使用しないとEC-CUBEを完全に動作させる事はできません。そもそも.envを書き換える設計がおかしいですが…
商品規格の登録ページの項目が増えて死ぬ
EC-CUBEは商品規格を設定し一括で商品を登録する画面がありますが、商品規格の項目が増えると入力項目の数が爆増して死にます。具体的には、max_input_varsの上限に達します。この問題はmax_input_varsを増やせば解決することができますが、なぜmax_input_varsが設定されているのかを考えると無闇に上限を開放しても良いとは思えません。
受注ステータスが不可逆
受注ステータスは不可逆です。出荷済みにすると入金済みに変更することができなくなります。
入金日などを変更できない
入金日など自動入力される一部のデータはGUIから変更することができません。そのためステータスを入金済みを飛ばし出荷済みしてしまうと入金日は未設定のまま変更することができなくなります。
購入ページの決済方法の選択にバグがある
購入ページで配達方法の変更時に決済方法はリセットされずに変更前の決済方法を選択したままになります。そのため、手数料は再計算されずに料金が表示されてしまいます。また、その仕様を考慮できていないプラグインはバグります。この仕様はEC-CUBE3から修正されていないようです。
痒いところに手は届かない
EC-CUBEはカスタマイズ性は低く痒いところに手が届きません。EC-CUBEにデフォルトである機能の以上のことは基本できないと考えたほうがいいです。普通のEC以外を求める場合はLaravelなどで自炊した方が圧倒的にラクだと思います。
ProductClassの意味が無くなっている
EC-CUBE4では、在庫数をdtb_product_stockテーブルとdtb_product_classテーブルの2テーブルで管理されています。DBの設計上は、dtb_product_stockテーブルに悲観ロックした際に、他のユーザーの表示速度を落とさないために、表示用のテーブルとしてdtb_product_classが用意されているが、実装はそうなっていない。
参考:
- dtb_product_stockとdtb_product_classのリレーションがEntityの定義通り作られていない · Issue #4476 · EC-CUBE/ec-cube
- ProductClass.stockの意味が無くなっている · Issue #5089 · EC-CUBE/ec-cube
- 商品の在庫数を管理しているカラムについての質問 · Issue #1622 · EC-CUBE/ec-cube
スケーリングできない
EC-CUBE4は、複数インスタンスでの運用に対応しておらず、AWSなどのクラウドサーバーでのオートスケーリングは困難になっています。アクセスが大量にあるサイトでは、EC-CUBE4の採用は避けた方が良いでしょう。
開発
ドキュメントが完備されていない
EC-CUBEはドキュメントが完備されておらず、ソースコードを読むしかない時が多々有ります。また、GUIの公式ドキュメントもないため、非公式のドキュメントを見るしかありません。
プラグインが有料。しかもクソ高い
EC-CUBEのプラグインは基本的に有料です。しかもクソ高い。
日本語でかかれた情報しかない
日本向けのCMSのため、英語のドキュメントはありませんし、英語で書かれたブログなどもありません。(日本語のブログも殆どない)
日本語だけだと情報が少な過ぎるし、日本語があまり得意ではないエンジニアはEC-CUBEを開発することは困難です。
情報が超少ない。寧ろ出さないほうがいい。
EC-CUBEの情報は超少ないです。寧ろ有料プラグインを買ってもらうために無料で情報を公開しない方が都合がいいです（笑）。
ネットワーク効果が期待できない
EC-CUBEは、プラグインを有料で販売できるためOSSのプラグインは殆どありません。故に情報が少なくネットワーク効果は期待できません。
EC-CUBEと契約しているクレジット決済代行サービスのプラグインが配布できない
EC-CUBEと契約しているクレジット決済サービスのクレジット決済用プラグインが公式ストアでは配布できません。Stripeとか、公式ストアのプラグインではサポートされてないです。Githubには野良のプラグインがあリますが、使用するにはいくつかバグがあるので注意が必要です。
すべてのテーマのCSS/JSの依存が一箇所で管理されている
管理画面と一般ページの依存関係は、別々で管理するだと思いますが、すべてのテーマのCSS/JSの依存が一箇所で管理されています。さらにたちの悪いことにデフォルトの設定では、インストールされているすべてのテーマのCSS/JSを自動検出してビルドしようとするため、すこし厄介です。
GitHub
GitHubのissueが事実上お客様サポートになっている
GitHubのissueが事実上お客様サポートになっている。民度低い。
リァクタリングされていない
前述したとおり、明らかに品質が低いコードが多くリァクタリングは全くされていません。
コミッターが少ない
圧倒的にコミッターが少ない。株式会社EC-CUBEの社員も2,3人しかEC-CUBEを開発していないように思います。
カスタマイズ時はプラグインなどを使用せずにコアファイルを編集して、アプデート時はGitHubの差分からmergeすることを推奨している笑
カスタマイズ時はプラグインなどを使用せずにコアファイルを編集して、アプデート時はGitHubの差分からmergeすることを推奨している人が長くEC-CUBEの開発にたち触っているせいか、カスタマイズ性が低くなっている原因の一つだと思います。コアファイルを編集するぐらいなら、自炊した方がマシです。
参考:
- EC-CUBE4の最新ブランチに追従しながら開発していく手順 - GitHub/Git使い方 - - Qiita
- EC-CUBEのバージョンアップを見据えたカスタマイズ方法2020年度版 - Qiita
頑張っても株式会社EC-CUBEが儲かるだけ
OSSに貢献しても結局、公式ストアのマージンやクレジット決済代行サービスの手数料などで株式会社EC-CUBEが儲かるだけでやる気が出ない。もっと良いコードをだしていたり、WPみたいにコミュニティが大きければやる気はでますが、糞コードにやる気をそがれてOSSに貢献するモチベーションが個人的には出ないです。
良い点
EC-CUBEの駄目なところをたくさん上げましたが、EC-CUBEにも良いところもあります。
国内シェアは高い(2.3%)
2020年1月時点日本のCMSのシェアランキング
Distribution of Content Management Systems among websites that use Japaneseより引用
国内シェアは高いです。(2.3%)
プラグインの機構がある
プラグインの機構があるのは、すばらしいことだと思います。
たとえ、商品情報のオプションデータを取得ために全商品のオプションデータを取得して、foreachで取得するようなプラグインを購入して、プラグインの修正を余儀なくされたとしても、1からプラグインを作成するよりかは、遥かに楽なことはあるかと思います。
2や3に比べてSymfonyを使用しているので4はまだマシ
EC-CUBE2や3に比べてSymfonyを使用しているので、EC-CUBE4のコードはまだマシだと思います。
最後に
EC-CUBE4についての意見や感想があればコメントしていただけると幸いです。
追記
2022-09-19
-
dtb_product_stockテーブルについて追記 - PHP-CS-Fixerについて追記
- CSS/JSのビルドについて追記
- JSON-LDについて追記
- ファットコントローラーについて追記
2022-09-27
- スケーリングについて追記
2023-06-26
- メール設定について追記
Discussion
最近触り始めたのですが、この記事を見て少し不安になりました。
筆者の一番おすすめなECシステムはどちらになりますか？
私は使用した事がありませんが、ShopifyまたはWooCommerceが現状一番勢いがあるかと思います。PHPで特殊なECサイトが必要なのであれば、LaravelShoppingcartを使用してスクラッチするのが簡単かと思います。
ありがとうございます。 wordpressにもあるWooCommerceですね。
参考になりますm(_ _)m