New line in 5.2.16 cubecart.class

[Dirty Butter]

What does this new line 835 cubecart.class.php do?

 

                $old_addresses = md5(serialize(array_merge($this->_basket['billing_address'],$this->_basket['delivery_address'])));

 

I have another error message referring to it - the only one left as of now!!

 

PHP Warning:  array_merge() [<a href='http://docs.php.net/manual/en/function.array-merge.php'>function.array-merge.php</a>]: Argument #1 is not an array in /xxx/public_html/plushcatalog/classes/cubecart.class.php on line 835

 

 

[bsmither]

About 50 lines later, a similar statement gets a hash of the same thing.

 

Between these two statements, CubeCart is updating the basket's billing and delivery addresses from the customer first filling out or later changing their addresses.

 

If the addresses are not the same, that is, the customer changed the billing/delivery address at the step just prior to choosing how to make payment, a Notification is queued.

 

Any queued Notifications or Warnings will prevent CubeCart from moving the customer to the Make Payment page.

 

This test is done to prevent a customer from saying the delivery address is just across town from you on one page, then, at the last moment, changing it to Nigeria yet keeping the previous shipping costs.

 

You get PHP's warning because Cubecart does not use a default billing address, like it does with a default delivery address (your store).

 

To get rid of the error message, we can try:

Was:
$old_addresses = md5(serialize(array_merge($this->_basket['billing_address'],$this->_basket['delivery_address'])));
 
Now:
$old_addresses = md5(serialize(merge_array($this->_basket['billing_address'],$this->_basket['delivery_address'])));

And again for the $new_addresses.

 

This CubeCart function, merge_array(), tests for an empty first array, and if so, returns just the second.

 

This also applies to CC6.

[Dirty Butter]

I was hoping it was something like that. In the past I have added some wordage at the point where the Update button stands above the shipping choices in Blueprint to try to solve this issue.

 

"Any queued Notifications or Warnings will prevent CubeCart from moving the customer to the Make Payment page."

 

Does this code depend on code somewhere in the skin? If so, I'll need to fiddle with Blueprint.

 

It's fine to get rid of the error message in the log, but I certainly don't want to defeat the usefulness this provides.

[bsmither]

"Does this code depend on code somewhere in the skin?"

 

No. It (should) be in the CubeCart class.

[Dirty Butter]

Just tried a couple of scenarios, and neither created an error message in the log.

 

1. Changed destination and clicked Checkout - possible shipping choices changed and customer remained on Checkout page, giving them a proper chance to select appropriate s/h - PERFECT!!

 

2. Changed shipping choice only and clicked Checkout - s/h cost in the order did not change if customer did not Update before clicking Checkout - not quite perfect in my mind, as they first see what they actually owe on PayPal, not on our site.

 

I think I'll leave my verbage above the Update button - "To See Accurate Charges BEFORE CHECKOUT Update if Shipping Method or Delivery Address is Changed"

 

UNLESS there's a way to force that update of price before Checkout transfers to gateway!!! That would be IDEAL!

[bsmither]

"s/h cost in the order did not change if customer did not Update before clicking Checkout"

 

That part is suspicious. If I recall, changing the shipping choice is an "auto-submit" action that will POST the alternate shipping choice and cause CubeCart to recompute the taxes (if any apply to shipping), derive a new Grand Total, and deliver the new page back to the browser.

 

So, having the need for the web form to be manually Updated (POSTed) is a concern.

 

To be clear in my mind - a stock skin or a third-party skin?

[Dirty Butter]

No, this is Blueprint. I'll try that second scenario again and verify. NO - Blueprint does NOT update s/h change automatically. If Vanilla does, I'll see if I can figure out how to work that code in - well, I'll try LOL.

[bsmither]

It's javascript-powered - the auto-submit.

 

I'll scan through the Blueprint templates and see if there is anything I can find - shortly.

[Dirty Butter]

Yes, I just tried Vanilla, and it automatically refreshes the page. This is definitely a Blueprint issue. Not pressing, but will need to be fixed.

[bsmither]

As you know, I do not actually run any Fusion-based skin, so this is an experiment that you must try on your own.

 

In the skin file /blueprint/js/application.js, near the bottom:

Find:
    // =============================
    // = Automatic Form Submission =
    // =============================
    //
    // Used for transferring to
    // gateways automatically.
 
Add after:
    $('select.update_form').change(function(){
        $('input.required').removeClass('required');
        $(this).parents('form').submit();
    });

This comes from the standard common javascript that all stock skins use.

 

Then, in the skin template file element.basket.php, near line 90:

Was:
<select id="shipping" name="shipping" required class="required">
 
Now:
<select id="shipping" name="shipping" required class="update_form required">

[Dirty Butter]

I HAD THAT SKIN SECTION COMMENTED OUT - I THINK MAYBE TO SHOW ALL S/H CHOICES. I'll work on this again tomorrow when my head is clear. Thanks!!! You always amaze me

[Dirty Butter]

I was right about why I have that commented out. We have so many customers who are not used to buying online I felt they needed help understanding all s/h choices available to them. But given the automatic behavior of the <select id="shipping" name="shipping" required class="update_form required"> - that seems even MORE important. Will try going back to the radio button for s/h choices and see how customers do.

[bsmither]

"Blueprint does NOT update s/h change automatically."

 

This leads me to believe that she shipping choices are being displayed. But in what manner if that section was commented out?

[Dirty Butter]

You had helped me with this sometime in the past.

<!-- BSMITHER FIX TO SHOW ALL SHIPPING CHOICES TO CHOOSE FROM -->

          <!--<p><span style="font-weight:bold;">{$LANG.basket.shipping_select}</span></p>-->

<p>To See Accurate Charges BEFORE CHECKOUT
<br> Update if Shipping Method or Delivery Address is Changed)			
							<a href="#hardsubmit" class="button">{$LANG.common.update}</a>
	</p>
<div class="update_form required price" style="display:inline-block;text-align:left;">
          <ul style="list-style-type: none;">
          {foreach from=$SHIPPING key=group item=methods}
          {foreach from=$methods item=method}
          <li style="padding-left:14px;"><input name="shipping" type="radio" value="{$method.value}" {$method.selected|replace:'selected':'checked'} />{$CUSTOMER_LOCALE.mark} {$method.display}</li>
          {/foreach}
          {/foreach}
          </ul>
{if $CUSTOMER_LOCALE.description}
	<strong>{$CUSTOMER_LOCALE.mark} {$LANG.basket.unconfirmed_locale}</strong>

{/if}

        </div>
<!--ALSO CHANGED  /js/common.js, ON line 109 find: $('select.update_form').change(function(select){
Removed the word select. 

END OF FIX -->

(The change to js/common.js wasn't necessary, as 5.2.16 stock now has that change.)

[bsmither]

Putting 'update_form' on a <div>...... Hmm......??

[bsmither]

I wonder what would happen if:

Was:
<div class="update_form required price" style="display:inline-block;text-align:left;">
 
Now:
<div class="price" style="display:inline-block;text-align:left;">
 
Was this part:
<input name="shipping" type="radio"
 
Now this part:
<input class="update_form required" name="shipping" type="radio"

[Dirty Butter]

I'm happy with the way it works with autoupdate. Thanks, anyway.