ozpost shipping module

...part 4!! I have been assured that that estimate is OK ...

so basically I no longer have any issues:smile:

p1drobert:

Hi peter,

Yes, I got the same error, although for a lot less weight. I've got a tare weight on the packaging boxes of about 0.1kg. It might have something to with the error occurring at different weights. I don't know, but there's definitely a weight error happening.

I found my problem here. Mayber it is relevant to you as well.

I set my weights as Kgs, as in 0.4kg 0.15kg etc.

When I installed ozpost, I mistakenly set the weight to gms and NOT Kgs.

When I changed it to Kgs the error went away.

With my error set up, ozpost was failing when the total weight was less than 0.5gm Not a surprise really :)

Maybe you have the same error?

Cheers,

Peter.

kaety:

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

[code]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"

Hmm, where are you seeing this?

What you are seeing is our default webpage, which should only happen if you go to our site with a web-browser. (ozpost.vcsweb.com and our client's website sites have a higher priority in regards to our restoration efforts)

If you are somehow seeing this from within zen-cart please supply the URL to your store 'cos I'd need to check this out for myself.

Rgds
Rod

belabela:

using curl DOES seem to fix the problem!

Excellent! I think we are getting somewhere. I rally do appreciate the effort you have put into this, and sorry for not being able to give you more timely responses, the timezone differences are mainly to blame for this. I'm here when you should be sleeping, and you've been debugging whale I've been sleeping.

belabela:

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.

This is all new to me, so I'm not sure how to test either.

belabela:

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.

Thanks. I've taken note of this too.

belabela:

So it seems to me that the tempoary fix if you're having the problem is to turn curl on.

I'm not sure I'd call this a temporary fix, because cURL is actually the preferred method these days (it is more secure than http for the ISP). In fact many ISP's have disabled the http method.

This is why the module gives a choice, some ISP's don't allow the http method, and others have been slow to implement cURL.

In short, I would consider cURL to be the permanent fix. At least for those that are able to use it.

belabela:

Make sure you're using the latest template file too, because otherwise the destination postcode doesn't always get passed to the shipping estimator.

Wise advise. Although this template file is actually optional,
upon first quote, unless a user is logged in, the module doesn't have a destination postcode to work with, so one of the tweaks I made to this file was to check if a postcode exists, and if it doesn't, it outputs a store disclaimer and an input box to force a postcode entry, else it'll try to quote a parcel to nowhere, which is sure to return an invalid response.

Anyway, once again I thank you for your help.

Cheers
Rod

p1drobert:

Hi Rod,

Heres some noted bugs.

When the weight of the products are small as in .0001Kg the server reports a weight error.

Anything to do with weights is not really a bug. It is invalid input data.

p1drobert:

Also as noted with remoteone above I get a blank screen on checkout; however the estimate shipping page is ok.(mostly).
I have to do a refresh to get something shown, and it looks wrong.

Use cURL (if possible and you haven't already done so).

p1drobert:

I haven't been able to try disabling curl as suggested because I deleted all the files and will need to try again later.

cURL needs enabling, not disabling.

p1drobert:

I don't think the current ozpost module was ready for release, or at least not to so many people. Unfortunately with the old module going down every one has been jumping onto the new module and its clearly not ready.

The ozpost module was released seven months ago. All problems reported since then have been fixed.

If people have tried it during this time, found they had a problem and didn't bother to report it, as I now suspect is the case, then I can only say that it is their own fault for finding themselves in the current situation.

Likewise, it has been made well known (via these forums) that the old AustPost module is no longer supported and has been giving erronious quotes (due to changes in postage costs) since July, so they've had ample time to notice this and upgrade and report any issues with the new module.

I can only do testing and debugging on servers I have access to. I find it almost impossible to believe that not a single person has experienced the current problem before now. Why hasn't it been reported?

The real pisser is that now the problem has been highlighted I simple can't spend the time finding a solution since I have far to many other issues to deal with.

Getting the ozpost server migrated and operational again was a high priority, especially since I'd figured there were no bugs to fix with the client software. It is somewhat annoying to find that this isn't the case, but the timing couldn't be worse.

Cheers
Rod

RodG:

Anything to do with weights is not really a bug. It is invalid input data.

Hi rod,

thanks for the reply. I realize the pressure you're under. I do custom electronics design myself.

These same weights seem to work fine with the old AUSTPOST module. The old AUSTpost module was great and I miss it. I fail to see how adding one of these items creates an error but adding 5 does not if its not a bug, Any other heavier product does fine too so I'm not sure what you mean "not a bug". Never mind, as I can live with that as long as I can figure out why I'm getting a blank page at checkout.

Use cURL (if possible and you haven't already done so).

By this I take it you mean set the USE CURL question to YES.
Yes have done this but still get a blank page. Is there another setting on my host server that I need to activate as well?

The ozpost module was released seven months ago. All problems reported since then have been fixed.

If people have tried it during this time, found they had a problem and didn't bother to report it, as I now suspect is the case, then I can only say that it is their own fault for finding themselves in the current situation.

As I said, I liked your old module so much that I saw no reason to shift to the new one. Until recently when the old one stopped working. I expect a lot of people are doing the same now which might explain why there's more problems reported now than 6 months ago. Also the problem does not occur with zencart version 1.3.7, only for 1.3.8. I have a backup zencart running on 1.3.7 so I was able to check this. Human nature being what it is, any one that tried the new module and found it not to work would probably just go back to the old one and not worry about it. This time we can't go back to the old one.

I've noted this odd occurrence. If icons are enabled the icon next to the ozpost module in the shipping page is missing. The properties show

myurl/catalog/admin/DIR_WS_TEMPLATEStemplate_default/images/icons/ozpost_logo.jpg

This is clearly wrong. The DIR_WS_TEMPLATE seems to be interpreted as part of template_default string. I'm wondering of this might have something to do with the problems I'm noticing.

Peter Homann:

I found my problem here. Mayber it is relevant to you as well.

I set my weights as Kgs, as in 0.4kg 0.15kg etc.

When I installed ozpost, I mistakenly set the weight to gms and NOT Kgs.

When I changed it to Kgs the error went away.

With my error set up, ozpost was failing when the total weight was less than 0.5gm Not a surprise really :)

Maybe you have the same error?

Cheers,

Peter.

Hi Peter,

Thanks for your reply. No, I already had my weights and the ozpost module set to kg. Heavier weights have no problem.
I suspect there's some sort of truncation of a few decimal points happening before it gets to the ozpost server.

p1drobert:

Hi Peter,

Thanks for your reply. No, I already had my weights and the ozpost module set to kg. Heavier weights have no problem.
I suspect there's some sort of truncation of a few decimal points happening before it gets to the ozpost server.

My guess is that it is sending a weight of 0 that causes the problem. Is it possible to add a line into the php that checks for this and if so sets the weight to a minimum value?

Cheers,

Peter.

I've just been doing some testing because I've got the same problem with a store.

I've always had my weights set to kgs and was previously using AustPost - Improved, no TARE.

The tests I did so far with OzPost are as follows:

1 item 0.2kgs = unexpected error (no valid methods). Using AP Flat Rate.
2 items at 0.1kgs each = quote obtained for regular parcel and 500g satchels
2 items at 0.05kgs each = quote obtained for regular parcel and 500g satchels (I'm assuming this is because of my dimensions H2 x L10 x W15)

It looks so far like the problem is with single item purchases. However, I have tried single item purchases at higher weights and they work. Just trying to find out what the threshold weight is for this right now.

Cheers
Andy

Peter Homann:

My guess is that it is sending a weight of 0 that causes the problem. Is it possible to add a line into the php that checks for this and if so sets the weight to a minimum value?

Cheers,

Peter.

ionebusiness:

I've just been doing some testing because I've got the same problem with a store.

I've always had my weights set to kgs and was previously using AustPost - Improved, no TARE.

The tests I did so far with OzPost are as follows:

1 item 0.2kgs = unexpected error (no valid methods). Using AP Flat Rate.
2 items at 0.1kgs each = quote obtained for regular parcel and 500g satchels
2 items at 0.05kgs each = quote obtained for regular parcel and 500g satchels (I'm assuming this is because of my dimensions H2 x L10 x W15)

It looks so far like the problem is with single item purchases. However, I have tried single item purchases at higher weights and they work. Just trying to find out what the threshold weight is for this right now.

Cheers
Andy

Single item weight limit to get a quote is 0.51kgs. It gives quotes for regular parcels and 3kg satchels.

Peter/Rod

Use of the cURL option in the Ozpost control panel appears to have removed the uncaught exception error on my charcool site as well.

Don't understand why it began playing up and don't understand why cURL option appears to have it normal again but I am extremely grateful for for your help.

For my homework, I'll go back over the posts to try and understand the detail :0

Thanks again

cheers

Gene

Peter Homann:

My guess is that it is sending a weight of 0 that causes the problem. Is it possible to add a line into the php that checks for this and if so sets the weight to a minimum value?

Cheers,

Peter.

If you enable the debug option you'll note that no parcel will ever be quoted with a value of '0'. This will cause problems, so any zero weight items get assigned a value of 1gm.

I suspect that the problem many of you are experiencing with the new module is due to a small change of the logic between the old AustPost Module and the current ozpost module.

With the old module/server, any small (letter size & weight) items would always return a quote from the server, this would include both letter rates and parcel rates (for the same item). If the letter rates were disabled, then only the parcel rates were shown, else both rates were shown. It did this by forcing a minimum size/weight before seeking a quote for the smallest parcel allowable (after the letter rate quote had been obtained).

With the new module, this isn't the default case, if the item/parcel is letter sized then ONLY the letter rates will be returned, and if letters are disabled there will be no quote to provide (not an error) and therefore no quote given at all.

**To emulate the same functionality as the old module you'll need to untick the 'hide parcel rates if letter sized'. ** This will then allow letters to be quoted as parcels. The main reason for making this change (and setting it this way by default) is to improve response times and minimise server load. It is silly having the server provide parcel rate quotes for anything letter sized, unless the client specifically requires this behaviour.

Besides, if the item/parcel in the cart is small enough to be classed as a letter the why not allow letters as a valid shipping method? Your customers will be much happier for it.

For this to all work correctly though valid weights and dimensions are required for all products being sold. It is no good having a large/heavy physical item and letting the module think that it only weighs 1gm (which will occur if given a weight of zero) and has no dimensions. I suspect this scenario is probably the reason why many have disabled letters as a valid shipping method in the first place.

I'm pretty sure that disabling the 'hide parcel rate' option will solve many of the weight problems that people are having.

If this is needed though it what it really means is that
either you are overcharging your customers for postage (charging parcel rates for letter sized items), OR that the weight/dimensions for your products are inaccurate, in which case any quotes given cannot be trusted for accuracy and **you'll almost certainly end up underquoting **for many of your parcels.

Cheers
Rod

Hi Rod

That works up to a point. The shipping costs are now being returned.

However, for my client, a single item purchase may require bubble wrap so won't fit in a letter size. A multiple item purchase would probably go with the cubing algorithm that says it has to fit in a parcel anyway. So, dimensions of the product are correct if you're trying to buy multiple items but don't allow for packaging with single items. The bottom line for this client I've got is that they need to force people into at least the regular parcel as experience shows they can't use letter sizes.

Can you point me in the right direction to the code so that I can hard code an if statement so that letters get ignored..?

Thanks for your help and quick response.

Cheers
Andy

p1drobert:

Hi rod,
thanks for the reply. I realize the pressure you're under. I do custom electronics design myself.

Please accept my apologies for letting it show.

p1drobert:

These same weights seem to work fine with the old AUSTPOST module. The old AUSTpost module was great and I miss it.

I'm sure in time you'll come to love the new module too. Although on the surface there may not be any significant advantages or improvements, the new code is a lot more versatile and easier to maintain.... it'll almost certainly work with the yet to be released zen-cart V2 (perhaps minimal changes), and it is far more easily expandable in that new shipping methods can be easily added... eg, quotes from couriers, etc.

p1drobert:

I fail to see how adding one of these items creates an error but adding 5 does not if its not a bug, Any other heavier product does fine too so I'm not sure what you mean "not a bug".

OK, try this, phone your local post office and ask them to give you a quote to post an item weighing 1gm with the dimensions 1mm x 1mm x 1mm, and insist you want it sent by parcel, without changing the dimensions. They'll tell you it can't be done, and that you'll need to place the item into a larger package before they'll even consider accepting it. They'll also probably suggest you just place the item in an envelope and send it as a letter (after all, why would you want to put such a small item into a large box to force it to be sent as a parcel)?

This is essentially what the ozpost module is telling you to do as well.

It isn't a bug, because it is performing according to real world requirements.

Technically speaking, it is the old AustPost module that has the bug because it was forcing a quote where no valid quote could really be given.

p1drobert:

By this I take it you mean set the USE CURL question to YES.
Yes have done this but still get a blank page. Is there another setting on my host server that I need to activate as well?

This is a maybe. IF you are getting a blank page because your data and shipping methods cannot provide a legitimate/valid quote you'll need to alter your settings to emulate the old behaviour (untick the 'hide letter rates if parcel sized), or, you can enable letters as a valid shipping method, or you can provide accurate weights and dimensions to your products and obtain accurate quotes.

However, if you are getting the blank page because the server can't be contacted (possibly because your ISP doesn't have cURL installed (unlikely) , or that they use a proxy server for cURL requests (possible), then you'll need to need to define your proxy settings located under the zencart configuration/myStore settings.

p1drobert:

As I said, I liked your old module so much that I saw no reason to shift to the new one.

Even though it has been giving invalid quotes for the last few months? (Surprised you hadn't noticed).

p1drobert:

Human nature being what it is, any one that tried the new module and found it not to work would probably just go back to the old one and not worry about it.

I accept that most people don't like change, and that many are what I can only consider either lazy or selfish by not reporting the problem(s) when they discovered it, but there is only so much that I can do alone. This wasn't a planned change, I had no more warning than anyone else, so I'm doing my best to not feel personally guilty about the current scenario... the guilt needs to be shared :-)

p1drobert:

I've noted this odd occurrence. If icons are enabled the icon next to the ozpost module in the shipping page is missing. The properties show

myurl/catalog/admin/DIR_WS_TEMPLATEStemplate_default/images/icons/ozpost_logo.jpg

This is clearly wrong.

Yes it is, and in fact is one of the more recent bugs that has been taken care of (it only seems to affect some people/servers, most notibibly those stores hosted on Windows based servers). This is a 'cosmetic' issue only and has no effect on functionality.

You can resolve this particular issue by downloading
http://www.zen-cart.com/forum/attachment.php?attachmentid=6437&d=1252290889

Hope this helps.

Cheers
Rod

ionebusiness:

The bottom line for this client I've got is that they need to force people into at least the regular parcel as experience shows they can't use letter sizes.

Can you point me in the right direction to the code so that I can hard code an if statement so that letters get ignored..?

Thanks for your help and quick response.

Cheers
Andy

To ignore letters, simply don't enable them as a method.
By default this will produce no quote at all for letter sized items.

To force a parcel rate quote on these items untick the 'hide parcel rate if letter sized' option, and the items will be quoted at the minimum parcel rate/size allowable. Be warned, that in this scenario, your bubble wrapped item could actually be larger than the minimum size required so you'll run the risk of underquoting.

I would suggest a better option would be to enter the size and dimensions of the items as though they were already bubble wrapped. Sure this will give a compounding problem if more than one item is added to the cart (and only a single bubble wrap is needed), but at least the error will be in favour of the merchant (who can offer a rebate if the postage costs blows out too high as a result). This is far easier to do and gives better goodwill than underquoting and then trying to recover (or wearing) the difference.

Cheers
Rod

Thanks Rod. Worked a treat. Unfortunately, I can't see my client going through all their items and changing the dimensions to include bubble wrap as they've been happy with the old AustPost - Improved quotes up until now. Anyway, they're getting the results they want now so all sorted.

Please accept my apologies for letting it show.

Dude, don't apologize. You're doing this for free. I'm amazed at your efforts as it is.

This is a maybe. IF you are getting a blank page because your data and shipping methods cannot provide a legitimate/valid quote you'll need to alter your settings to emulate the old behaviour (untick the 'hide letter rates if parcel sized), or, you can enable letters as a valid shipping method, or you can provide accurate weights and dimensions to your products and obtain accurate quotes.

However, if you are getting the blank page because the server can't be contacted (possibly because your ISP doesn't have cURL installed (unlikely) , or that they use a proxy server for cURL requests (possible), then you'll need to need to define your proxy settings located under the zencart configuration/myStore settings.

Sadly the hide letter rates were already set to NO. My server curl info is shown below.
cURL support enabled
cURL Information libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8 libssh2/0.18

Still a blank page.
I don't think its a curl issue. Or an issue with sizes and weights as the estimate shipping page works every time. How is the estimate shipping page different from the proceed through to checkout page?

This is what I know so far. That the estimate shipping page works every time. That sometimes when I do a refresh of the blank page the actual shipping information comes through. Or ar least some of the rates comes through as I noticed one time that the ECI costings were missing.

That if I run the same module with the same settings from my zencart 1.3.7 installation (which I no longer use) that it works every time. I'm currently using the 1.3.8 zencart version.

I had trouble first setting up my 1.3.8 installation as my host uses shared sessions. I had do set up a special session path in my configuration.php files to get 1.3.8 to install properly. I'm wondering if thats significant.

Enabling the debug mode returns information indicating that the mail server responded ok, with no errors apparent.

I'm wondering if this has anything to do with my Shared SSL certificate as the url on the blank page seems to access the secure page address. My 1.3.7 version zencart doesn't have SSL enabled.

p1drobert:

This is what I know so far. That the estimate shipping page works every time.

Well, that's 95% of the possibilties eliminated.

p1drobert:

That sometimes when I do a refresh of the blank page the actual shipping information comes through. Or ar least some of the rates comes through as I noticed one time that the ECI costings were missing.

The 'sometimes' type problems are always the most difficult to solve.
At the moment I'll put this down as an item of curiosity, especially when there is clearly something 'permanently' amiss.

p1drobert:

That if I run the same module with the same settings from my zencart 1.3.7 installation (which I no longer use) that it works every time. I'm currently using the 1.3.8 zencart version.

I didn't think much of this observation the forst time you mentioned it, but it has turned out to be an important clue ... in fact it actually validates what I believe the problem is.

p1drobert:

I had trouble first setting up my 1.3.8 installation as my host uses shared sessions. I had do set up a special session path in my configuration.php files to get 1.3.8 to install properly. I'm wondering if thats significant.

YES. You've actually managed to isolate the problem... I will lay 100/1 odds on this...

p1drobert:

I'm wondering if this has anything to do with my Shared SSL certificate as the url on the blank page seems to access the secure page address. My 1.3.7 version zencart doesn't have SSL enabled.

There may be a link/connection between this and the session data, and you can possibly prove the point by temporally disabling SSL.

The actual cause of the problem though IS the session data, almost 100% guaranteed.

Here's the deal....

The old AustPost module, as well as having to contact 2 different servers to obtain a full set of quotes, it also made another contact to the servers during the checkout to obtain just the quote that had been selected.

The ozpost module avoids the need to contact the server during checkout by caching the result of the full set of quotes and then retrieving the single/required quote from the session data.

If your session data isn't being stored/retreived properly there isn't going to be a 'method' (or quote) availalbe to use during the checkout.
This is entirely unexpected of course, so the page is just bombing out.

OK, so that is the cause.... The big issue now is how to fix it?

As suggested above, disabling SSL may effect a cure of sorts in that session data for an http:// page isn't likely to be the same session data as for a https:// page - at least not by default.

You will probably need to set up a special session path as you did in order to get it to install properly.

Cheers
Rod.

Hi Rod,

Thanks for your time.

RodG:

There may be a link/connection between this and the session data, and you can possibly prove the point by temporally disabling SSL.

The actual cause of the problem though IS the session data, almost 100% guaranteed.

Yes, disabling SSL allows the shipping information to be displayed. Unfortunately the payments refuse to process. I'm using direct credit card processing on my web site via Eway. It requires SSL to be enabled or it just doesn't work.

Here's the deal....

The old AustPost module, as well as having to contact 2 different servers to obtain a full set of quotes, it also made another contact to the servers during the checkout to obtain just the quote that had been selected.

The ozpost module avoids the need to contact the server during checkout by caching the result of the full set of quotes and then retrieving the single/required quote from the session data.

If your session data isn't being stored/retreived properly there isn't going to be a 'method' (or quote) availalbe to use during the checkout.
This is entirely unexpected of course, so the page is just bombing out.

Is it possible to add a bypass in the ozpost module that forces two separate quotes to be made as occurred in the AUSTPOST module. Bypass the save to session info.

You will probably need to set up a special session path as you did in order to get it to install properly.

I'm not sure where to add this session path. My shopfront is using Database stored sessions. Shouldn't the shipping information be stored in the database? When I first had trouble installing zencart 1.3.8 I added the session path to the specific installation files. I'm not clear as to where to add the required path lines in this case.

p1drobert:

Is it possible to add a bypass in the ozpost module that forces two separate quotes to be made as occurred in the AUSTPOST module. Bypass the save to session info.

It is code, so yes of course it is possible.

If you really meant to say is it possible for me to do this for you I'd have to say I wouldn't even consider wasting time even looking at it.

When I do get time I'll certainly take a look to see if I can resolve the issue that you are having with your session data, because this will almost certainly take less time that what you are proposing.

p1drobert:

I'm not sure where to add this session path.

That makes two of us, but without doing any research at all, I would imagine that ozpost.php would be the obvious place to start because that is where you are having the problem.

p1drobert:

My shopfront is using Database stored sessions. Shouldn't the shipping information be stored in the database?

In a perfect world I guess it should be, but this isn't a perfect world and I'm an inherently lazy person, so rather than study how zencart itself handles session data I simply chose to use the garden variety session commands that are part of the PHP command syntax.

p1drobert:

When I first had trouble installing zencart 1.3.8 I added the session path to the specific installation files. I'm not clear as to where to add the required path lines in this case.

/includes/modules/shipping/ozpost.php

Perhaps a google search for setting session paths with php is and a little experimentation is in order?

it probably just needs something real simple such as
php_session_path = "/path_to_session_directory"

I suggest you NOT copy and paste that.. I'm simply guessing what the command could be.

As I said, I'll be happy to look into this one at a later date, but now is not the time.

Cheers
Rod