ozpost shipping module

[RodG]

I'm now getting this message at stage 1 of the checkout:
"Sorry, we are not shipping to your region at this time"
<snip>
When I visited the admin side Ozpost updated itself to v3.3.2 but this issue persists. Can you advise if this notice is part of Ozpost or should I be looking elsewhere to resolve it?

It's NOT part of Ozpost, so you probably need to be looking elsewhere.

It doesn't hurt to remove/install the ozpost module to ensure the database and files are in sync though. Your settings will remain intact.

Cheers
Rod

[antnest]

Rod can you help me find where to do this please? I'm getting the same error The service Sea Mail for NEW ZEALAND does not accept parcels over 20kg. )

Oops I didnt quote original message....you were saying to "turn off error messages"

Also would it be easy for me to update to your ozpost module? By the looks of it i'm using something else (ozzy post) that was set up for me years ago.

Thanks in advance

http://www.antmanhelmetdesign.com/store/

[RodG]

Rod can you help me find where to do this please? I'm getting the same error The service Sea Mail for NEW ZEALAND does not accept parcels over 20kg. )

Oops I didnt quote original message....you were saying to "turn off error messages"

The early versions of ozpost don't have the option to turn these messages off, and this particular error message is now being suppressed by the ozpost servers (which means that whatever module you are using, it is still connecting to the old drc.edeliver servers, which were to be turned off earlier this year (but they had a reprieve because a lot of merchants weren't ready for it).

Also would it be easy for me to update to your ozpost module?

The ozpost module installs are getting easier all the the time (with only two files to install/copy to the server there's not a lot that can go wrong).

After the initial install of ozpost V3.x.x further upgrades are either fully automatic (V3.3.0 -> V3.3.2), or invoked via a single keypress (V3.3.3 and above).

Cheers
Rod

[gmturner]

Hi Rod, i upgraded to zen cart V1.5 with fresh install about 6months ago and ever since ozpost has been doing something wierd where it works out postage fine but it wont show what type of postage it was from admin area or on the order summary that is sent to customer and admin.

In the email it shows as:


Sub-Total: $171.00
( ): $10.85
GST: $15.55
Total: $181.85

in admin area is shows like this:



any idea what i may have done wrong?

[RodG]

Hi Rod, i upgraded to zen cart V1.5 with fresh install about 6months ago and ever since ozpost has been doing something wierd where it works out postage fine but it wont show what type of postage it was from admin area or on the order summary that is sent to customer and admin.

any idea what i may have done wrong?

I've not experienced this symptom before.

What version of ozpost are you using? The most current is V3.3.5.

My suggestion would be to update to this version and see if the problem resolves itself.

Cheers
Rod

Ps. The latest version has only just been uploaded to the zencart site and will take a few days for it to be made available. You can d/load the latest version at any time from http://ozpost.net.au/downloads/

[gmturner]

Im using 3.3.4 and its set to auto-update but doesnt seem to want to jump up to 3.3.5 when i force a re-install/update.

It only seems to happen on paypal express checkout from what i can tell. Direct deposit seems to work fine.

I just tried doing a paypal express checkout and i bought a item worth $4.50 and it takes you to the paypal thing and gets you to log in etc and tell you its going to charge you $4.50 and you press continue and then it takes you back to my site and then adds postage on, but doesnt give you a option of which one you want to pick. It just auto-selects cheapest?

When i do re-install it says:
The file (/home/countr18/public_html/*adminareaname*/includes/languages/english/product.php) has already been modified. This alert can be ignored
The file (/home/countr18/public_html/*adminareaname*/includes/modules/update_product.php) has already been modified. This alert can be ignored
The file (/home/countr18/public_html/*adminareaname*/includes/modules/product/collect_info.php) has already been modified. This alert can be ignored

The bottom 2 appear to be changed for ceon uri mapping, the top one im not sure. is this a issue that may be causing it?

Ill re-install with 3.3.5 in a minute and see how she goes.

[RodG]

Im using 3.3.4
It only seems to happen on paypal express checkout from what i can tell. Direct deposit seems to work fine.

In other words you have been having this exact same problem since about the start of the V3.x.x series and possibly before?

and its set to auto-update but doesnt seem to want to jump up to 3.3.5 when i force a re-install/update.

"Doesn't seem to" doesn't really rell me a lot. :-(

I just tried doing a paypal express checkout and i bought a item worth $4.50 and it takes you to the paypal thing and gets you to log in etc and tell you its going to charge you $4.50 and you press continue and then it takes you back to my site and then adds postage on, but doesnt give you a option of which one you want to pick. It just auto-selects cheapest?

The way this works it outside the scope of anything ozpost (or any other shipping module) has any control over, so if this is a problem that only started occuring about 6 months ago it will be caused by a change in your paypal settings

Having said that, due to bad placement of a bit of javascript code in v3.3.3 there is a problem with PayPal checkout in that it'll only produce a blank screen and not even go to the PayPal site. This was fixed in V3.3.4

When i do re-install it says:
The file (/home/countr18/public_html/*adminareaname*/includes/languages/english/product.php) has already been modified. This alert can be ignored
The file (/home/countr18/public_html/*adminareaname*/includes/modules/update_product.php) has already been modified. This alert can be ignored
The file (/home/countr18/public_html/*adminareaname*/includes/modules/product/collect_info.php) has already been modified. This alert can be ignored

These messages are generated by the ozpost installer code, and yes, they CAN be ignored. If you wish to get rid of these messages you will need to click the REMOVE button to uninstall ozpost, then re-replace these three files using the original files from the zencart distribution package, and finally, click the INSTALL button to re-install the ozpost module, which will then be able to perform the modifications needed. (The changes being exactly the same as the changes already made to the pre-modified files).

Although this may seem a bit odd/quirky, the reason for it is that up until V3.x.x. the initial installation of the ozpost module required that these 3 'core' files be replaced by the copies from the ozpost package. This has always been a source of problems because quite often they were not being replaced, or they were being placed into the wrong folders. They were also being re-replaced with the ZenCart upgrades, causing a loss of the ability to add or modify the product dimension data.
V3.x.x has taken a different approach in that these files no longer need to be replaced, but instead, the module will make a backup copy of them and perform the needed modifications during installation (and revert them back to the zencart originals upon removal). This makes installations a lot easier (just two files, plus the graphics) to upload to the server with no need to replace these core files.

The update code performs a check to see if these files have already been replaced, and if so, it generates the alerts, but makes no further changes to the files.

Ill re-install with 3.3.5 in a minute and see how she goes.

So, how'd it go?

Cheers
Rod

[gmturner]

In other words you have been having this exact same problem since about the start of the V3.x.x series and possibly before?

yeh it started i think as soon as i upgraded, so whatever version you were on 6months ago. Ive only now decided to address it.

"Doesn't seem to" doesn't really rell me a lot. :-(

Well i forced a upgrade and it upgraded to 3.3.4 yesterday, it would not upgrade to 3.3.5 automatically. I did this today manually by replacing the files.

The way this works it outside the scope of anything ozpost (or any other shipping module) has any control over, so if this is a problem that only started occuring about 6 months ago it will be caused by a change in your paypal settings

There are 4 ways you can pay for something in my store:
-Paypal express checkout(dont need to create account on my site, just sign into paypal. Is a new feature in 1.5 i believe) - this one has the issues.
-Normal paypal where you have to sign into my site and then select it - works fine.
-Direct bank deposit - works fine
-cheque/money order - works fine

So the issue i believe is restricted to paypal express and may possibly be linked to how it doesnt let you pick which method to ship with it just auto-picks the cheapest for you, this is where the problems start as seen here:

When you use one of the payment methods that work fine that shouldnt even be one of your logo's.. it should be text and this is where the problem seems to be, its trying to use the logo's instead of text and the logo's dont work in admin area or in emails so it just shows as nothing.

The update code performs a check to see if these files have already been replaced, and if so, it generates the alerts, but makes no further changes to the files.

So it senses that my files are changed and gives up? do i need to go in manually and put some of your code in in this case? what are some chunks of your code i can look for in these files to make sure auspost has installed itself correctly?


I think i found a small error in your INSTALL.txt

Installation: Copy the following files to your store (keeping the same folder hierarchy)
Required: includes/modules/ozpost.php

That should be includes/modules/shipping/ozpost.php shouldnt it? thats the way you have it in the actual folder structure anyway.

[RodG]

yeh it started i think as soon as i upgraded, so whatever version you were on 6months ago. Ive only now decided to address it.

I think that this alone would suggest that ozpost is NOT the issue (unless you are refering to an ozpost upgrade you did six months ago rather than the Zencart upgrade you did six months ago. Or did you upgrade both at the same time?

Well i forced a upgrade and it upgraded to 3.3.4 yesterday,

I'm still not sure what you mean by 'forced an upgrade'. Prior to V3.3.2 this was fully automatic with no way to 'force' anything. Since v3.3.2 I've added a button that needs to be pressed to initiate the updates. It doesn't 'force' anything, it is just a button that effectively make it possible to prevent the automatic updates until you are ready to do so.

it would not upgrade to 3.3.5 automatically.

Did it show the update was available and *attempt* to update itself (perhaps with errors?) or was you presented with the update button?

Sorry if these questions seem silly or obvious, but I can't see what you are seeing, and your terminology is causing me confusion.

I did this today manually by replacing the files.

I assume your PayPal problem still exists? (It probably will do, because other than my blunder with v3.3.3 the operation of the module hasn't changed for years)

There are 4 ways you can pay for something in my store:
-Paypal express checkout(dont need to create account on my site, just sign into paypal. Is a new feature in 1.5 i believe) - this one has the issues.
-Normal paypal where you have to sign into my site and then select it - works fine.
-Direct bank deposit - works fine
-cheque/money order - works fine

There is *no* connection between payment methods and the shipping methods.

So the issue i believe is restricted to paypal express and may possibly be linked to how it doesnt let you pick which method to ship with it just auto-picks the cheapest for you,

You are quite right, this IS where the problem is, but there is *nothing* the ozpost (or any other shipping module) can do to affect this.
If you wish the customer to have the ability to select the shipping method, you'll need to set the following option in your paypal module settings:
--------------------------------------------------------------------------------------
Express Checkout: Select Cheapest Shipping Automatically
When customer returns from PayPal, do we want to automatically select the Cheapest shipping method and skip the shipping page? (making it more *express*)
Note: enabling this means the customer does *not* have easy access to select an alternate shipping method (without going back to the Checkout-Step-1 page)
----------------------------------------------------------------------------------------

this is where the problems start as seen here:

When you use one of the payment methods that work fine that shouldnt even be one of your logo's.. it should be text and this is where the problem seems to be, its trying to use the logo's instead of text and the logo's dont work in admin area or in emails so it just shows as nothing.

They do (or did) used to work, but there was a problem in that the database fields weren't big enough to hold all the data, so to mitigate this issue the ozpost module used to extend the size of these fields. This was way back in v2.x.x though. The module has long since stopped using these logos in the /admin/ functions, and I didn't think there was any way they could still be used. It seems I'm mistaken though, and will need to investigate this a little further.

Anyway, this means there are now two ways to cure your problem. The first is to adjust the paypal setting so that the customer can choose the shipping method.
The second would be to disable the use of the icons (which may or may not work. It depends on whether the lack of feedback problem is related to the field size or not).

So it senses that my files are changed and gives up?

No. It senses that the files already have the required changes, and if so it makes a straight copy of the changed files without re-applying the same changes (which will cause problems). The rest of the upgrade processing continues normally (at least that's the theory). The fact that there were no other error messages suggests the upgrade was succesfull. (This is why I can't really understand why you are finding it wasn't successull. There are a zillion checks that occur during an upgrade/install), I can't think of how it can fail an upgrade without producing a useful error message to explain the cause.

do i need to go in manually and put some of your code in in this case?

No. The entire idea behind these latest changes are so that users don't have to manually modify any code, ever. In fact the latest code even incorperates tests and checks to determine whether products are weighed in Gms or Kgs, and will update the language files to match (the defualt definition of 'lbs' is never going to be right for an aust merchant)

what are some chunks of your code i can look for in these files to make sure auspost has installed itself correctly?

The main ozpost.php file should be self evident as to which version is used from the version number displayed in the config screen.
The ozpost language file never gets auto updated, and the only time this will change is when a new carrier is added.

All the other files that get changed or modified will have a current date/time stamp, and the *original* files will be renamed with a _restore extension.

In your case, the three files that didn't get updated because they were premodified will be exactly the same size and have the same contents as the same named _restore files.

Here's a list of the files that ozpost ether creates or modifies:

create: DIR_FS_ADMIN , "clicknsend.php"
create: DIR_FS_ADMIN, DIR_WS_INCLUDES . "extra_datafiles/clicknsend.php"
create: DIR_FS_ADMIN, DIR_WS_INCLUDES . "functions/extra_functions/init_clicknsend_dhtml.php" (zen v1.5.x only)
create: DIR_FS_ADMIN, DIR_WS_INCLUDES . "boxes/extra_boxes/clicknsend_customers_dhtml.php" (zen 1.3.x only)
modifyIR_FS_ADMIN, DIR_WS_LANGUAGES . "english/product.php" (this premodded file was needed with ozpost v3.3.2 and below)
modifyIR_FS_ADMIN, DIR_WS_MODULES . "update_product.php" (this premodded file was needed with ozpost v3.3.2 and below)
modifyIR_FS_ADMIN, DIR_WS_MODULES . "product/collect_info.php" (this premodded file was needed with ozpost v3.3.2 and below)
modifyIR_FS_CATALOG, DIR_WS_TEMPLATES . "template_default/templates/tpl_modules_shipping_estimator.php"
modifyIR_FS_ADMIN, DIR_WS_LANGUAGES . "english.php" (changes 'lbs' to kgs/gms only)
modifyIR_FS_CATALOG, DIR_WS_LANGUAGES ."english.php" (changes 'lbs' to kgs/gms only)

I think i found a small error in your INSTALL.txt
That should be includes/modules/shipping/ozpost.php shouldnt it? thats the way you have it in the actual folder structure anyway.

Yup, that's an error in the text file. The actual folders are correct.

Cheers
Rod

[gmturner]

You are quite right, this IS where the problem is, but there is *nothing* the ozpost (or any other shipping module) can do to affect this.
If you wish the customer to have the ability to select the shipping method, you'll need to set the following option in your paypal module settings:
--------------------------------------------------------------------------------------
Express Checkout: Select Cheapest Shipping Automatically
When customer returns from PayPal, do we want to automatically select the Cheapest shipping method and skip the shipping page? (making it more *express*)
Note: enabling this means the customer does *not* have easy access to select an alternate shipping method (without going back to the Checkout-Step-1 page)
----------------------------------------------------------------------------------------



They do (or did) used to work, but there was a problem in that the database fields weren't big enough to hold all the data, so to mitigate this issue the ozpost module used to extend the size of these fields. This was way back in v2.x.x though. The module has long since stopped using these logos in the /admin/ functions, and I didn't think there was any way they could still be used. It seems I'm mistaken though, and will need to investigate this a little further.

Anyway, this means there are now two ways to cure your problem. The first is to adjust the paypal setting so that the customer can choose the shipping method.
The second would be to disable the use of the icons (which may or may not work. It depends on whether the lack of feedback problem is related to the field size or not).

Changing the paypal setting to allow the user to choose their shipping has fixed it.

I still think this problem is ozpost related and only happens when the customer uses paypal express checkout and the option is set for it to auto-select cheapest postage. I may be wrong though, you may want to look into it further. If i find some spare time i might try install on a fresh install of 1.5 and see if it happens. Not that i really care anymore as its better for my customers to be able to select what they want and it also opens up the free store pickup option which they didnt even get a choice to before.