Changing Address causes Custom View to be ignored

Hi Guys,
I have a custom view for show-block-cart.php however when someone chooses a different address in the checkout, the page refreshes with the original show-block-cart file. This seems to be somehow related to Ajax. If I then refresh the browser it again finds the correct file. I need to resolve this as a matter of urgency as the site is live.

Hi,

The AJAX system does support overrides.
So the only reason I can think of is that during the AJAX call to refresh the "cart" view, another template of your website is being used and this other template doesn't have the override on show_block_cart.php
So I would recommend first to do two things:
- do the override on show_block_cart.php for all your template on the frontend and see if that helps.
- if not, you could provide a link to the shop with precise instructions to reproduce the issue.

That is a concern. We do have a different template for the last step of the checkout precisely because the customer wants a cut down view of the cart in that step and for them it is non-negotiable (this is a product portal for one of Australia's biggest companies and they are not at all flexible on styling issues). The first step of checkout is the full cart display. The site is a private portal so I will send the access details separately. Steps to reproduce are simple. Got to checkout and select an alternative address.

I sent the access details last week, has anyone looked at this yet? It is causing our client a lot of angst.

Hi,

I replied to you by email then with this message:

Hi,

It's you who gave me the .com URL, and not the .com.au URL. The first link to the .com.au URL you gave didn't work, and the second one you gave was the .com URL... I'm sorry but I'm working with what I have.

I'm not able the reproduce the same problem you're talking about.
When I follow your instructions, I arrive on the checkout with only one address already preselected. So I can't select another one.
So I went and tried to create a new address.
But then, when I validate the new address, I get that error:
monosnap.com/file/gCQT1mbhgryvdMdtgyDD5egvHikCQE
Could you activate the "debug mode" of the Joomla configuration to get the full error message so that I can tell you what to do to fix that issue ?

Best regards,
Nicolas

You must have got the email in your spam folder for some reason.

The site is crashing with error "1054 - Unknown column 'test_hikashop' in 'where clause'". Are you testing anything?

Edit. OK found the problem,. The custom shipping plugin only recognizes Australian postcodes and the address you added was in France. Will need to put some error checking into our plugin.

I've activated debug mode but there is nothing in messages. What should I be looking for?

I've narrowed down the issue to a custom payment plugin that has to recalculate shipping on a change of address but have no clue what I should be looking for. What is the event that triggers the refresh of shipping calculations?

Hi,

The debug mode activation was to understand where that 1054 error message was coming from. Since you already figured out, then no need to activate it.

The shipping fees are calculated dynamically each time the cart is loaded.
It's done with a call to the onShippingDisplay function of the plugins of the group "hikashopshipping".
So I don't know why a payment plugin would modify the shipping fees, but in that case, it's possible that it won't be triggered all the time since it isn't in the hikashopshipping group and isn't supposed to implement the onShippingDisplay function.

Back on deck with this project. I have narrowed down the cause of the problem to a custom shipping plugin (I miss typed as payment earlier). The shipping plugin was created as a modification of the older Australia Post plugin some years ago (not the current one). I have looked through the code but not sure what I should be looking for. Are there specific events or code that I should be checking for?

Hi,

First we need to recap where we're at.
What is the current problem you're trying to solve ? A mysql query error ? The layout of the cart not using the override upon address change ? Something else ?
And why do you think it comes from this custom shipping plugin ?
If you deactivate and use instead the default Australia Post shipping plugin you don't have the problem ?
If you could give a zip of the plugin and tell us what was customized in there, that might also help us better understand the situation.