🖕

EC-CUBE4はここが酷い。

6 min read

最近、EC-CUBEでの開発保守の仕事をしていますが、EC-CUBEのソースが余りにも酷すぎると感じています。EC-CUBE4を利用する前に長いですが一読してもらい、本当にEC-CUBE4を使用するか考え直して欲しいです。

TL;DR

  • EC-CUBEのカスタマイズ性は低く、痒いところに手が届かない
  • カスタマイズするには、ソースコードを読むしかない
  • クソコード、クソ仕様、バグがいっぱいある

EC-CUBEの嫌いなことろ

クソコード

コードの品種が酷い

EC-CUBEのコードは品種が酷いです。特にCSSは特に酷く、少し漁っただけでたくさん汚いコードが出てきます。

margin: 10px 0 18px ;

https://github.com/EC-CUBE/ec-cube/blob/b0c61a5fe5ad44589ed28a8c2eec40baa7aa1693/html/template/default/assets/scss/project/_15.2.order.scss#L144 より

.ec-grid--center {
  justify-content: center
}

https://github.com/EC-CUBE/ec-cube/blob/b0c61a5fe5ad44589ed28a8c2eec40baa7aa1693/html/template/default/assets/scss/component/_5.1.grid.scss#L304 より

margin-left: percentage((4 / 12));

https://github.com/EC-CUBE/ec-cube/blob/b0c61a5fe5ad44589ed28a8c2eec40baa7aa1693/html/template/default/assets/scss/component/_5.1.grid.scss#L242 より

& &_fooとかもやめて欲しい。

ソースコードのコメントに嘘が書かれている

ソースコードのコメントに嘘が書かれれていることが多々あります。コメントを保守できないのであればコメントはない方が良いと思います。

DOMではなく、文字列を置換しているコードがある

var $img = $(proto_img.replace(/__path__/g, path));

https://github.com/EC-CUBE/ec-cube/blob/b0c61a5fe5ad44589ed28a8c2eec40baa7aa1693/src/Eccube/Resource/template/admin/Product/product.twig#L82 より

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を活用すれば良いのでしょうか?

仕様・バグ

EC-CUBEはバグ(仕様)がかなりあります。

バージョンの記法がセマンティックじゃない

EC-CUBEのバージョン記法は一見セマンティック・バージョニングのように見えますが、セマンティック・バージョニングではありません。

先日、4.1がリリースされましたが、依存フレームワークのバージョンが上がっており、セマンティックバージョニングで言うv5.0.0になっております。

EC-CUBEのバージョニングは実際には、<スーパーメジャーバージョン>.<メジャーバージョン>.<マイナーバージョン> のような形になっています。

セマンティック・バージョニングが一般的になった今、初見殺しなので速くLaravelの様に改善して欲しいです。

また、v4.0.6のときの脆弱性の時は、v4.0.6-p1としてリリースされましたが、EC-CUBEには、パッチバージョンが基本ないため、バグがあっても次のマイナーバージョンがリリースされるまで、バグが修正されないため、バグの修正スピードも遅いです。

メールアドレスの設定項目が嘘

管理で送信専用メールアドレスを設定する項目があるが、設定したメールアドレス宛にお問い合わせメールなどを送信している。

オプションのキーをemail01, email02とかにしているのが完全に悪い。

.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などで自炊した方が圧倒的にラクだと思います。

開発

ドキュメントが完備されていない

EC-CUBEはドキュメントが完備されておらず、ソースコードを読むしかない時が多々有ります。また、GUIの公式ドキュメントもないため、非公式のドキュメントを見るしかありません。

プラグインが有料。しかもクソ高い

EC-CUBEのプラグインは基本的に有料です。しかもクソ高い。

日本語でかかれた情報しかない

日本向けのCMSのため、英語のドキュメントはありませんし、英語で書かれたブログなどもありません。(日本語のブログも殆どない)

日本語だけだと情報が少な過ぎるし、日本語があまり得意ではないエンジニアはEC-CUBEを開発することは困難です。

情報が超少ない。寧ろ出さないほうがいい。

EC-CUBEの情報は超少ないです。寧ろ有料プラグインを買ってもらうために無料で情報を公開しない方が都合がいいです(笑)。

ネットワーク効果が期待できない

EC-CUBEは、プラグインを有料で販売できるためOSSのプラグインは殆どありません。故に情報が少なくネットワーク効果は期待できません。

EC-CUBEと契約しているクレジット決済代行サービスのプラグインが配布できない

EC-CUBEと契約しているクレジット決済サービスのクレジット決済用プラグインが公式ストアでは配布できません。Stripeとか、公式ストアのプラグインではサポートされてないです。Githubには野良のプラグインがあリますが、使用するにはいくつかバグがあるので注意が必要です。

GitHub

GitHubのissueが事実上お客様サポートになっている

GitHubのissueが事実上お客様サポートになっている。民度低い。

リァクタリングされていない

前述したとおり、明らかに品質が低いコードが多くリァクタリングは全くされていません。

コミッターが少ない

圧倒的にコミッターが少ない。株式会社EC-CUBEの社員も2,3人しかEC-CUBEを開発していないように思います。

カスタマイズ時はプラグインなどを使用せずにコアファイルを編集して、アプデート時はGitHubの差分からmergeすることを推奨している笑

カスタマイズ時はプラグインなどを使用せずにコアファイルを編集して、アプデート時はGitHubの差分からmergeすることを推奨している人が長くEC-CUBEの開発にたち触っているせいか、カスタマイズ性が低くなっている原因の一つだと思います。コアファイルを編集するぐらいなら、自炊した方がマシです。

頑張っても株式会社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%)

プラグインの機構がある

プラグインの機構があるのは、すばらしいことだと思います。

2や3に比べてSymfonyを使用しているので4はまだマシ

EC-CUBE2や3に比べてSymfonyを使用しているので、EC-CUBE4のコードはまだマシだと思います。

最後に

長文で疲れたため、EC-CUBEのクソ仕様等は書ききれていませんが、EC-CUBE DAY 2021の前に公開したかったために公開します。

EC-CUBE4についての意見や感想があればコメントしていただけると幸いです。

Discussion

ログインするとコメントできます