ozpost shipping module

Cheers Rod, I'll see how that goes..

Thanks,
Mike

gee38l:

Hi Rod,

Just wondering if this module is compatible with fast and easy checkout (FEC)?

I don't know if FEC is compatible with this module or not.

gee38l:

Also if i was using the Aus Post improve module is it just a matter of overwriting the existing files with the new ones?

Aus Post improved hasn't worked properly for almost a year.

ozpost is a completely different module so no overwriting the existing files will take place. If you just upload/install the ozpost module you'll end up with two modules, austPost and ozpost. There is no need to remove/disable the unused module, but it is strongly recommended so as to avoid any possible confusion.

Cheers
Rod

Mike_Dean:

Cheers Rod, I'll see how that goes..

Thanks,
Mike

Worked a treat, inserted straight after // store it //.

Now, how do I remove the words "Australia Post," as well.

I tried using the same formula, but using "Australia Post'" instead, but it did not work.

The reason I want to remove it, is that we don't always use Aust Post, but we do use the prices it quotes. So I don't want people automatically assuming it is Aust Post that will deliver.

Mike_Dean:

Now, how do I remove the words "Australia Post," as well.

I tried using the same formula, but using "Australia Post'" instead, but it did not work.

The reason I want to remove it, is that we don't always use Aust Post, but we do use the prices it quotes. So I don't want people automatically assuming it is Aust Post that will deliver.

The 'dirty' way to to this would be to add a line reading:
$carrier = "" ;
This will need to be added just before/after the other line of code you added.

A simpler/better way would be to modify the /languages/modules/shipping/ozpost.php file and redefine he carrier name to your choosing (including '' )

The $carrier variable and the various 'defines' were introduced along with the TNT and Fastway functionality.

Cheers
Rod

Hi Rod,

I'm still getting errors with shipping calculation. Not sure if there has been an update to fix yet.

If a customer orders too many of a particular item/s then it will get to a point where ozpost can't calculate the shipping cost and give the Error and AP flat rate.

"ERROR: (18+53.00) x 2cm exceeds the Maximum 140cm girth allowed. Using AP Flat Rate." etc..

I've noticed on ebay, I believe its using the Auspost rates to calculate shipping automatically if wieght, size/dimensions have been entered for each product. The shipping calculates the same costs as ozpost, but doesn't give an error when more products (qty) are added.

Any update on this?

Michael

giftpackaging:

Hi Rod,

I'm still getting errors with shipping calculation. Not sure if there has been an update to fix yet.

As far as I'm aware, your problem was solved months ago. The last posting from you stated "If I choose items/qtys so that it does not exceed the restrictions, everything works perfectly".

giftpackaging:

If a customer orders too many of a particular item/s then it will get to a point where ozpost can't calculate the shipping cost and give the Error and AP flat rate.

Yes, that is what it is supposed to do. The only other options are to return no quote at all, or a quote on a parcel that is too large for Australia post to accept anyway.

What do you think the module should do? Compress the parcel so that it will fit the allowed dimensions? Split the parcel into multiple parcels even though this may be physically impossible to do without damaging the goods?

A better method of 'packing and stacking' would alleviate the problem somewhat, but having already attempted several different methods, each which introduced their own problems I agree with many others in that this is the 'holy grail' of shipping modules no matter what ecommerce software is being used.. Besides, even with a perfect packing and stacking code, sooner or later the parcel is going to reach limits that will require you to use a different shipping method.

giftpackaging:

"ERROR: (18+53.00) x 2cm exceeds the Maximum 140cm girth allowed. Using AP Flat Rate." etc..

This is more a statement of fact rather than an error. It really doesn't matter what I do with the code, (18+53.00) x 2cm is always going to exceed the Maximum 140cm girth allowed by AustPost.

giftpackaging:

I've noticed on ebay, I believe its using the Auspost rates to calculate shipping automatically if wieght, size/dimensions have been entered for each product. The shipping calculates the same costs as ozpost, but doesn't give an error when more products (qty) are added.

If you can provide a URL I'd be happy to take a look at what is being used, and how they perform this feat, but my gut feeling tells me that it will only be quoting on weight alone.

giftpackaging:

Any update on this?
Michael

It is a trivial task to have the module ignore any size errors, simply by ignoring the calculated parcel size and substituting fixed dimensions instead. It may come as a bit of a shock when you actually go to post the parcel though.

Although I've no 'real world' data to back myself up, my hunch is that this problem will occur far more due to mulitple quantities of a single item being added to the cart than it would with single quantities of multiple items being added, and this being the case, and it is a serious issue, then the solution is to use 'bulk packing' for the items in question. By this I mean create a cart item for a box of (say) 10 somethings, and then enter the actual dimensions of these 10 items packed together so that when people buy the 10 pack the module will only see this as a single item and it won't need to use the very simple stacking code. In other words, you literally need to pre-pack the items where you are likely to get sales of multiple quantities.

As before, this will only really help minimise the error, because sooner or later we just have to obey the laws of physics. :D

Cheers
Rod

Hi Rod

I tried to load 2.0.5 onto 139c localhost but it would not install.

All I got was this error message

Network Connectivity test FAILED
Is cURL installed on your server? (it needs to be). If so, this may be a temporary glitch, try again in a few minutes.
Installation will NOT continue.

I have curl enabled in php5.2.9, but also tried it unenabled.

I tried switching lines 70-71 of \includes\modules\shipping\ozpost.php ie

$this->SERVER = 'ozpost.vcsweb.com';
// $this->SERVER = 'http://localhost/zencart/' ;

but to no avail. Are there other switches?

In doing the upgrade, however, I did note that one of your files was based on a 139b version.

dw08gm:

Network Connectivity test FAILED
Is cURL installed on your server? (it needs to be). If so, this may be a temporary glitch, try again in a few minutes.
Installation will NOT continue.

I have curl enabled in php5.2.9, but also tried it unenabled.

There is no way that it will work without cURL.

dw08gm:

I tried switching lines 70-71 of \includes\modules\shipping\ozpost.php ie
$this->SERVER = 'ozpost.vcsweb.com';
// $this->SERVER = 'http://localhost/zencart/' ;
but to no avail.

No reason to expect that to work either, unless you happen to be running a quotation server on your own machine :-)

dw08gm:

Are there other switches?

No.

dw08gm:

In doing the upgrade, however, I did note that one of your files was based on a 139b version.

Firstly, I have no idea if you are referring to an upgrade of the ozpost module, or if you are referring to an upgrade of zencart to 1.3.9b. Perhaps both.
Either way, I must ask the question, was your previous install of ozpost working correctly, and if so, what version was it.

As for "I did note that one of your files was based on a 139b version" this isn't quite true, it (actually, "they" as there are three of them) are based on a much older 1.3.7 or 1.3.8 version of zencart.
The purpose of them is clearly detailed within the .txt files that are supplied with all ozpost distribution packages.

Anyway, as for solving your problem, the error message is clearly indicating that there is (or was) a problem connecting to the server. A problem with cURL is just one of the possible causes of this problem. Other possible problems include temporary failure of the server, a firewall issue (client or server end), a routing/networking issue. a problem with the nameservers, and so forth.

The first thing you need to do though is ensure that cURL really is availalble and working. zencart has a program for this in the 'extras' folder.

After confirming that cURL is ok you/we will need to start to investigate why it can't (apparently) connect to the ozpost server. Depending on your skills/knowledge you may need to involve your webhost with this, however it is possible that there is a bug/flaw in the code that does the checking, so I propose this may be the easiest next step..

To do this, load /modules/shipping/ozpost.php into a text editor, then comment out (or delete) lines 525 - 532 and resave the file. Please report your results.

Cheers
Rod

Hi Rod,

I'm not suggesting parcels are to be compressed to fit the dimensions of auspost requirements. But I know if you walk into a auspost outlet, with 10 items, they aren't going to give you an error and say they can't post them because the sum of the parcels is too large.

I really think your module works perfectly except for when customers either purchase an item which is too large or add too many items to the cart that then eventually exceeds the 'requirement'.

I have just put tissue reams on ebay and used the estimate postage costs. I put in dimensions and weight of 1 ream, allowed regular and registered postage options.

http://cgi.ebay.com.au/ws/eBayISAPI.dll?ViewItem&rd=1&item=130390584392

Click on the postage tab, and you can enter a postcode and change qty amount. On our website, it will give an error once you go over 4 reams.

giftpackaging:

Hi Rod,

I'm not suggesting parcels are to be compressed to fit the dimensions of auspost requirements. But I know if you walk into a auspost outlet, with 10 items, they aren't going to give you an error and say they can't post them because the sum of the parcels is too large.

This is true only if you make the each of the parcels small enough for them to accept. In some cases this may not be possible, ie, where a single item will exceed the allowed dimensions.

giftpackaging:

I really think your module works perfectly except for when customers either purchase an item which is too large or add too many items to the cart that then eventually exceeds the 'requirement'.

This, in itself isn't a shortcoming of the module. It is still a matter of physics.
X number of Y products is eventually going to exceed any allowable size (or weight) limitation.

giftpackaging:

I have just put tissue reams on ebay and used the estimate postage costs. I put in dimensions and weight of 1 ream, allowed regular and registered postage options.

http://cgi.ebay.com.au/ws/eBayISAPI.dll?ViewItem&rd=1&item=130390584392

Alas, I am unable to tell from this link exactly what it is that is being sent to the quotation servers. I am still of the strong opinion that the dimensions are being ignored.

giftpackaging:

Click on the postage tab, and you can enter a postcode and change qty amount. On our website, it will give an error once you go over 4 reams.

I understand what you are saying, but it really doesn't change anything. All this means is that unless they are using code that is too complex for me to understand (possible) the quotes that they are providing under such conditions are probably inaccurate in that it obtains a quote for a single item and multiplies it by the number of items purchased (thus over quoting when multiple items can be placed into a single package, OR it may possibly work similar to the default zencart code whereby the dimensions are non-existent/unused and the weights are simply added together and if the resulting parcel weight over the 20kg limit the purchase gets split into multiple parcels and quoted accordingly ... eg, 60kg of 'product' will be quoted at 3x 20kg parcels.

On the surface this appears to be a good working solution, until you get into the following situations (examples only).

3 items weighing 13kg each will create a 39kg parcel, which will be 'split' at the maximum weight setting (20kg) producing a quote for TWO parcels weighing 19.5kg each.
Unless one of the items itself can be cut in half (without damage) you will not be able to create the two parcels being quoted - you'd need to pack them into 3 parcels @ 13kg each - and I can assure you that the cost of 3 parcels @ 13kg each isn't going to cost the same as two parcels @19.5kg each. The postal charges simply aren't that linear.

Another example:
Suppose you have two items in your store, one weighing 19.7kg, the other weighing 400gm, and a person orders both. The total weight of both items exceeds the 20kg limit - If we split by weight we'll be quoted for 2x 10.05kg parcels. Clearly the 'best' way to ship these items would be 1x 19.7kg parcel and perhaps a 500gm prepaid satchel for the other. The shipping costs between the two methods is going to be significantly different (and it may not be possible to cut the 19.7kg item in half).

The same problem occurs when attempting to divide/split the parcels by size. There is no way of knowing if any given item can be physically 'split' or not, and this one is even harder to overcome than splitting by weight.

These are just very simple examples - The more items that get added to the cart (especially if the items are all different weights and sizes) the more complex this all becomes).

Bottom line is that although it is easily possible to prevent both weight and dimension errors by attempting to split parcels into allowable sizes, the quotes returned cannot be accurate unless the items themselves can actually be split in the same manner as the underlying code suggests they could.

I have spent literally months trying to find a practical solution to this dilemma, and there really doesn't seem to be one (which is why it is still known as a holy grail), so the options are 1) to report an error when limits are exceeded, or 2). Circumvent the limits (by dividing parcels in somewhat arbitary ways that may not even be possible) and then returning quotes that cannot be possibly be accurate.

I'd rather have ozpost produce error messages and accurate quotes rather than have it quote for parcels that may not be be possible in a real world situation or quotes that may be a long way from being even close to the real costs.

Hopefully this clarifies the situation a little better for you.

Cheers
Rod

RodG:

To do this, load /modules/shipping/ozpost.php into a text editor, then comment out (or delete) lines 525 - 532 and resave the file. Please report your results.
Cheers
Rod

Hi Rod

Before committing to your response, I rechecked all of the 2.05 file edits. The file that I said was a 139b version should have read 139c, and was
admin/includes/modules/product/collect_info.php. However, I doubt this edit is material, as the only difference concerns $oFCKeditor->Value =...

Upon remming lines 525 - 532 of includes/modules/shipping/ozpost.php, all except the following shipping modules in Admin > Modules > Shipping disappeared,
Flat Rate
Free Shipping Options
FREE SHIPPING!
Per Item

Returning to Admin > Home, unremming lines 525 - 532, and then returning to Admin > Modules > Shipping, resulted only with
Flat Rate

But upon returning again to Admin > Home, and then to Admin > Modules > Shipping, all shipping modules re-appeared. There is now a green light against the OZpost module and an error message at top of screen:
Error cURL communication ERROR: Could not resolve host: ozpost.vcsweb.com; No data record of requested type
Error Unable to connect to Ozpost server

Upon clicking OZpost to select for install, the screen gyrated for about 10 seconds, and then the list of OZpost Multiquote options appears in column right below Remove/Edit buttons.

Upon clicking Remove, the Install button reappears in column right, and then clicking Install, I get the white screen with error message
Network Connectivity test FAILED
Is cURL installed on your server? (it needs to be). If so, this may be a temporary glitch, try again in a few minutes.
Installation will NOT continue.

In between this remming, I got three of the following myDEBUGs:

PHP Parse error: parse error, expecting `T_FUNCTION' in ...\includes\modules\shipping\ozpost.php on line 742

Upon uninstalling 2.05 and reinstalling 1.02, just by replacing the two ozpost.php files, I get no curl errors and 1.02 loads.

Upon uninstalling 1.02 and reinstalling 2.05, just by replacing the two ozpost.php files, I get the curl errors and 2.05 fails to load.

Upon running http://localhost/MYSTORE/extras/curltester.php (after reinstalling 1.02), I got this result

Array
(
[url] => "http://www.zen-cart.com/testcurl.php"
[content_type] =>
[http_code] => 0
[header_size] => 0
[request_size] => 0
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 0
[namelookup_time] => 0
[connect_time] => 0
[pretransfer_time] => 0
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => 0
[upload_content_length] => 0
[starttransfer_time] => 0
[redirect_time] => 0
)

I gather this result is correct when running on localhost. For comparison sake, could someone please provide live test result.

ps
This week may be remembered as the week of the long posts.

Interminable troubles of infinitesimal trickiness - how I love and hate IT.

dw08gm:

There is now a green light against the OZpost module and an error message at top of screen:
Error cURL communication ERROR: Could not resolve host: ozpost.vcsweb.com;

This is the 'guts' of your problem.

As for the errors you were getting when remming the code, it is quite possible that I got the line numbers wrong by looking at slightly different code than you have, so I wouldn'd worry about them.

dw08gm:

No data record of requested type
Error Unable to connect to Ozpost server

These errors are both effects stemming from the "Could not resolve host" error.

dw08gm:

Upon running http://localhost/MYSTORE/extras/curltester.php (after reinstalling 1.02), I got this result

Array
(
[url] => "http://www.zen-cart.com/testcurl.php"
[content_type] =>
[http_code] => 0
[header_size] => 0
[request_size] => 0
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 0
[namelookup_time] => 0
[connect_time] => 0
[pretransfer_time] => 0
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => 0
[upload_content_length] => 0
[starttransfer_time] => 0
[redirect_time] => 0
)

I gather this result is correct when running on localhost.
.

Sadly, no. That is NOT a good result.

dw08gm:

For comparison sake, could someone please provide live test result.

Here's my result (also running from localhost)

CURL Test Page

This page is intended for testing CURL behaviour. You should be accessing this page via CURLTESTER.PHP running on YOUR server.

You submitted the following fields and data:

Array
(
[field1] => This is a test
[statuskey] => ready
)
Data validation

Good Other Info

Your server IP address is: xxx.xxx.xxx.xxx.
Your system identifies itself as: Zen Cart(tm) - CURL TEST

Array
(
[url] => "http://www.zen-cart.com/testcurl.php"
[content_type] => text/html
[http_code] => 200
[header_size] => 275
[request_size] => 212
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 1.024883
[namelookup_time] => 0.497785
[connect_time] => 0.757249
[pretransfer_time] => 0.757299
[size_upload] => 0
[size_download] => 2181
[speed_download] => 2128
[speed_upload] => 0
[download_content_length] => 2181
[upload_content_length] => 0
[starttransfer_time] => 1.023789
[redirect_time] => 0
)

As you can see, a very different result.

Anyway, from the only significant error message provided, it appears that there may be a problem with the DNS rather than cURL - So unless you know about such things your best option is to take it up with your webhost.

Cheers
Rod

Hi Rod

I see the light now thanks. Upon connecting my localhost to the internet, I got the following curltest result. So my CURL was enabled (via php.ini) but did not work because localhost was not connected to the internet.

CURL Test Page
This page is intended for testing CURL behaviour. You should be accessing this page via CURLTESTER.PHP running on YOUR server.

You submitted the following fields and data:

Array
(
[field1] => This is a test
[statuskey] => ready
)

Data validation
Good
Other Info
Your server IP address is: xxx.xxx.xxx.xx.
Your system identifies itself as: Zen Cart(tm) - CURL TEST
Copyright © 2003 - 2010 Zen Ventures, LLC - Powered by Zen Cart™

Array
(
[url] => "http://www.zen-cart.com/testcurl.php"
[content_type] => text/html
[http_code] => 200
[header_size] => 275
[request_size] => 212
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 1.36
[namelookup_time] => 0.156
[connect_time] => 0.531
[pretransfer_time] => 0.531
[size_upload] => 0
[size_download] => 2183
[speed_download] => 1605
[speed_upload] => 0
[download_content_length] => 2183
[upload_content_length] => 0
[starttransfer_time] => 1.36
[redirect_time] => 0
)

However, whereas OZpost1.02 only required CURL to be enabled (via php.ini but with Use cURL? No), to install OZpost2.05 on localhost requires CURL to be enabled AND a live connection to the internet. I hazzard this should have been the point of my initial post on this matter.

Perhaps an explicit note to this affect in your install documents (which I wish were all combined into one txt file) would be useful for newcomers, even seasoned novices like myself.

Hi Rod

Just wondering if you can help me. I have ozpost installed and i have set the error amount up but when a customer orders alot and it goes back to my error amount the customer can't use it. It wont let them past step 2 in the check out and when it does it brings up a error screen saying the webpage format is not supported do you know what this could be.

Thanks

dw08gm:

I see the light now thanks. Upon connecting my localhost to the internet, I got the following curltest result. So my CURL was enabled (via php.ini) but did not work because localhost was not connected to the internet.

I guess that explains things.

Mind you, the cURL test program, and indeed, the ozpost module itself are only really designed to work with internet connected computers and running the curltest program on local host doesn't help solve server related issues anyway.

dw08gm:

to install OZpost2.05 on localhost requires CURL to be enabled AND a live connection to the internet. I hazzard this should have been the point of my initial post on this matter.

Perhaps an explicit note to this affect in your install documents

I'll put this way up there with a warning notice that says "Hot surface, do not touch".

No offense intended, but I do expect zencart users to have a little bit of common sense, and if an error message along the lines of "unable to connect to server" doesn't imply that an internet connection is needed then perhaps the person shouldn't be running an online store in the first place.

dw08gm:

(which I wish were all combined into one txt file)

Not everyone will want, or need, to read all of the text files supplied. By combining them all into a single document will create a document that I beleive will be scare many people away from even attempting a self-install.

dw08gm:

would be useful for newcomers, even seasoned novices like myself.

As indicated above, I believe that newcomers should at least have some prior experience with the Internet and website management/maintanance prior to embarking on something as powerful and flexible as zencart and its associated modules. It really isn't my position to 'teach' people that 'unable to connect to server' could mean something as simple as their modem not being plugged in, to something more complex such as cURL not being installed, or a firewall issue, etc, etc... .

As for "seasoned novices like yoursself" - In light of this discussion I would be categorising you as a complete novice due to your inabilty to realise that a localhost needs to be connected to the internet in order to access an internet server.

That said, you DID eventually realise this, as will all 'newcomers'. some will take a little longer than others, but once again this is basic computing 101 - the ozpost module documentation isn't really the place for such lessons.

Cheers
Rod

Hi Rod,

Just a piece of assistance if you wouldn't mind.

I want to remove the bracketed delivery method that appears at step 2 of the checkout process., such as

Delivery (3Kg Prepaid Satchel) and replace it with

Delivery - Prepaid Satchel. (ie remove the brackets and the reference to the 3Kg)

Thanks,
Mike

uniqueliving:

Hi Rod

Just wondering if you can help me. I have ozpost installed and i have set the error amount up but when a customer orders alot and it goes back to my error amount the customer can't use it. It wont let them past step 2 in the check out and when it does it brings up a error screen saying the webpage format is not supported do you know what this could be.

Thanks
I'll need to check/verify this somehow.

If I don't get back to you in a day or 2 please send me a reminder :-)

Cheers
Rod

Mike_Dean:

Hi Rod,

Just a piece of assistance if you wouldn't mind.

I want to remove the bracketed delivery method that appears at step 2 of the checkout process., such as

Delivery (3Kg Prepaid Satchel) and replace it with

Delivery - Prepaid Satchel. (ie remove the brackets and the reference to the 3Kg)

Thanks,
Mike

Removing the "3kg" reference can be achieved in a similar manner that has previously been discussed.

Removing the brackets is something I can't really help with. They are not added by the ozpost module, but rather by the checkout page(s) themselves, so that is where you'll need to be looking.

Cheers
Rod

RodG:

I'll need to check/verify this somehow.

If I don't get back to you in a day or 2 please send me a reminder :-)

Cheers
Rod

Thanks for your help Rod Much appreciated. :D

RodG:

Removing the "3kg" reference can be achieved in a similar manner that has previously been discussed.

Removing the brackets is something I can't really help with. They are not added by the ozpost module, but rather by the checkout page(s) themselves, so that is where you'll need to be looking.

Cheers
Rod

Thanks Rod,

I manged to get rid of the brackets... :clap:

but the other part has got me stumped.. :censored:

The earlier efforts removed the 3Kg from the shipping estimator, but I cant seem to fathom where, and in what file to edit to remove the reference from the checkout process pages.