Moxamint

The new code works as expected. Thank you very much! Since get_first() will replace cheapest() in the core checout_shipping.php, does it means you do not consider cheapest() being a reasonable default? Cheers, Eddy

Hi All, If shipping method has not yet been selected, how do I make the method with least sort order of display (the first shipping method) automatically selected? Currently the system would use the cheapest method. Thank you in advance if you can give me a hint. Cheers, Eddy

Yes it's now working without a hiccup! Cheers, Eddy

@Gergely@clustersolution@douglaswalker I confirm that my issue was introduced by the code change I made in checkout_process.php. I did not know PayPal does use checkout_process.php, and the code change in it works for my bank payment option, so I never looked into it... Thanks very much again for your help! Best wishes, Eddy

@clustersolution Update: All info provided above was from my development site. I just made a real purchase at my productive site (running on non-responsive osC 2.3.3.4) and everything including e-mail went through and logged correctly with IPN turned off and PDT turned on in my PayPal account. If I remember correctly, the old osC only uses IPN. So does PayPal code in osC simply ignore the setting in PayPal account??? Thanks, Eddy

@clustersolution I turned off IPN and left PDT on. Now I received only one e-mail from paypal_standard.php and the customer was redirected to checkout_success.php successfully. However, while the order ID logged in the e-mail is 1060717418, the order ID logged in admin/orders is 1060717417. I went to check my database, the order ID to be used for next order is 1060717418. Also the order status stayed at Preparing [PayPal]. It never changed to Verify [PayPal]. I have no idea what's happening. I guess my issues with PayPal APP is unique? Thanks, Eddy

Thanks. I'll try using PDT only and see what happens. Is <<checkout_process.php>> being called at all when using PayPal Standard? <<standard_ipn.php>> redirect buyers to <<checkout_success.php>>, but in osC admin the PayPal Standard suggest that <<checkout_process.php>> must be used as the return URL. Thanks, Eddy

I have IPN on only. PDT is off. I am receiving 2 e-mails all the time - one from <<ext\modules\payment\paypal\standard_ipn.php>> and the other one from <<includes\modules\payment\paypal_standard.php>>. Thanks, Eddy

@Gergely I did not see any order_status value being zero. The two-email issue remains. Also my product stock was deducted twice. My currently setup in my PayPal account has only IPN turned on. I am going to roll back my PayPal APP to version v4.039 and start over. Thanks, Eddy

@Gergely I placed an order after added the above code, and the order_status in orders table was 5, of which number is assigned to "Verified [PayPal]" Thanks, Eddy

@Gergely Thanks I'll give it a try and report back. I have a new finding, though, that anything I changed in PayPal website would take a while to kick in. I'll try turn off PDT again and see what's gonna happen. Also @clustersolutions by looking at the code in <<paypal_standard.php>> IPN seems to be loaded anyway regardless the setting in your PayPal account - can anyone advise on this? Cheers, Eddy

@Harald Ponce de Leon Hi, I am having some issues when using PayPal Standard with the latest PayPal APP. I am running osC BS Edge and have recently upgraded PayPal APP from v4.039 to v5.018. Because my server is on PHP v7.0.14 so I had to modify the following 19 files to make the "deprecated constructor" warning message go away in PayPal APP: includes\apps\paypal\cfg_params\ssl_version.php includes\apps\paypal\cfg_params\transactions_order_status_id.php includes\apps\paypal\hooks\admin\orders\tab.php includes\apps\paypal\modules\DP\DP.php includes\apps\paypal\modules\EC\cfg_params\checkout_flow.php includes\apps\paypal\modules\EC\cfg_params\incontext_button_color.php includes\apps\paypal\modules\EC\cfg_params\incontext_button_shape.php includes\apps\paypal\modules\EC\cfg_params\incontext_button_size.php includes\apps\paypal\modules\EC\cfg_params\transaction_method.php includes\apps\paypal\modules\EC\EC.php includes\apps\paypal\modules\HS\HS.php includes\apps\paypal\modules\LOGIN\LOGIN.php includes\apps\paypal\modules\PS\cfg_params\prepare_order_status_id.php includes\apps\paypal\modules\PS\PS.php includes\modules\content\login\cm_paypal_login.php includes\modules\payment\paypal_express.php includes\modules\payment\paypal_pro_dp.php includes\modules\payment\paypal_pro_hs.php includes\modules\payment\paypal_standard.php All test purchases went through. Payments were received OK. However, I always received TWO confirmation e-mails with two different, continuous order IDs for each order. Only the smaller order ID number would be registered in admin/order. The customer's comments would only show in the e-mail with larger order ID number, but disappeared in admin/order. This phenomenon occurred either when only IPN or PDT was enabled, or both IPN and PDT were enabled. It looks to me the following two files are both sending out order confirmation e-mails: ext\modules\payment\paypal\standard_ipn.php includes\modules\payment\paypal_standard.php It would be great if anyone can give me a direction on how to fix this issue of mine. Thanks in advance for your time and help. Cheers, Eddy

Line 3 => $tmp_weight = 2 * ceil($shipping_weight);

@@Psytanium Double the weight. Cheers, Eddy

Here is the conceptual code: $rate_table = preg_split("/[:,]/" , constant('MODULE_SHIPPING_ZONE_COST_' . $dest_zone)); $table_size = sizeof($rate_table); $tmp_weight = ceil($shipping_weight); for ($i=0; $i<$table_size-2 && $tmp_weight>0; $i+=2) { ##################################################### $shipping += min($tmp_weight, $rate_table[$i]) * $rate_table[$i+1]; # If zone shipping is 2:5.3,4:4.2,1:3.1 # $tmp_weight -= floatval($rate_table[$i]); # it means the first 2KG costs $5.3 per kilo # } # the next 4KG costs $4.2 per kilo # # the rest of weight costs $3.1 per kilo # if ($tmp_weight > 0) $shipping += $tmp_weight * $rate_table[$i+1]; ##################################################### So you simply double the total weight and the rate table would be as simple as 1:5 if you charge $5 for every 0.5 kilo.