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

On every order placed, there is a debug file created for: PHP Notice: Malformed value for session-based shipping module; customer will need to re-select: false in /includes/classes/order.php on line 322

I cannot track down whats causing the error.
Using 1.5.7a PHP v7.3.21 (Zend: 3.3.21)

Using the shipping mod "StorePickup"

Shipping modules are supposed to set the $_SESSION['shipping'] to an array of details, starting with the data POSTed by the customer's selections during checkout.
In your case, 'false' is being set instead.

So ... something is setting the shipping method to an invalid format.

I just tried to replicate the problem, without success, as follows:

v157a PHP 7.4.12
fresh install, demo data
Store Pickup module enabled (tested it with just the default "Walk In" for the pickup name, and also with custom choices with prices; no difference in outcome)
added "Sample of Product General" to cart
went thru checkout with Store Pickup and Check/MoneyOrder
Success
No errors (except for email failing, because this test site intentionally has no email set up, but it proves that it is properly logging errors if they do occur).

This suggests that the problem is in either the way your site's code is different from a fresh install, or the steps taken to get to/thru checkout. Or maybe configuration settings of store or products.

Thank you for the reply!
It started happening with 1.5.7 after I added a 2nd address for selecting a pickup location. I then upgraded last night to 1.5.7a hoping to fix it.
I could try uninstalling the shipping mod and reinstalling it? Or do you think this a file modified somewhere? ... or missing?

When I added a 2nd address (actually 3) to test, I just copy-pasted the example:

Sunnyside,4.00;Lee Park,5.00;High Street,0.00

How is yours different?

FIGURED OUT WHATS CAUSING THE ERROR.... If a customer FAILS to select a pickup location using the Store Pickup shipping mod, its causing the debug error.

Every time I attempted to click CONTINUE from Step 1 to Step 2, it reloads step 1 page for mandatory selection of pickup location.

DrByte:

When I added a 2nd address (actually 3) to test, I just copy-pasted the example:

Sunnyside,4.00;Lee Park,5.00;High Street,0.00

How is yours different?

Ahhh... I am not including ANY value with the option, as it's 0. Should I add the 0.00 to the addresses?

CURRENTLY
Oak Park Temple - 1235 N Harlem Ave - River Forest; (Alternate pickup location for Thanksgiving Meal ONLY) Beat Mix Music - 3200 Doolittle Dr - Northbrook

Carbonless:

Ahhh... I am not including ANY value with the option, as it's 0. Should I add the 0.00 to the addresses?

CURRENTLY
Oak Park Temple - 1235 N Harlem Ave - River Forest; (Alternate pickup location for Thanksgiving Meal ONLY) Beat Mix Music - 3200 Doolittle Dr - Northbrook
No, if it's 0 then the price is not necessary as long as locations are separated by semicolons.

Carbonless:

If a customer FAILS to select a pickup location using the Store Pickup shipping mod, its causing the debug error.

Every time I attempted to click CONTINUE from Step 1 to Step 2, it reloads step 1 page for mandatory selection of pickup location.
I'm not getting any logs in this situation. Just a quiet reload of Step 1

DrByte:

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

Over the holiday, I'll attempt to delete the shipping mod and then redo it to see if that clears it. I think somewhere I edited one of the files to change the wording displayed in the checkout process... I may have deleted an extra character or entered a character misinterpreted.

I have seen this a few times as well - will monitor and report back on findings.

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

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

[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?

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:

(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).

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.

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?