ozpost shipping module

[Arliss61]

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

[RodG]

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

[ionebusiness]

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

[RodG]

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.

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.

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.

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.

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).

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 :-)

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/attach...7&d=1252290889

Hope this helps.

Cheers
Rod

[RodG]

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

[ionebusiness]

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.

[p1drobert]

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.

[RodG]

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

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

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.

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.

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...

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.

[p1drobert]

Hi Rod,

Thanks for your time.

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.

[RodG]

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.

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.

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.

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