[SOLVED] Inconsistent "Shipping method required" error IE8

REPOSTED IN GENERAL SUPPORT (rather than GENERAL DISCUSSION)

Folks,

Got a curly one that customers reported and I've only just been able to reproduce.

Platform: OC 1.5.4.1 (installed inside Joomla 2.5.8 using Mijoshop 1.3.4).

User browser: IE 8 (8.0.6001.19401). Problem does not appear in IE9, or Firefox, or Chrome.

The issue I'm hitting is that when people run through the ordering and checkout process without doubling back then it all works fine. However, if they double back to Step 2: Billing Details of the checkout process after getting down to Step 5, or they add more items to their cart and then start the checkout process again, they get the dreaded "Warning: Shipping method required".

The nasty thing is that there is a shipping method selected. Refer the attached screenshot - this occurs AFTER hitting the continue button. Just to clarify - even users on IE8 can successfully checkout if they just flow through as normal. The easiest way to reproduce is to get down to step 5 and then click on the "Modify>>" link for step 2. Then roll back through the steps until the error appears.

I'm stuffed if I know how to troubleshoot, and why a particular browser version could be causing this logic problem. The platform works just fine for all other browsers.

I have disabled all my VQMODs to make sure it wasn't any of my code changes.

Any ideas on why or how to troubleshoot?

Thanks,
Danny.

Every browser and version of it paints screens its own way, with generally broad overlap among them. They all have their quirks.

Pure guess: backpeddling upsets fore- and backward sense of the browser version, and MS or somebody on-line probably has a code snippet for doing that 8's own way. Just be happy it's 8 rather than 6.

Thanks Butte.

The thing that is doing my head in is that this isn't a display problem, but rather a logic problem. My understanding of Opencart is that the logic is housed within the php in the back-end, which shouldn't be impacted by the presentation layer.

I'm putting in some additional debugging to see if I can work out what IE8 is doing to screw up the variables that carry the data that drives the behaviour of that error message.

The logic contributing to the variables contributing to the states contributing to the screen painting are all swept in. That in overview is why the wake for IE6 will be populated mostly by its enemies. There is a limit to how many of us will write how many code variants to accommodate how many different browsers, versions, search engines, local operating systems, and whatnot.

OK - done some more troubleshooting into what is going on, and it looks like something odd is happening with the session information. I dumped the $this->session variable and compared what happens when everything works OK vs when IE8 stuffs it up, and here's what falls out.....

Working session:
step2: [session.counter] => 5 [session.timer.last] => 1364526050 [session.timer.now] => 1364526061
step3: [session.counter] => 8 [session.timer.last] => 1364526077 [session.timer.now] => 1364526080
step4: [session.counter] => 11 [session.timer.last] => 1364526107 [session.timer.now] => 1364526110
step4b: [session.counter] => 14 [session.timer.last] => 1364526117 [session.timer.now] => 1364526125
step5: [session.counter] => 15 [session.timer.last] => 1364526125 [session.timer.now] => 1364526129
Jump back
step3: [session.counter] => 17 [session.timer.last] => 1364526162 [session.timer.now] => 1364526166
step4: [session.counter] => 20 [session.timer.last] => 1364526187 [session.timer.now] => 1364526190
step4b: [session.counter] => 23 [session.timer.last] => 1364526198 [session.timer.now] => 1364526223
step5: [session.counter] => 24 [session.timer.last] => 1364526223 [session.timer.now] => 1364526227

Note on the step numbers. "step2" refers to the status of the session variables upon entering step2 of the checkout process (Billing Details). Step 3 and 4 are same for the respective steps. Step4b is the session variables as set within the shipping_method/validate function (called when the CONFIRM button is clicked within step4).

As is evident by the results, the session.counter continues to increment with each call to the webserver, and the timers also increment.

Now for the IE8 results:

Step 2: [session.counter] => 7 [session.timer.last] => 1364523432 [session.timer.now] => 1364523445
step 3: [session.counter] => 10 [session.timer.last] => 1364523502 [session.timer.now] => 1364523505
step 4: [session.counter] => 12 [session.timer.last] => 1364523525 [session.timer.now] => 1364523528
step 4b: [session.counter] => 13 [session.timer.last] => 1364523528 [session.timer.now] => 1364523552
step 5: [session.counter] => 14 [session.timer.last] => 1364523552 [session.timer.now] => 1364523556
Jump back to
step 3: [session.counter] => 10 [session.timer.last] => 1364523502 [session.timer.now] => 1364523505
step 4: [session.counter] => 12 [session.timer.last] => 1364523525 [session.timer.now] => 1364523528
step 4b: [session.counter] => 17 [session.timer.last] => 1364523629 [session.timer.now] => 1364523648
this last step gets the error ("Shipping method required") and I can see that the shipping_methods array is no longer set within the shipping_methods/validate function.

What is odd here for me is that when the user jumps back to earlier steps, the session.counter reverts back to the values from the original pass through the steps and then obviously gets confused (and something happens to the most important session data such as the shipping_methods array.

So, is this a problem with the opencart code?
What is responsible for maintaining the session counter - is it the webserver, or does the browser play a role in setting these values?

Cheers, Danny.

Sessions are set in .php and sent (along with rendering) to the browser, then the browser accepts them and writes them onto the client machine (or denies them, and that causes problems while browser and .php might be, as it were, arguing or stalemated about it).

How are cookies or session cookies set in the browser?

Try flushing cookies but don't go anywhere . . . then try flushing browser cache but don't go anywhere . . . then axe and restart browser.

Finally someone else with this issue!

I have been looking for a fix for this for over a month now, at first I wasn't able to replicate it, but I also discovered its only IE that does this when a customer modifies any data before checking out.

Please can someone give us a fix for this issue?

G'day Insomniak,

Sorry to hear that you've been battling with the problem for some time now, but also glad that I'm not the only one going bonkers over trying to work this out.

A quick question about your environment - are you running OC standalone, or are you running it inside Joomla like I am?

Cheers, Danny

Good News!!! I've just worked out that the problem is caused by IE caching the ajax get requests.

Traced the http transactions using fiddler and could see that IE was not sending the same requests that the other browsers were.

Simple solution - just set "cache: false" for each ajax get request.

I've created a vqmod to set all the ajax requests in checkout.tpl to not cache: I'm sure that there are other ways of implementing this, but it seemed expedient to just change the checkout rather than making this a global change.

Cheers, Danny.

Hi Danny,

I am running a standalone OC.

I am going to try and implement your vqmod to see if it works.

Will reply soon!

Just uploaded the vqmod and tested with IE9 and it looks like the problem is gone!

I added items to the cart, done guest checkout, selected shipping, then payment, then clicked back to modify address data, and it still let me progress, then clicked back and added more items and it still worked.

I am not great at reading code and fixing errors, so thank you very, very much for this!

clubnamatjira wrote:Good News!!! I've just worked out that the problem is caused by IE caching the ajax get requests.

Traced the http transactions using fiddler and could see that IE was not sending the same requests that the other browsers were.

Simple solution - just set "cache: false" for each ajax get request.

I've created a vqmod to set all the ajax requests in checkout.tpl to not cache:

Code: Select all

<modification>
	<id>Fix IE ajax caching issue</id>
	<version>1.0</version>
	<vqmver>1.0.0</vqmver>
	<author>Danny O'Brien</author>
				
	<file name="catalog/view/theme/default/template/checkout/checkout.tpl">
		<operation>
			<search position="after"><![CDATA[
				$.ajax({
			]]></search>
			<add><![CDATA[
				cache: false,
			]]></add>
		</operation>
	</file>
</modification>

I'm sure that there are other ways of implementing this, but it seemed expedient to just change the checkout rather than making this a global change.

Cheers, Danny.

Total newbie and found this post in the forum as I am having same problem with only one order on a storefront. Does the vqmod code you wrote get pasted in the checkout.tpl file or the vqmod.php file? Not sure exactly where to put it?

Hey jprout,

Just create a file called whatever you want (eg. set-cache-false.xml) with the content from the vqmod script, and then drop it into the /opencart/vqmod/xml directory. There should be other xml files in there as well.

Cheers, Danny.

If i delete an order or refresh the order quantity I am facing the same error " shipping method required" while using chrome and also Firefox during guest checkout or even logged in account checkout .I have tested on fresh install of opencart's on version 2.0.3.1 ,2.1.0.1,2.1.0.2 and also 2.2.0.0 and facing the same issue.Request for the solution for the same from the members

Hi Stumbleup,

Have you tried putting the vqmod code in place to tell the system not to cache ajax requests?

The original problem that I had was due to IE8 caching the request (ie. assuming that because it had already made that request to the server, it would just reuse the results rather than asking the server again).

If you have already implemented the "fix", then it may be that something else is going wrong. The way I found out the problem was to install fiddler onto my PC and then did a network trace to watch what was being sent to the server and what was returned. It may be that you can just use the embedded network tracing tools in your browser to capture what is happening. I simply compared the traffic between a working session (not IE8) and the IE8 session and saw that there were calls missing from the IE8. It was then a matter of consulting Dr Google as I could then see that it was the ajax requests that were missing.

Hi, I'm facing the same issue in opencart 3.0.3.8 version using on chrome. Will the solution provided above still work for this version of opencart or there shall be any changes in code and under which directory/folder of opencart, it needs to be pasted? Please help!