仕事で、EC-CUBEを使うことになってしまった。
「なってしまった」というのは、事前調査時の悪評があまりに多かったから。
しかしながら、日本国内でインスタントに自前のECサイトを立ち上げるなら
まあEC-CUBEが妥当なんじゃね？ という検討結果となり
実際に使ってみたんだけど、
ぜんぜんコアにいじってないレベルで見ても、これ、ほんとにひどい。腹立つ。
- サーバー上で、テンプレートファイルが一元管理されていない。のであっちをいじってこっちをいじって。
- もう版数もかなり上がっているのに、変数名のtypo多すぎ。使えねえ英語なら使うな。
- ていうか、デフォルトのテンプレートの日本語がまるでなってねえ。使えねえ自国語なら使うな。（努力はしたけど、全部校正するのはあきらめた）
- デフォルトの管理画面テンプレートだと、httpsなアクセスで使えない機能が何点かある。あれですか、個人情報を扱う管理画面で非暗号化通信が前提ですかそうですか。（これは直した）
- 画面遷移の要所要所でURLが変わらない。おいおいGoogle Analytics使えねえぞ。（これはシステムに影響の無いPATH_INFO突っ込んで、画面遷移を確実に追えるようにした）
- などなど。
まあ、ここ10年くらいの日本のインターネット業界の悪いところを
凝縮したようなシステムだったなあ。
====================
ここまでが長い前置き。
さて、最近、なるべく避けて通りたかった処理なんだけど、
ログイン状態を取得して、それにより共通ヘッダーの表示を変える、という必要が出てきた。
まあ、普通なら、そういうAPIが用意されてるんだろうなあ、と思って
あまり期待はしてなかったけどそんな感じで検索してみたら
えーそれマジかよー って方法が広まってて
ちょっとカルチャーショックだった、という話。
たとえば、次のブログ。
EC-CUBEでログインしているかログインしていないかを判断する方法 from ajiblo
- isLoginSuccess っていう関数があるからこれで真偽値取れるよ！
- それか、セッション変数「customer」の有無で判別できるよ！
ということなんだけど、
どちらも共通ヘッダー向けの処理としては良くないように思う。
まず、isLoginSuccess関数を共通ヘッダーで利用すると、
全ページへのアクセスについて、毎度毎度DBとの通信が追加で発生してしまう。
いくらただの小規模な参照クエリーにすぎない（たぶん）とはいえ、
とかくWebアプリケーションにおいてボトルネックになりやすい
DBとの通信を、ちょっとした表示制御のためなんかにわざわざ増やしたくない。
このくらいの話なら、セッションオブジェクトの範囲でなんとかしたい。
だけど、本質的な話としては、
セッション変数「customer」の有無は、ログインの有無を表さない。
なぜならば、セッション変数「customer」は、
ログインしないで購入手続きを済ませた場合にも生成されるからだ。（確認した限りでは）
だから、
{if $smarty.session.customer|@count > 0}
っていう判定コードは間違い。
これは、EC-CUBEの実装のまずさに起因する間違いと言えるだろう。
だって、なんでログインユーザーの情報とログインしてないユーザーの情報を
同じオブジェクト名で扱うのさ？
で、じゃあ結局どうすればいいのかな、あんまり手をかけない範囲で、と考えた結果、
EC-CUBE 2.4.4の実装依存で悪手ではあるけど、
セッション変数「customer」が持つ連想配列のうち、
ログインユーザーには値があって、非ログインユーザーには値がないであろう項目の
文字列長を判定基準とすることを試みた。
たとえば、「password」とかは、非ログインユーザーは入力する機会がないから
ダミー値が入ってるか、空かのどっちかのはず。
具体的には、
{if $smarty.session.customer.password|count_characters > 0}
と書いてみた。
いろんなパターンでテストしたけど、
いまのところ、一応これで要件は満たせてるみたいだし、
コアモジュールにも手を出さず、テンプレートの範囲で済む修正だったので
もうこれでしばらくはいいや、という感じ。
でも実際、どうすべき話なんでしょうね？
EC-CUBEのドキュメントも何もちゃんと調べてないんだけど、
もっとマシな、筋の通った方法がちゃんと用意されてるのかな？
コメント