ozpost shipping module

RodG:

1. This is the most likely... your server isn't using php5 (I still need to put this requirement in the docs).

Most ISP's and servers offer php5 these days, although many leave it for the user to choose whether they want php4 or php5.

Cheers
Rod

Sorry for hashing up such an old post, but I think I've read every post in this thread 5 times or more and I'm still coming out empty handed! It would seem that this quote may also be a big part of my problem though (I posted on another thread about this not long ago, also. However I think this may be more relevant).

Now.... you're all probably going to roll your eyes when I ask this incredibly n00b question, but I really have no other option! How exactly do you change to php5 (in the most simple terms you can manage please! lol)? My actual domain is running on php5 FastCGI, which had me running in circles for a bit - but upon looking at my actual zencart version etc, I'm being told that the zencart is running on php 4.4.9 :shocking: And that's as far as I've got!

Any help would be greatly appreciated :blush:

Danika.

Oh!!! I have solved it!! I knew sheer stubborness to give up would pay off eventually :blink:

If anyone else is reading through this thread with the same horrified, yet slightly blank expression on their face, fear not! I won't make you ask the dumb questions like I just did.

It was something so simple... as I said above, my server was running on "php5 fastCGI" and all I had to do was change it to "php5 CGI". Now my zencart is running on php5.2.9 (as opposed to php 4.4.9) and my ozcart is running like a dream!

PHEW!

Now....time to hit the hay. Hours of scouring the net has done my head in!

Hi Rod,

I hope the air condition works or that you got a pool down there :-)
Anyway have installed the new ozpost version on a site on my server and it drives me nuts :-)

You can see it here: http://www.saxophonestraps.com

Now I am using the Austpost__improved_2-1-3 on a number of sites on the same server without any problems at all. I thought for this site to use the updated version but it just not working.

The problem is that when using Firefox I can go the first time and on the estimator I am just getting the Close Window without any content or no rates. Then I can close the window and go back again and works halfway but no rates and then i can go back again and then it works.

If I go with IE then it starts loading the window and just as it is about to show the drop down menu for countries and the postcode boxes it does a refresh or something and then nothing.

Any ideas please?

Tassos

hrinfo:

Now I am using the Austpost__improved_2-1-3 on a number of sites on the same server without any problems at all.

Hmmm, the Austpost - Improved module is obsolete. It hasn't worked for months due to a (forced) change of servers.

hrinfo:

I thought for this site to use the updated version but it just not working.

This is qhat you should be using.
http://www.zen-cart.com/index.php?main_page=product_contrib_info&cPath=40_51&products_id=1286

hrinfo:

The problem is that when using Firefox I can go the first time and on the estimator I am just getting the Close Window without any content or no rates. Then I can close the window and go back again and works halfway but no rates and then i can go back again and then it works.

Assuming that you are using the 'ozpost' module as per the link above, try enabling the 'use cURL' option. This has taken care of this problem for most people.

Also, ensure that you are using PHP 5.1 or 5.2.
PHP4 isn't supported with this module (A lack of feedback in the early stages of development allowed this shortcoming to slip by unnoticed)
PHP 5.3 has other issues (there is a separate zencart thread about this).

Anyway, if you meet the requirements of 'Use cURL' and php5, and you STILL have problems please get back to me, because there is still another thing to try before we get down to the nitty-gritty debuging stuff.

Cheers
Rod

RodG:

Hmmm, the Austpost - Improved module is obsolete. It hasn't worked for months due to a (forced) change of servers.

Rod

Hi rod,

Actually AUSTpost module seems to have come back on-line, or at least partially. I seem to be missing Insured parcels and some other features. Don't know why.

I can't get OZpost module to work at all with SSL activated. Do we have a confirmation by other people using the OZpost module with SSL active that it does work?

p1drobert:

Hi rod,

Actually AUSTpost module seems to have come back on-line, or at least partially. I seem to be missing Insured parcels and some other features. Don't know why.

I can explain this. I eventually got around to adding a redirect on austpost.vcsweb.com to drc.edeliver.com.au

The drc server doesn't 'know' about insurance, letters, prepaid stachels, etc, so the only quotes you'll get will be for parcels.

p1drobert:

I can't get OZpost module to work at all with SSL activated.

As I recall, we traced this issue back to a problem with the session data not being saved/retrieved.

p1drobert:

Do we have a confirmation by other people using the OZpost module with SSL active that it does work?

Sadly, I have had no other feedback on this at all (we're not currently using SSH on our live server, and I still have gotten around to setting up a local server to test with).

Like you, I am pretty much waiting for someone else to step in with "yes it works for me" or "I have the same problem when using SSL too".

It really would be good to know either way whether this is an issue with the module itself or just your specific setup/server/host/whatever.

As a general rule, the fact that no one else has reported a similar issue would indicate the problem is at your end rather than with the module itself ... however, I have discovered that this 'general rule' has been broken several times already, so the current odds are 50/50.

FWIW, although it has been a while since we first diagnosed that it is a session related problem, and that no one else has reported a similar issue, it is still something I have on my checkilist for things to look into, so you haven't been forgotten. I simply find myself with more compelling things I need to do. <sigh>

Cheers
Rod

Hi Rod,

The mysteries of the machine :-) I did try yesterday with Curl on but it didn't work so turned it off. I turned it on today and it works so I guess now I will try again tomorrow and see what happens.

I do use PHP 5.2.9 so that should not be the issue. Also I have just remembered that I have another site that uses the ozpost without Curl without a problem on the same server and using the exact same template.

Also I do have a couple of other sites that use auspost and they work fine but it may be just an illusion :-)

Also sorry but I don't use SSL so I can't help there.

Thanks for your time as always you have been very helpfull :-)

Tassos

hrinfo:

Hi Rod,

The mysteries of the machine :-) I did try yesterday with Curl on but it didn't work so turned it off. I turned it on today and it works so I guess now I will try again tomorrow and see what happens.

It'll probably continue to work. These settings get cached so unless you clear the cache or close and re-open your web browser you'll often not see the effects of any changes until you do,
This caught me out numerous times during development until I realised what was going on.

hrinfo:

I do use PHP 5.2.9 so that should not be the issue. Also I have just remembered that I have another site that uses the ozpost without Curl without a problem on the same server and using the exact same template.

To be perfectly honest, it is a bit of a mystery to me why some sites work without cURL but others don't, even on the same server. What I do know though is that the use of cURL seems to be working for everyone that has had the problem that you had.

hrinfo:

Also I do have a couple of other sites that use auspost and they work fine but it may be just an illusion :-)

It's an illusion. They only partially work.

[/quote]

RodG:

FWIW, although it has been a while since we first diagnosed that it is a session related problem, and that no one else has reported a similar issue, it is still something I have on my checkilist for things to look into, so you haven't been forgotten. I simply find myself with more compelling things I need to do. <sigh>

Cheers
Rod

Hi Rod,

I totally understand.

If you ever get around to it I'm thinking its more likely to be something to do with zencart switching save session addresses once SSL is activated. I switched to SSL once I got rid of paypal and got involved with direct credit card processing on my site. I imagine most people would'nt go this way unless they felt it would increase sales. I thought it would, but was sadly mistaken.
All the other modules seem to be ok with shared sessions as is used by my host, and without SSL active the ozpost module works fine, further indicating it has less to do with shared sessions, and more to do with what happens when SSL is used.

p1drobert:

If you ever get around to it I'm thinking its more likely to be something to do with zencart switching save session addresses once SSL is activated.

Good news ... I got a round tuit.

Bad news. I'm unable to duplicate your problem. It all works just fine with SSL enabled.

My checks included having just the checkout SSL enabled, as well as the entire catalog with SSL enabled.

I also did a bit more code review in regards to the session data, and the ozpost module doesn't differ in any significant way to the older AustPost module.

Furthermore, both the old and the new module saves and loads the session data in the same way as zencart itself ... In other words, when a quote is requested both modules use the zencart session data to extract values/items from the cart for processing. Specicially:

$myorder = $_SESSION['cart']

The old AustPost module also stored its fees data into a session variable, as such:

$_SESSION['fees'] = $fees

It retrieves the data using:

$fees = $_SESSION['fees']

The ozpost module does similar, but the variable name(s) have been changed, eg. $_SESSION['ozpostQuotes']

.... So, what does this all mean? Your guess is as good as mine at the moment..

If you'd care to PM me the admin login details for your store, as well as the login details for FTP/Cpanel/Plesk/Webmin access I should have a bit of spare time over the coming weekend to see if I can figure out what is really going on at your end. I can't think of any other practical way to solve this otherwise.

Cheers
Rod

hi all,

i have just implemented this module for a client, did a search for my question but alas no results and we're going live tonight! i also read "cubing.txt" in the supplied source files but this didn't help either.
my client has several stock items that are quite large (1m x 30cm x 30cm), and as i understand it these are subject to "cubing rules" as they weigh about 1kg. thing is, if multiply out to get a weight based on dimensions i get the following:

1 x 0.3 x 0.3 x 250 = 22.5

this result is over the 20kg limit normally applied (does the cubed limit apply? i assume it must as no prices are given over this figure).

my confusion stems from the fact that the module still seems to calculate the price based on 'actual' weight rather than cubed weight. am i missing something here?

ps: great module by the way rod, really well done!

cheers
andrejs

Hi there,

I think Rod will have a better explanation for your problem but I have just done a quick test using some of the info that you provided the module still works fine. What I have done is the following:

Created a test product using the following info:

Product weight: 1000 (this is grams as this is what I am using)
Product Height (cm): 30
Product Length (cm): 100
Product Width (cm:30

That way basically I am using 1kg as weight and 13030 and everything worked fine and I got a quote. I did also a test with 2kg(2000) and I still a quote.

So you may want to try with different combinations. The only problem that I had was when I was using kilos instead of grams and since I changed to grams everything has been working just fine.

Sorry if that does not help :-)

Tassos

thanks for the response. i worked out why it wasn't using cubed weight, the reason was becasue i was shipping locall, and shipping aus post to and from same city does not use cubed weights.

i have another question now. another item that i tried to buy 2 of, (1.8kg, 42cm x 40cm x 20cm) shipped to and from same city has neither a cubed weight, nor a real weight greater than aus posts minimums, but for some reason no quote is available through the shipping estimator (nor the checkout for that matter). any configuration of stacking or packing or weight or cubed weight should work, but to no avail.

cheers
andy

ALiepinieks:

i have another question now. another item that i tried to buy 2 of, (1.8kg, 42cm x 40cm x 20cm)

2 items of this size/weight will create a package of

Weight 3.6kg
Length 42cm
Width 40cm
Height 40cm (20cm x 2)

This gives the parcel a girth of (40x2) + (40x2) = 160cm.

The maximum girth that Australia Post will accept is 140cm.

Cheers
Rod

wow, i thought it was just the sum of the other two measurements, not actual diameter!
thanks a million.
andrejs

Will the latest version of ozpost work with ZC1.3.7?
as it changes some admin files....

vandiermen:

Will the latest version of ozpost work with ZC1.3.7?
as it changes some admin files....

Yes.

Furthermore the changes made to the admin files are no different than the changes made by the old AustPost-Improved module, so if you have that module wotking you won't need to re-change them.

The reason for changing these files is to allow the adding/editing of the product dimensional data.

Cheers
Rod

ALiepinieks:

wow, i thought it was just the sum of the other two measurements, not actual diameter!
thanks a million.
andrejs

I wish my girth was just a matter of my width + depth :smartalec:

Cheers
Rod

RodG:

This particular module currently has no means of splitting parcels that exceed to 20kg limit.

I do plan on re-adding this functionality in a later update, but I can't give an estimate of when this will be.

Until I do so, you might want to consider using the older 'AustPost Improved' module (which honours the zen-cart 'maximum shipping weight' setting and provides a quote on multiple parcels.

...

ok, so i too (well not really me, more the client who owns the site!) am having fits over the fact there's no parcel splitting, and i'm curious what i should look out for if i revert back to the old aust post mod, assuming there is a) little to no support for it, and b) there were good reason for rewriting the new mod. is it really wise for me to revert back to this old mod simply to split parcels (in your opinion of course)?

my only other alternative presently seems to be to add another shipping option, however as my clients place of business is right next door to an australia post outlet, they're very reluctant to use anything else :)

cheers
andrejs

one more question i guess; if "downgrading", should i uninstall the old module first? install notes on the old module say this is wise when upgrading, not sure about the reverse.
any other important tips? sorry if i'm asking a bit much now, very tight deadline : )

cheers
andy