前回カートセッションの作りが酷いという話をしましたが、口だけとか言われるとアレなんで試しにやってみました。
http://blog.cnobi.jp/v1/blog/user/8f14c19eb01af9c2e80c7f2ad07dc8ca/1271426019
EC-CUBE2.4.3用です。
基本的にはSC_CartSession.phpを差し替えるのですが、一部問題点があるので修正策も提示しておきます。
主な変更点
・$_SESSION['cart'][0]、$_SESSION['cart'][1]…となっていた商品リストを$_SESSION['cart']['products']配下に入れた
・商品の配列キーを連番ではなく商品IDにした
・cart_noも面倒なのでIDにした
・SC_CartSession::getNextCartID()、SC_CartSession::getMax()は不要なので削除
・ereg()を排除
注意事項
・あんまりデバッグしてない
・売り切れとかポイント関連は何やってるのかよくわからなかったので概ね適当
・$_SESSION['cart']を直接どうこうしていた場合動かなくなるかもしれない
・MySQLで作ったのでPostgreSQLだと動かなくなるかもしれない
・マジックメソッドとかrunkitとかの強力な機能でカートを上書きしていた場合動かなくなるかもしれない
・SC_CartSession::getNextCartID()、SC_CartSession::getMax()を使用していた場合動かなくなるかもしれない
・商品配列のキーが数値連番である前提の実装だった場合動かなくなるかもしれない
・よくわからないけどどこかで動かなくなるかもしれない
さて、差し替えただけでは一部動かない場所があります。
まあ注意事項の下から2番目と3番目に引っかかってるんですが。
まずSC_Helper_DB::sfTotalCart()、LC_Page_Cart::process()、LC_Page_Shopping_Complete::lfRegistOrderDetail()。
何れも商品リストに対し、
for ($i = 0; $i < $max; $i++) {
とか書いてあります。
それぞれ順番に、
foreach( $arrCart as $i => $val){
foreach( $arrRet as $i => $val){
foreach( $arrCart as $i => $val){
に書き換えるとそのまま動きます。
なんでそんなにforが好きなの？
次にLC_Page_Shopping_Payment::lfGetDelivDate()
max = $objCartSess->getMax();
for($i = 1; $i <= $max; $i++) {
とか書いてあります。
ていうか、$_SESSION[$objCartSess->key]とか書いてあります。
これはひどい。
勝手拡張でこんなのを追加した、とかなら仕方ないかもしれないが正式版でやることではなかろう。
何故SC_CartSession::getAllProductID()を使わないのかと。
以下の部分を書き換えます。
この$arrID、別に他に使われているわけでもないし二次元配列にする意味が全く無いんだが何故こんなことに。
以上でSC_CartSessionが見た目すっきりになりました。
実はなにか重大な理由があってあのような作りになっていたとかいう可能性もないでもないですが気付かなかったことにします。
まあ、修正したはいいけどパフォーマンスチェックとかやってないから早くなったという保証はないんですがね。
というか、毎回尋常じゃない結合をやっているSQLのほうが明らかにボトルネックなので正直自己満足レベル。
あと、カートなんてどう考えても投入より参照回数の方が多いんだから、税金の計算とかも投入時にやるべきなんですが、そこらへんもやってません。
めんどうだったので。
EC-CUBEの記事
http://blog.cnobi.jp/v1/blog/user/8f14c19eb01af9c2e80c7f2ad07dc8ca/1271426019
EC-CUBE2.4.3用です。
基本的にはSC_CartSession.phpを差し替えるのですが、一部問題点があるので修正策も提示しておきます。
主な変更点
・$_SESSION['cart'][0]、$_SESSION['cart'][1]…となっていた商品リストを$_SESSION['cart']['products']配下に入れた
・商品の配列キーを連番ではなく商品IDにした
・cart_noも面倒なのでIDにした
・SC_CartSession::getNextCartID()、SC_CartSession::getMax()は不要なので削除
・ereg()を排除
注意事項
・あんまりデバッグしてない
・売り切れとかポイント関連は何やってるのかよくわからなかったので概ね適当
・$_SESSION['cart']を直接どうこうしていた場合動かなくなるかもしれない
・MySQLで作ったのでPostgreSQLだと動かなくなるかもしれない
・マジックメソッドとかrunkitとかの強力な機能でカートを上書きしていた場合動かなくなるかもしれない
・SC_CartSession::getNextCartID()、SC_CartSession::getMax()を使用していた場合動かなくなるかもしれない
・商品配列のキーが数値連番である前提の実装だった場合動かなくなるかもしれない
・よくわからないけどどこかで動かなくなるかもしれない
さて、差し替えただけでは一部動かない場所があります。
まあ注意事項の下から2番目と3番目に引っかかってるんですが。
まずSC_Helper_DB::sfTotalCart()、LC_Page_Cart::process()、LC_Page_Shopping_Complete::lfRegistOrderDetail()。
何れも商品リストに対し、
for ($i = 0; $i < $max; $i++) {
とか書いてあります。
それぞれ順番に、
foreach( $arrCart as $i => $val){
foreach( $arrRet as $i => $val){
foreach( $arrCart as $i => $val){
に書き換えるとそのまま動きます。
なんでそんなにforが好きなの？
次にLC_Page_Shopping_Payment::lfGetDelivDate()
max = $objCartSess->getMax();
for($i = 1; $i <= $max; $i++) {
とか書いてあります。
ていうか、$_SESSION[$objCartSess->key]とか書いてあります。
これはひどい。
勝手拡張でこんなのを追加した、とかなら仕方ないかもしれないが正式版でやることではなかろう。
何故SC_CartSession::getAllProductID()を使わないのかと。
以下の部分を書き換えます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
// 商品IDの取得
$max = $objCartSess->getMax();
for($i = 1; $i <= $max; $i++) {
if($_SESSION[$objCartSess->key][$i]['id'][0] != "") {
$arrID['product_id'][$i]
= $_SESSION[$objCartSess->key][$i]['id'][0];
}
}
↓
// 商品IDの取得
$arrID['product_id']=array();
$tmp=$objCartSess->getAllProductID();
foreach($tmp as $key=>$val){
$arrID['product_id'][]=$val[0];
}
|
この$arrID、別に他に使われているわけでもないし二次元配列にする意味が全く無いんだが何故こんなことに。
以上でSC_CartSessionが見た目すっきりになりました。
実はなにか重大な理由があってあのような作りになっていたとかいう可能性もないでもないですが気付かなかったことにします。
まあ、修正したはいいけどパフォーマンスチェックとかやってないから早くなったという保証はないんですがね。
というか、毎回尋常じゃない結合をやっているSQLのほうが明らかにボトルネックなので正直自己満足レベル。
あと、カートなんてどう考えても投入より参照回数の方が多いんだから、税金の計算とかも投入時にやるべきなんですが、そこらへんもやってません。
めんどうだったので。
EC-CUBEの記事
PR
トラックバック
トラックバックURL:
コメント
無題
ereg()残ってた…orz
posted by NurseAngel at
2010/04/17
00:54
[ コメントを修正する ]
