Because We Love Happy Coding

フリーライターからエンジニアへ。発信力だけあり余ってる感じ

ECCUBE3でハマった仕様

私がECCUBE3の開発をしていて「ええっ」と思った仕様を挙げておく。

目次

環境

「数量変更」ボタンの機能はカートに戻されるだけ

カートから購入に進むと、確認画面shoppingが表示される。ここには「数量変更」ボタンがある。

これは、ただのa要素で、カート画面cartにリンクされているだけだ。

しかも、カート画面ではOrderは破棄され、確認画面に進む時に内部的には新規のOrderを生成し、注文番号も取り直しになる。

つまり、確認画面で入力したすべての内容は、「数量変更」ボタンを押した瞬間に破棄されるということだ。うっかり確認画面に入力内容を増やしたばかりに大変だった。

FaxTypeというFormTypeは存在しない

厳密には、存在するが使われていない。コメントには削除予定とある。

現状では、TelTypeの別名が使われている。FormBuilderadd()する際の第一引数がfaxであれば、faxという名前のTelTypeが生成される。

このTelTypeが、3つのtextタイプで構成され、3つすべてが入力されないとエラーになるという仕様。Pluginから弄ろうとするとだいぶ悩まされる。

メールのSubjectはMailService.phpで変更する

各種メールのSubjectはMailService.phpでセットされている。

変更したい場合はコアコードに手を入れざるを得ないのか…と思っていたけれど、メールにもイベントがあることを発見。

例えばmail.orderでフックすると、受注確認メールの内容に干渉できる。ここでうまくすればなんとか?

CustomerAddressは顧客住所ではなく配送先住所

Customerは顧客の情報。住所もこれに含まれる。常に一つしかない。

CustomerAddressは配送先。複数ならCustomerAddressesとなる。テンプレートではCustomer.CustomerAddressesの形で登場することも。

英語的にはShippingAddressの方が良かったのではないかと。顧客住所がCustomerAddressではなくCustomerの中にある、と分かるまでにけっこう探したよ。

配送先住所をShippingにセットする処理はこう。どうしても「顧客情報」から住所を設定しているように見えてビクッとする……。

// お届け先情報を更新
$Shipping->setFromCustomerAddress($CustomerAddress);
$app['orm.em']->flush();

shipping_delivery_name

オブジェクトDeliveryにNameあるんだからそっちを見てくれよ……と思うけれどなぜかshippingにはshipping_delivery_nameという項目があって。setDelivery($Delivery)した時には原則setShippingDeliveryName($Delivery->getName())するということになる模様。

$Delivery = $this->app['eccube.repository.delivery']->findOneBy(array('id' => $delivery_id));
$shipping->setDelivery($Delivery);
$Shipping->setShippingDeliveryName($Delivery->getName());

setDelivery()の中で$this->setShippingDeliveryName()してくれた方がスムーズな気がするんだけど、そうもいかないんだろうか。

関連して、注意しないと行けないのは、shopping.twigテンプレートから呼び出されるのはform.shippings[idx].deliveryつまり$Delivery->getName()だが、メールテンプレートMail/order.twigから呼び出されるのは{{ Shipping.shipping_delivery_name }}なので、食い違っていると、「画面上は正しいものが表示されるのに、メールでは別のDeliveryNameが届く」というバグになる。