2.11.4でレスポンシブデザインをやるときの注意点。
前置きというか。
ECCube2.11系はPC/SP/mobileでテンプレートをそれぞれ作れる。
mobileはもはや切っていいレベルで、PC/SPはレスポンシブ・リキッドレイアウトでやれば親和性がある≒使い回しができる。
でもECCube側のシステムがアレなので注意しなきゃいけない点がいくつかある。
SPのデザイン前提がヤバい
PCとほぼほぼ一緒なんだけどヤバい。
jQueryライブラリについて
jQueryライブラリを使う場合、slim版(スリムビルド)は使っちゃいけない。
SPのログイン動作はformとjsをアレしてシステムに投げて動作させてるんだけど、jsがjQueryありきの書式になっている。で、それはライブラリによって影響を受ける(≒動作不良を起こす)。
ECCubeのSP版ログインはajaxを使ってる。
slim版はajaxが使えない。
よっぽどの理由がなければslim版の使用は却下すること、使わざるを得ないなら回避方法を探さないといけないので超めんどい。
ログイン処理は最低でも直接アカウントページに行った場合と購入手続き中とで複数あるので包括的な処理にしないと対応しきれないからクソめんどい。
そもそものログイン処理について
PC版はjsを使わずにログイン処理ができてるのに、それをSPで使うと
{“success”,”【ログイン元url】”}
みたいなのだけが表示されるlogin_check.phpに遷移する。
ログイン処理はできてるんだけど、状況に応じたページが表示されない。
ブラウザだかデバイスが原因で起きてる症状らしいけど、システムエラーというよりはこれが正常の処理なんだと、 ajaxで投げるのが正攻法なんだってのが当時の見解なんだと思う。2.11系なんてもう過去の遺物だしね。
万が一SP版を上書きしてしまって元データが確認できなくなっちゃった場合、これがちょっと面倒。
公式サイトで旧版のデータもDLできるんだけどバージョンが限られてるので、自分のがそれと違った場合、近いからってそれを流用できるとも限らない。
やっぱり同じバージョンのデータを確認したい。
http://downloads.ec-cube.net/src/eccube-3.0.11.zip
http://downloads.ec-cube.net/src/eccube-3.0.11.tar.gz
ECCubeのコミュニティフォーラムですごく助かる投稿があった。
このURLのバージョン部分を変えたら2系でもDLできる(2019.12現在)。
拡張子変えてもいけるって便利すぎる。
管理画面で現環境のバージョンを確認して、同じバージョンのをDLしてローカルに残しておくのが安心。
で、PCとSPの違いは、SPにはscriptでjsが書き込まれてるのと加えてformも内容が微妙に違う。js、form、念の為にinputも確認しとくと安心。
つまり
レスポンシブで作ったとしてもテンプレートはPCとSPで分けて、ログインとかの別個で調整が必要な部分を変更する。見た目一緒でも使ってるテンプレートが違うんで面倒ではあるけど、システムに関わるところがあるから分けちゃったほうが無難かなと思う。同一のテンプレートを指定して、useragentとかで要所要所を切り替えてもいいんだろうけどね。
まとめというか
ECCubeの2.11系は自サイトでのEC運営ができるってんでめちゃくちゃ流行った。WEB会社がこれ幸いと、大して独自デザインもしないで色とかバナーとか変えるくらいで殆どデフォルトのまま使って、要するにいい加減な改変しかしないで何も考えずに売りまくった。導入したところも無知が悪いといえばそれまでだけど災難だと思う。バージョンアップのことなんかそもそも考えられてない作りだし、多分WEB会社はそれを伏せて売ったよな?旧版ほど新版へのアップデートがキツい。3系からだったか、システムを新築しないでもアップデート可能になったんでそれは良かったけど。
2系、しかも古いやつはシステムが違いすぎてド素人には触りようがない。
新サイトを作ることはできてもデータの載せ替えで詰む。
商品情報と顧客情報が何においても一番厄介で、システムのフォーマットに沿った内容で組み込んでればまだ対応のしようもあるんだろうけど。
システム側が用意してる枠以上にオプションを組み込んだり、システム側で用意してないオプションを組み込んだりした場合、会員情報に残される購入履歴との紐付けはできるのか?っていう。
お前らそこまで先のこと考えて自社ECサイトのパッケージを売ったのか?
商社が自分で作ったんなら自己責任だけどWEB制作会社が売り込んだらお前らがフォローしなきゃダメだろみたいな、今は良くても後で不幸になるものをつくるんじゃねえよと。
脆弱性との戦いについて
まとめてるはずが速が上がってしまったのでこれも書く。
脆弱性の対策は大雑把に言って2つ。
- 個別に脆弱性を潰す
- システムのバージョンを上げる
古いから無理、みたいな絶望感を味わうことはなくて、SSL入れたりadmin変えたりなんやかんやで対処できたりする。やり方が分かってれば面倒くさくてもそんなに大掛かりなことは必要ない。
個別に脆弱性を潰す
都度潰せば終わりなんだけど、古いバージョンはそれだけ研究期間が設けられてるって話で、ワンチャン大どんでん返しを食らう可能性も無きにしもあらずで、公式が脆弱性を発表してるからそれさえやれば安心かといえばそうともいい切れず、今発表されてる内容が全てかといえばまた追って何かしら出てくることもあるだろうし、そもそものところサポートが終了したらどうすんだよって話で。
別の会社がサポートをなんちゃらみたいなサービスを始めてるけど、それに頼るのもどうなのっていう、情報弱者救済というよりはいい食物にされてんじゃんみたいな気持ちがある。
多少体力のある会社が危機感にいい加減煽られたのか、今後の対応についての連絡を寄越したりしてる。でもバージョンアップはクソ手間がかかるんで、やってくれることって言ったらこっちの方なんだろうね。
システムのバージョンを上げる
個人的な意見としては絶対にこっちのほうがいい。
脆弱性の原因に包括的なのじゃなくてSP部分に限った内容があるんで正直なところ前者の対策でカバーしきれる気がしないというか、穴がデカすぎるんじゃないのかという。
js前提の制御は今にしてjs当たり前で通ってるけど、いつまた使わないブームが来るかもわかんないし。
ECCubeもシステムアップデート機能がついたお陰で都度人力のアップデートをする必要がなくなった。つっても3→4でまたビッグアップデートかましてるから何やってんのって気持ちだけど。
2系から上げる場合は親和性が皆無なので新バージョンで新たにサイトを作成する必要がある。で、新しいサイトに顧客情報とかを流し込む。
そもそもデータベースの仕組みが違うのですんなりいかない、移行用プラグインは出てるけど対象バージョンに含まれてるかどうかも怪しい、商品のオプションで独自設定をしてたらどうなるのという疑問点、不安感もある。
なので、自分でやれたら御の字なんだけど、載せ替えのサービスをやってる業者がいるので冒険する余裕のないところはそこを活用してさっさと乗り換えちゃうのがいいと思う。
番外:他のCMSを使う
いっそのことメイクショップとかそういう、サービス元が脆弱性対策のすべてを担保してくれるところに金で解決していくスタイルでやってくのはどうか。
高く付くけど安心感が買える、たまにやらかすこともあるけどそれはどこだって同じリスクを背負ってるわけで。
まああくまでも、納得できる落とし所を探そうねっていう話。
コメント