ozpost shipping module

[belabela]

The link you provided is working fine - can get an xml result back from that without any problem.

Turning on debug mode for the ozpost module, and telling the module to spit out the value of $qu before it hits line 345, it seems to me that not returning data in xml format? under some conditions which is then throwing line 345 which tries to process the xml...?

Not sure what triggers it to work/not work as have another site on the same server that is working absolutely fine without any problem....? Can't find any material differences between those two sites at all.

Putting in the code die ($qu);exit after the $this->_getAPdata line in the offending module, returns

324 PPS39.94 3Kg Prepaid SatchelPPSE311.31 3kg Prepaid Satchel ExpressRPP11.6 4 Regular ParcelREG14.45Registered ParcelEXP17.3 1 Express ParcelCOD21.85Cash On Delivery 0 2.8 0

shouldn't this be xml? or did I do something wrong.

I'll sit on it until tomorrow to see if further propagation fixes it, but just wanted to raise this as a potential problem in case it raises any flags for you and is indeed a bug. hope this helps.

fingers crossed.

[RodG]

The link you provided is working fine - can get an xml result back from that without any problem.

Turning on debug mode for the ozpost module, and telling the module to spit out the value of $qu before it hits line 345, it seems to me that not returning data in xml format? under some conditions which is then throwing line 345 which tries to process the xml...?

Not sure what triggers it to work/not work as have another site on the same server that is working absolutely fine without any problem....? Can't find any material differences between those two sites at all.

Velly Interllesting. Could you please do me a big favour and do the debug test on both your sites to see if you can see any difference in regards to the xml?

Putting in the code die ($qu);exit after the $this->_getAPdata line in the offending module, returns

324 PPS39.94 3Kg Prepaid SatchelPPSE311.31 3kg Prepaid Satchel ExpressRPP11.6 4 Regular ParcelREG14.45Registered ParcelEXP17.3 1 Express ParcelCOD21.85Cash On Delivery 0 2.8 0

shouldn't this be xml? or did I do something wrong.

You are doing all the right things, and yes, the data should be xml (which is why I'd like you to do this same exersice on both sites).

There are three possibilities here...
1. The server isn't always returning valid xml for some reason (you should probably see the difference between your two sites).
2. The server is returning xml, but the xml tags are being stripped when displayed to screen. This is what happens when I use that test link using MS Explorer rather than Firefox.
3. Still a mystery.

I'll sit on it until tomorrow to see if further propagation fixes it, but just wanted to raise this as a potential problem in case it raises any flags for you and is indeed a bug. hope this helps.
.

Your findings could be very important and valuable clues, especially since you appear to be in a rare position to have two sites operational, one that exhibits a problem and the other doesn't. If these two sites consistantly behave this way I have a feeling that I will be relying heavily upon you to help me find the cause (and therefore the fix).

As you can imagine, since none of the sites that I maintain (or have direct access too) don't exhibit any troublesome behaviour it is going to be impossible for me to work alone to solve the issue, so any clues, no matter how small is most welcome.

Cheers
Rod

ps. I wonder if it has anything to do with wether the server access is via 'cURL' or the http (file) method. Which of these do you use on your sites?

[kaety]

Hi Rod,

Our clients and we are seeing an error message to do with VCSWEB error?

Services will be restored ASAP.
We apologize for any inconvenience.
Telnet/SSH members,if you can't login please use "herbie.vcsweb.com" instead of 'vcsweb.com"

FreeDNS Users  - It was abuse of this system that has caused all of our current problems.  This service is no longer available. The nameservers themselves have just been brought back online on a temporary basis. We suggest you use a network tool (dig, nslookup, etc) to recover any zone data that you require and migrate to alternate nameservers as soon as possible.  We recommend www.xname.org

Web/Email Customers -  We are doing all we can to migrate your data to new servers with minimum disruption to services. If you are getting authentication errors when trying to pick up your email you will need to update your LOGON name from "yourname" to "yourname@yourdomain".

No other changes should be required. 

 

 Please send us an email for any other issues.  admin @ vcsweb.com

Could you shed some light on this??

[belabela]

Have established that the problem is not dns, but something to do with how the data gets translated after it comes back from the server. The server IS connecting and returning valid xml.

Here's how I established that:
- Put some code into the getAPdata function to write the request url to a file
- Put the request url into a browser manually and inspected the result
- Copied the result from the browser manually into the $xml = SimpleXMLelement line in the code and ran the shipping estimator: yes, it returned results okay.

So the problem is how the data is translated in the getAPdata function - the data variable being returned must be somehow being corrupted in the site that is working versus the site that isn't.

Am running some more tests in the getAPdata function on the site that is working and the site that isn't and comparing the results. Will report back when I can. Any ideas or things to look at appreciated as my php coding skills are pretty basic.

[belabela]

p.s. I have been using http but changing to curl doesn't seem to make a difference

[belabela]

Here is what is being returned by the getAPdata function when it is not working....

3d
<?xml version='1.0' encoding='ISO-8859-1'?>
<quotes>

<quote>
89
<id>PPS3</id><cost>9.9</cost><days>4
</days><description>3Kg Prepaid Satchel</description></quote><quote><id>RPP</id><cost>10.5
</cost>
25e
<days>4
</days><description>Regular Parcel</description></quote><quote><id>PPSE3</id><cost>11.3</cost><days>1
</days><description>3kg Prepaid Satchel Express</description></quote><quote><id>REG</id><cost>13.3</cost><days>5</days><description>Registered Parcel</description></quote><quote><id>EXP</id><cost>14.2
</cost><days>1
</days><description>Express Parcel</description></quote><quote><id>COD</id><cost>20.7</cost><days>5</days><description>Cash On Delivery</description></quote>
<information>
   <insurance>
   0   </insurance>
   <registration>
   2.8   </registration>
</information>


</quotes>
0

There's an extra 3d appearing at the start of the text and a '0' at the end. If you run the url that generated this in a browser, you get:

<quotes>
−
<quote>
<id>PPS3</id>
<cost>9.9</cost>
<days>4
</days>
<description>3Kg Prepaid Satchel</description>
</quote>
−
<quote>
<id>RPP</id>
<cost>10.5
</cost>
<days>4
</days>
<description>Regular Parcel</description>
</quote>
−
<quote>
<id>PPSE3</id>
<cost>11.3</cost>
<days>1
</days>
<description>3kg Prepaid Satchel Express</description>
</quote>
−
<quote>
<id>REG</id>
<cost>13.3</cost>
<days>5</days>
<description>Registered Parcel</description>
</quote>
−
<quote>
<id>EXP</id>
<cost>14.2
</cost>
<days>1
</days>
<description>Express Parcel</description>
</quote>
−
<quote>
<id>COD</id>
<cost>20.7</cost>
<days>5</days>
<description>Cash On Delivery</description>
</quote>
−
<information>
<insurance>
   0   </insurance>
<registration>
   2.8   </registration>
</information>
</quotes>

Any ideas what could be causing this and how to fix? Off to try the site that does work now with a similar product/weight/destination setup...

[belabela]

Could the problem have anything to do with chunked transfer encoding?

http://en.wikipedia.org/wiki/Chunked_transfer_encoding

That could explain the 0 at the end but not sure if it is the actual explanation. I'm just throwing ideas out there....

[belabela]

I had the path to curl wrong - using curl DOES seem to fix the problem!

This suggests to me that the chunking transfer with http method does seem to be the problem with the http method - at least on my installations - as it is corrupting the xml. Not sure how to change the getAPdata to test for chunked transfer method and to correct for it as my php skills are not good enough nor how to check the xml returned to look for and catch the line 345 error before calling simplexmlelement.

one major difference between the site that works and the one that doesn't is that the one that does not is using mod_deflate on the server for compression (hence the chunked transfer mode) whereas the one that doesn't is not.

So it seems to me that the tempoary fix if you're having the problem is to turn curl on. Make sure you're using the latest template file too, because otherwise the destination postcode doesn't always get passed to the shipping estimator.

[remoteone]

RodG,
It looks like the server is running, but my Checkout process still just gives me a Blank Page at main_page=checkout_shipping.
The estimator is working, returning the correct costs, but customers cannot check out. I havent changed anything in Zen, apart from setting up Flat rate shipping.
No PHP errors are logged, just a blank page, when ozpost is enabled

Your help appreciated.

[Peter Homann]

RodG,
It looks like the server is running, but my Checkout process still just gives me a Blank Page at main_page=checkout_shipping.
The estimator is working, returning the correct costs, but customers cannot check out. I havent changed anything in Zen, apart from setting up Flat rate shipping.
No PHP errors are logged, just a blank page, when ozpost is enabled

Your help appreciated.

I had this problem and solved it by setting the use Curl to true.

Cheers,

Peter.