DeBug-Log file created on every order for Malformed value for session-based shipping

Hi DrByte,

I'm seeing this problem on my store too. It seems to kick in when the delivery address is in another tax zone. In my case zero rating a sale for export to the US. You then end up with this on the payment page "UK VAT (20%) + VAT Zero Rated for Export:". Vat is charged on the items and any store collection charge is zero rated.

I've tried on PHP 7.1 to 7.4 and it is the same. Previously I was on ZC 1.5.6 and the issue appeared when I upgraded to 1.5.7b.

Brent

Quote:

---

Originally Posted by DrByte

I'm not getting any logs in this situation. Just a quiet reload of Step 1

---

In attempts to identify how/when $_SESSION['shipping'] could "rightfully" be set to false, I think I found a condition at least as it relates to Carbonless' situation.

I find that in the page load of checkout_shipping, at about line 209 of includes/modules/pages/checkout_shipping/header_php.php the value of $_SESSION['shipping'] gets set to false even though as described above it is not expected to be such overall...

I did recreate this issue when I made store pickup to be the only shipping module that was enabled, I added a second "location" that did not have a price associated with it along with a zero price for the overall.

When I did as Carbonless suggested of loading the checkout_shipping page where no default is selected (basically because "cheapest" ignores the store pickup module even if it is the only module at play) and therefore returns false that upon page load/reload is still false and therefore fails in the orders class. Seems that perhaps a check should be performed before that point to "clear" out the shipping session in that situation? Otherwise, in the cheapest method to do some level of "accounting" where, if the only active module is the store pickup that when evaluating the cheapest option that it select perhaps the method that is not a 0 charge though perhaps that too if all charges are a 0 charge...

Not yet sure on Bruce's issue yet. Have to figure out what the condition(s) are.

I think the error does kick in when there are no available shipping options.

Last night I removed the store pickup plugin and added store pickup as a method in Conor's Advanced Shipping which I use. With only Advance Shipper active as soon as I had any products in in my basket that didn't have a shipping method assigned I got the error.

Yep, seeing more of these in my monthly checks now.

Yep

Code:

---

[09-Apr-2021 13:02:47 US/Central] PHP Notice: Malformed value for session-based shipping module; customer will need to re-select: {"id":"","title":"United States Postal Service (Priority Mail™ (2 - 3 days))","cost":19.71000000000000085265128291212022304534912109375} in /includes/classes/order.php on line 323

---

We're seeing this too on ZC157c

Has anyone got a definitive solution yet?

Quote:

---

Originally Posted by Ryk

We're seeing this too on ZC157c

Has anyone got a definitive solution yet?

---

"Solution" may depend on the conditions of the site. In another post, I identified the following conditions that could cause $_SESSION['shipping'] = false (and then the error log to be generated):

If the "cheapest" method in the shipping class has the potential to return false even if all else is "correctly" setup. That is a point where $_SESSION['shipping'] can be set to false without 'false' being hardcoded to "suit" said search...

Ways this could "physically" happen:
$this->modules is not an array (note though there are other checks and operations in normal processing at least in includes/modules/pages/checkout_shipping/header_php.php to not attempt to get the result of the cheapest function unless "basically" this condition has already been met.

So, next chance?
Basically there are no $rates calculated, this involves using the default value of $cheapest which is false at that point and the internal loop never gets processed to change the value of $cheapest to one of the rates.
Last chance within this method: an observer of NOTIFY_SHIPPING_MODULE_CALCULATE_CHEAPEST has set $cheapest to false.

So what does it take in a default install to get to the cheapest method calculation?

$_SESSION['shipping'] isn't set, $_SESSION['shipping']['id'] is not set, or $_SESSION['shipping']['id'] is falsey. Then if any of those are true, if there is at least one shipping module...

How is it that specifically no rates get set? A few different ways: $quotes['methods'] is empty (not set, an array of zero elements, a pair of quotes, the value 0, false, etc...). If there are methods with quotes but the cost is not set as in: $quotes['methods'][$i]['cost'] is not set.


Then... Doing a search for points where $_SESSION['shipping'] is set, assuming that consistent code formatting is used to then search on '$_SESSION['shipping'] = ', there are very few cases at all where it is set to anything let alone a non-array. Basically as already stated in a default install there are two places where this could occur: paying with paypal or standard checkout when stepping through the header file.

That said, there is also the assignment of $shipping_modules->cheapest to $shipping in includes/modules/shipping_estimator.php though I don't know yet what impact that would have if it is set to false at that point. And that was just found by searching on 'cheapest('. I didn't try with a space before the parentheses. Nor have I sought for any weird situations like use of a variable assigned to 'cheapest' and using it as a function...

Additionally, there is a condition possible while processing a paypal payment where the same could occur as discussed in this post, namely:
Alternatively and to wrap back around to the original question/information (started before prompted in a previous message), it looks like it could be possible that a purchase could be made with $_SESSION['shipping'] not being set if during ec_step2 the cart is determined/identified as possibly being changed, because the order is not present (does not appear to be in the path of being set until after this "change in contents") the section of code mentioned is "processed" and then with the store *not* setup to select the cheapest shipping method, then a purchase appears to be able to complete through paypal without $_SESSION['shipping'] being set. Additionally, because $_SESSION['shipping'] was unset when the cart "discrepancy" was identified, this path of processing would result in reaching the code snippet in the OP but bypassing it because $_SESSION['shipping'] is not set. So the last conditions that cause(d) unsetting are from includes/modules/paypalwpp.php at/around Line 1875:

Code:

---

(isset($response['SHIPPINGCALCULATIONMODE']) && $response['SHIPPINGCALCULATIONMODE'] != 'Callback') && (!(isset($_SESSION['paypal_ec_markflow']) && $_SESSION['paypal_ec_markflow'] == 1))

---

There doesn't appear to be anything at this point that ensures correction to the shipping session value in this situation.

Regardless, more information about store setup and ways to reach the orders class code section where the log is generated would help to identify potential corrections. (e.g. how the store is modified from original as suggested in the posting tips).

Quote:

---

Originally Posted by Brent

I think the error does kick in when there are no available shipping options.

Last night I removed the store pickup plugin and added store pickup as a method in Conor's Advanced Shipping which I use. With only Advance Shipper active as soon as I had any products in in my basket that didn't have a shipping method assigned I got the error.

---

Confirmed this is happening on a stock 1.57c install when the shipping options are not available or return as unavailable in my region.

Debug Log:
[18-May-2021 02:23:21 America/Chicago] PHP Notice: Malformed value for session-based shipping module; customer will need to re-select: false in includes/classes/order.php on line 327

This issue also happens on 1.57d, when the shipping options are not available (like to Russia).

The strange thing is, if I want to get a shipping quote in shopping cart page, there is no log or error generated. If I want to get a shipping quote during checkout process, this log file will be generated.

Quote:

---

Originally Posted by njcyx

This issue also happens on 1.57d, when the shipping options are not available (like to Russia).

The strange thing is, if I want to get a shipping quote in shopping cart page, there is no log or error generated. If I want to get a shipping quote during checkout process, this log file will be generated.

---

What shipping modules are enabled?