ozpost shipping module

[robax]

Hi Rod

This is a fresh post, not following on from any previous on in this thread.

I've just upgraded my Zen Cart from 1.3.9 to 1.5.1 and after that was done and confirmed working, I upgraded the OZ Post module from 3.1.1 to the current 3.5.2

I ended up doing the manual shift of the generated files from the cache into their appropriate locations. That all went fine.

I have removed and added the module from the shipping modules and have been through all options to ensure everything is correct.

There are two problems since this upgrade.

The first issue is a display problem.

On first visit from any browser, when then the estimator is meant to display the results, the page breaks and no results are displayed. When I examine the HTML source, the div with id="shippingEstimatorContent" is missing.

That looks like this: http://s21.postimg.org/l6m3xsjmv/ozpost_1.jpg

If I then revisit or refresh the page, the estimator shows, but does not show any of the OZ Post results. However in this case, the HTML source does in fact contain estimator code.

That looks like this: http://s11.postimg.org/ggy5dc7sj/ozpost_2.jpg

To quickly see this happening live, please add this example product to cart and then go to checkout and use 3000 as the post code:
http://www.saxandwoodwind.com.au/ind...oducts_id=1289

That's one problem.


The second issue has to do with the OZ Post results - I'm not getting any.

Try adding this product to cart and then get a shipping estimate with post code 3000:
http://www.saxandwoodwind.com.au/ind...roducts_id=474

This example should give plenty of Australia Post results, but it does not show any. Enabled parcels are: Australia Post PrePaid Satchels, 500g Satchel., 500g Express Satchel, 3kg Satchel., 3kg Express Satchel

This worked fine with the previous version of the module, even after the upgrade to ZC 1.5.1

I briefly enabled the debug message option in the module it makes the page show this:
http://s7.postimg.org/kkkgxjmx7/ozpost_3.jpg

Let me know what you think.

Thanks for any advice on this.
Regards
Rob

Environment info:
v1.5.1 [2013-10-25 16:43:45] (Version Update 1.5.0->1.5.1)
v1.5.0 [2013-10-25 16:43:45] (Version Update 1.3.9->1.5.0)
v1.3.9b [2010-05-18 18:34:34] (Version Update 1.3.8->1.3.9b)
v1.3.8 [2008-07-30 02:07:56] (Fresh Installation)
Database: MySQL 5.5.21-log
PHP Version: 5.2.17 (Zend: 2.2.0)

[RodG]

Hi Rod
This is a fresh post, not following on from any previous on in this thread.

:)

Apologies for the delayed reply, I needed a little time to investigate some of this.

On first visit from any browser, when then the estimator is meant to display the results, the page breaks and no results are displayed. When I examine the HTML source, the div with id="shippingEstimatorContent" is missing.

That looks like this: http://s21.postimg.org/l6m3xsjmv/ozpost_1.jpg

If you 'view paqe source' of this same page you can get a better idea of what you are (and aren't) seeing.

<br class="clearBoth" />

<!-- ** BEGIN PAYPAL EXPRESS CHECKOUT ** -->
<!-- ** END PAYPAL EXPRESS CHECKOUT ** -->

      <script language="javascript" type="text/javascript"><!--

function update_zone(theForm) {
  // if there is no zone_id field to update, or if it is hidden from display, then exit performing no updates
  if (!theForm || !theForm.elements["zone_id"]) return;
  if (theForm.zone_id.type == "hidden") return;

  // set initial values
  var SelectedCountry = theForm.zone_country_id.options[theForm.zone_country_id.selectedIndex].value;
  var SelectedZone = theForm.elements["zone_id"].value;

  // reset the array of pulldown options so it can be repopulated
  var NumState = theForm.zone_id.options.length;
  while(NumState > 0) {
    NumState -= 1;
    theForm.zone_id.options[NumState] = null;

..... lines deleted for brevity -------------

function showStateField(theForm) {
    theForm.state.disabled = false;
    theForm.state.className = 'inputLabel visibleField';
    theForm.state.setAttribute('className', 'visibleField');
    document.getElementById("stateLabel").className = 'inputLabel visibleField';
    document.getElementById("stateLabel").setAttribute('className', 'inputLabel visibleField');
    document.getElementById("stBreak").className = 'clearBoth visibleField';
    document.getElementById("stBreak").setAttribute('className', 'clearBoth visibleField');
  }
//--></script><!-- shipping_estimator //-->

<script language="javascript" type="text/javascript">
function shipincart_submit(){
  document.estimator.submit();
  return false;
}
</script>

This is all standard/default Zencart code for the country/state dropdown menus. The ozpost module doesn't make any changes to this code. It appears that the page is being aborted trying to load whatever comes next. (possibly the tpl_modules_shipping_estimator.php file, which *does* get modified by ozpost.

Try reverting this (tpl_modules_shipping_estimator.php) back to the unmodified copy to see if the problem goes away. The ozpost module should still function, but it will be missing the code to select the suburb name, and that is only really needed for the courier services, Australia Post quotes don't need this. Even the courier quotes will still work for *most* destinations

If I then revisit or refresh the page, the estimator shows, but does not show any of the OZ Post results. However in this case, the HTML source does in fact contain estimator code.

That looks like this: http://s11.postimg.org/ggy5dc7sj/ozpost_2.jpg

This isn't really surprising. The 'refreshed' page is obtaining the quotes from a local cache, and since no quotes were returned from the original request, there are none to display on the refteshed page. Under normal circumstances the ozpost module would have flagged this as an error so as to force a fresh quote request rather than displaying the non quote result, but because the ozpost code didn't complete, this flagging never took place.

To quickly see this happening live, please add this example product to cart and then go to checkout and use 3000 as the post code:
http://www.saxandwoodwind.com.au/ind...oducts_id=1289

Thanks. That has allowed me to verify the problem and report my findings. Always a step in the right directlion. :)

The second issue has to do with the OZ Post results - I'm not getting any.
I briefly enabled the debug message option in the module it makes the page show this:
http://s7.postimg.org/kkkgxjmx7/ozpost_3.jpg

This confirms what I said above. The quote (or lack of) that you are seeing here are being retieved from a local cache (specifically, the SESSION data).

Try adding this product to cart and then get a shipping estimate with post code 3000:
http://www.saxandwoodwind.com.au/ind...roducts_id=474

According to our logs, your store is both sending and recieving valid data for this item.

This example should give plenty of Australia Post results, but it does not show any. Enabled parcels are: Australia Post PrePaid Satchels, 500g Satchel., 500g Express Satchel, 3kg Satchel., 3kg Express Satchel

Although the satchels should be showing, I would suggest that you also enable the Aust Post regular parcels (at least for the time being). IF for some reason the satchels are being disallowed via the client code, the regular parcels would be a more suitable fallback rather than resorting to one of the static rates (or no rates at all).

This worked fine with the previous version of the module, even after the upgrade to ZC 1.5.1

Let me know what you think.

Although ozpost V3.5.1 does have a known display issue (the quote items not all lining up) I've not come across this particular problem before, so about all I can suggest at this stage is
1) restore the rpl_modules_shipping_estimator.php file back to a zencart original, and
2) Enable the australia post parcel methods.

Hopefully one or the other may shed more light on the problem.

Cheers
Rod

[robax]

:)

Although ozpost V3.5.1 does have a known display issue (the quote items not all lining up) I've not come across this particular problem before, so about all I can suggest at this stage is
1) restore the rpl_modules_shipping_estimator.php file back to a zencart original, and
2) Enable the australia post parcel methods.

Hopefully one or the other may shed more light on the problem.

Thanks for getting back to me on this, much appreciated.

First I looked for the tpl_modules_shipping_estimator.php and it is using the one in my custom template folder. I compared it to the original from 1.5.1 and the one from my previous 1.3.9 install and can confirm that it is the one modified by OZPost for this release.

Then I replaced it with an original 1.5.1 file as suggested and visited the checkout.
That made it look like this screenshot. It didn't seem to do anything or provide any results:
http://s21.postimg.org/k87o5xzif/ozpost_4.jpg

Then I enabled debug to see what it would show - That was this:
http://s21.postimg.org/n8oimhatj/ozpost_5.jpg

Then I progressively enabled Australia Post Letter, Satchels and Parcels until all were ticked, checking for a change in behavior along the way. It showed no results no matter what I selected.

I've now restored the OZPost tpl_modules_shipping_estimator.php again now and have left Regular and Express Australia Post Parcels enabled in addition to the satchels I had all along. I restored it to the non-working state in case you need to see it fail.

A suitable test product again is one like this:
http://www.saxandwoodwind.com.au/ind...oducts_id=1107


Is there possibly a permissions problem with this? One of the fiddly bits to get right with Zen Cart on IIS is the file system permissions and I had to use the manual install method for this because I didn't have the permissions quite right when I upgraded OZPost. I'm wondering if it is trying to write a file somewhere that it can't?

I'm also wondering if I should downgrade to the OZPost I had on here before, but I won't do that unless you've run out of ideas.

Thanks for any further advice on this.
Regards
Rob

[RodG]

I replaced it with an original 1.5.1 file as suggested and visited the checkout.
That made it look like this screenshot. It didn't seem to do anything or provide any results:
http://s21.postimg.org/k87o5xzif/ozpost_4.jpg

Well, there goes my biggest suspect. I was pretty certain that even if no quotes were obtained that this would at least stop the page being aborted prematurely.

Then I enabled debug to see what it would show - That was this:
http://s21.postimg.org/n8oimhatj/ozpost_5.jpg

As before, this is only showing what is being stored in the SESSION data, which unfortunately isn't much help in a case like this.

Then I progressively enabled Australia Post Letter, Satchels and Parcels until all were ticked, checking for a change in behavior along the way. It showed no results no matter what I selected.

OK, this idea was more of a passing thought. I didn't expect it to solve the aborted page problem, which is what you/we really need to concentrate on.

Is there possibly a permissions problem with this?

I'd have to say *probably not*. At least not for anything that the ozpost module is doing. The tpl file is obviously readable, else we wouldn't be getting the suburb names being shown. The SESSION data is save just like any other session data, and if there was a problem there you'd be having much more serious problems.

One of the fiddly bits to get right with Zen Cart on IIS is the file system permissions and I had to use the manual install method for this because I didn't have the permissions quite right when I upgraded OZPost. I'm wondering if it is trying to write a file somewhere that it can't?

The ozpost module does attempt to write data to the /cache/ folder if the 'click n send' option is enabled, but it will only do this when the order is submitted. It doesn't write to anything else whilst obtaining a quote.

I'm also wondering if I should downgrade to the OZPost I had on here before, but I won't do that unless you've run out of ideas.

Yes, I am out of ideas. Downgrading will be a worthwhile test, because if that does solve the issue it will demonstrate that the problem is caused with a change made to the last upgrade. Offhand I can't think of (m)any changes made that would cause the problem, but if the test shows that this is indeed the case it will narrow the possibilities down tremendously.

Oooops, I just remembered, one of the changes I did make with the last upgrade *does* involve writing stuff to a folder, specifically, the /images/icons/ozpost folder. However, as long as my error checking is working as it should, if the folder doesn't exist or is unwritable the module should just ignore it and move on.
FYI, what this is trying to do is add the icons for the new methods (if they are needed but missing). However, I don't *think* this would be the cause of the problem, because it 1st needs to obtain the quotes before it can check if they are needed or not.

A 'normal' downgrade is generally a matter of replacing the /modules/shipping/ozpost.php file with the older one, then logging into the admin and running the remove/install process (to resync the database).

OK, that has just given me another idea... With the new/latest ozpost there *should* be methods displayed for 'SkippyPost' (for overseas quotes). If you are NOT seeing these as an option to enable/disable it means that the database is out of sync with the files, and that could go a long way to explaining things.

If you do find these options are missing then going back to the last known working version of ozpost should get things going for you, but it won't solve the core problem as to why the database isn't getting resynced, and this could be because the 'install' code is aborting before it gets that far (as would happen if you have a permissions problem during the install). If this IS the case, then rather than reverting back to an older version, if you load
/includes/modules/shipping/ozpost.php into a text editor and search for the line of code that reads:

---------------------------------------
if ($NO == 0) { // no point in continuing //
-------------------------------------------

This should be around line#3096, then change it to read

---------------------------------------
if ($NO != 0) { // no point in continuing //
-----------------------------------------

Then resave the file, and try the remove/install keypresses again you'll still get the alerts/warnings about the incorrect permissions, but it will ignore them and proceed to update the database anyway.

Please only do this with the latest ozpost code and only if the SkippyPost options are missing. If you do it for any other reason you will be digging a bigger hole and reverting back to the older version will be a much wiser idea.

Cheers
Rod.

PS. Never keep a 'backup' of the ozpost.php code in the same folder as the code you are working with, or if you do, you must give it a filename that *doesn't* end with '.php'
Examples
"ozpost_bak.php" and "ozpost_3.5.1.php" will cause problems.
"ozpost.php_bak" and "ozpost_3.5.1.php_bak" will NOT cause problems.

[robax]

Thanks for the extensive and detailed reply Rod.

I've reorganised my reply here to reflect the order in which I worked through your post.

Well, there goes my biggest suspect. I was pretty certain that even if no quotes were obtained that this would at least stop the page being aborted prematurely.

Sorry... but I've just realised that I didn't make this bit quite as clear as I should have... and the screenshot didn't help either:
When I replaced the tpl_modules_shipping_estimator.php with a genuine one from 1.5.1, the page did not break on first load as it did with the Ozpost modified file. However it didn't do anything else either and did not provide any result other than what was in the screenshot.

So the comment here is that it did not break the page on load when the original file is in place. Does that mean we have a further clue?

Oooops, I just remembered, one of the changes I did make with the last upgrade *does* involve writing stuff to a folder, specifically, the /images/icons/ozpost folder. However, as long as my error checking is working as it should, if the folder doesn't exist or is unwritable the module should just ignore it and move on.

I've reapplied suitable permissions to the folder now in any case.

OK, that has just given me another idea... With the new/latest ozpost there *should* be methods displayed for 'SkippyPost' (for overseas quotes). If you are NOT seeing these as an option to enable/disable it means that the database is out of sync with the files, and that could go a long way to explaining things.

Yes, there's heaps of new stuff in this release over the one we had previously, including SkippyPost.

If you do find these options are missing then going back to the last known working version of ozpost should get things going for you, but it won't solve the core problem as to why the database isn't getting resynced, and this could be because the 'install' code is aborting before it gets that far (as would happen if you have a permissions problem during the install). If this IS the case, then rather than reverting back to an older version, if you load
/includes/modules/shipping/ozpost.php into a text editor and search for the line of code that reads:

---------------------------------------
if ($NO == 0) { // no point in continuing //
-------------------------------------------

This should be around line#3096, then change it to read

---------------------------------------
if ($NO != 0) { // no point in continuing //
-----------------------------------------

Then resave the file, and try the remove/install keypresses again you'll still get the alerts/warnings about the incorrect permissions, but it will ignore them and proceed to update the database anyway.

Please only do this with the latest ozpost code and only if the SkippyPost options are missing. If you do it for any other reason you will be digging a bigger hole and reverting back to the older version will be a much wiser idea.

I haven't done this as the Skippy Post items are present.

PS. Never keep a 'backup' of the ozpost.php code in the same folder as the code you are working with, or if you do, you must give it a filename that *doesn't* end with '.php'
Examples
"ozpost_bak.php" and "ozpost_3.5.1.php" will cause problems.
"ozpost.php_bak" and "ozpost_3.5.1.php_bak" will NOT cause problems.

Got it - I went back in and removed an estimator template file that I had named like that and then tested again, but it still breaks.


And then things started to get interesting.....

Yes, I am out of ideas. Downgrading will be a worthwhile test, because if that does solve the issue it will demonstrate that the problem is caused with a change made to the last upgrade. Offhand I can't think of (m)any changes made that would cause the problem, but if the test shows that this is indeed the case it will narrow the possibilities down tremendously.
A 'normal' downgrade is generally a matter of replacing the /modules/shipping/ozpost.php file with the older one, then logging into the admin and running the remove/install process (to resync the database).

I've just now tried this to see what happens...

After restoring the ozpost.php with the one I had in ZC 1.3.9, the UI posted a message about the 3.5.2 upgrade being available and also 2 red warnings about not being able to write the tpl file.

Then I clicked the remove button and the messages showed again.

Then I clicked to install and the messages vanished and all my old 3.1.1 settings showed up.

Then I went to the checkout and it displayed a warning as in this screenshot:
http://s22.postimg.org/t8u8djfn5/ozpost_6.jpg

That was suspicious (possibly a dud product weight entry), so then I tried a bigger product and I got a result like I used to:
http://s8.postimg.org/ncduchbrp/ozpost_7.jpg

So armed with that I reinstalled 3.5.2 again and went through the whole process, again copying the files by hand, with one minor difference - I noticed that there was a language change I had previously ignored - What used to be 'KGs' is now 'Kilos', so I put that through to make the upgrade 100% accurate.

And now I get a slightly different result form my original post:

When I add the same test product to cart as previous:
http://www.saxandwoodwind.com.au/ind...oducts_id=1289

The checkout still breaks on first load, but on page refresh it now it produces a couple of the desired shipping options!!

I'm unsure which step has caused that part to start working - the only difference I'm aware I made is the KGs > kilos language update, and for good measure I applied it in both the default english.php and in my template's own english.php


So that's great, and it just leaves us with the page breaking on first load. The only clue I can offer is that it doesn't break with the 3.1.1 Ozpost in place.

I've left 3.5.2 installed on the site, and so you can see it happening if you need to check it again. The product linked above is a good one to try.


Thanks for all the assistance so far!
Regards
Rob

[RodG]

When I replaced the tpl_modules_shipping_estimator.php with a genuine one from 1.5.1, the page did not break on first load as it did with the Ozpost modified file.
However it didn't do anything else either and did not provide any result other than what was in the screenshot.

This implies there is more than one problem. They need to be tackled individually, so the 1st thing to with the V3.5.2 install is to leave the tpl_ file as per the ZenCart original.

This will allow me/us to debug the other issue(s)

Yes, there's heaps of new stuff in this release over the one we had previously, including SkippyPost.
I haven't done this as the Skippy Post items are present.

That's fine. Regardless of anything else, the Skippy Post options will be a clear indicator that the database is in sync with the ozpost files.
They will/should be present with ozpost v3.5.2 but missing from the older versions.

Got it - I went back in and removed an estimator template file that I had named like that and then tested again, but it still breaks.

Unless I'm misreading again, this causes it to break in a different way. IE: With the original/unmodified tpl file the page loads normally, and with the modified file the page aborts early. Is that correct?

After restoring the ozpost.php with the one I had in ZC 1.3.9, the UI posted a message about the 3.5.2 upgrade being available and also 2 red warnings about not being able to write the tpl file.

The upgrade message is indicating that a connection to our servers is ok. These can be ignored. The upgrade won't procede until/unless you tell it to.

The inability to write to the tpl file is a permissions problem. In this case it is actually a good thing because it means that ozpost can't make its modifications and will leave the original file intact. The warnings can therefore be ignored.

Then I clicked the remove button and the messages showed again.

The remove process tries to restore the file modifications. Since it wasn't possible for it to modify the file in the 1st place this message can also be ignored.

Then I clicked to install and the messages vanished and all my old 3.1.1 settings showed up.

This older version expects/requires that the relevent files be replaced manually by those in the ozpost.zip file. Therefore the install/uninstall code has no need to modify them, so therefore no errors will be produced during the process.

Then I went to the checkout and it displayed a warning as in this screenshot:
http://s22.postimg.org/t8u8djfn5/ozpost_6.jpg

This is because the Kgs/gms database setting is getting 'lost' between the different code version. This will need to be set/reset manually between the upgrades and downgrades.

That was suspicious (possibly a dud product weight entry), so then I tried a bigger product and I got a result like I used to:
http://s8.postimg.org/ncduchbrp/ozpost_7.jpg

Not a product weight entry, but the kg/gms setting getting 'lost' (a known bug)

So armed with that I reinstalled 3.5.2 again and went through the whole process, again copying the files by hand, with one minor difference - I noticed that there was a language change I had previously ignored - What used to be 'KGs' is now 'Kilos', so I put that through to make the upgrade 100% accurate.

The change in the language file is unimportant. It doesn't affect functionality in any way. This change, and the change to the kg/gms setting was to provide consistency.. In the older code in some places it was using 'Kg' in other places it was 'Kgs' in even other places it was 'kg' or 'kgs'. Same with the gms, which was one of Gms, Gm, gm & gms. The 'Kilos' in the language file is/was an odd one out, and the only one that is under user control.

And now I get a slightly different result form my original post:

When I add the same test product to cart as previous:
http://www.saxandwoodwind.com.au/ind...oducts_id=1289
The checkout still breaks on first load, but on page refresh it now it produces a couple of the desired shipping options!!

Although it may seem quite confusing, it now seems like that this is going to be quite easy to fix/resolve :)

I'm unsure which step has caused that part to start working - the only difference I'm aware I made is the KGs > kilos language update, and for good measure I applied it in both the default english.php and in my template's own english.php
So that's great, and it just leaves us with the page breaking on first load. The only clue I can offer is that it doesn't break with the 3.1.1 Ozpost in place.
I've left 3.5.2 installed on the site, and so you can see it happening if you need to check it again. The product linked above is a good one to try.

OK, so if you now revert the the tpl file back to the original zencart one this will/should prevent the page from breaking on the 1st load.
At the same time, if you double check that the ozpost Kg/gm setting is correct, that should allow valid quotes to be returned.

If you *don't* use any of the courier services you can probably leave it like that with no ill effect.

If you do wish to use the courier services I/w need to figure out what is causing the problem with the tpl file changes. I'm *guessing* that this probably has something to do with the AJAX code that is added to retrieve and display the suburb names. I'll not investigate this any further until/unless you confirm that the original tpl file and the correct kg/gms settings do indeed provide valid quotes without the 1st page breaking.

Cheers
Rod

[robax]

Thanks again for checking through this Rod

OK, so if you now revert the the tpl file back to the original zencart one this will/should prevent the page from breaking on the 1st load.

I've reverted to the original 1.5.1 version of tpl_modules_shipping_estimator.php - Note that this did not break the page, but also did not produce quotes.

At the same time, if you double check that the ozpost Kg/gm setting is correct, that should allow valid quotes to be returned.

Got it - I event went into the DB and looked for the setting.
MODULE_SHIPPING_OZPOST_WEIGHT_FORMAT is set to 'kilos'

If you *don't* use any of the courier services you can probably leave it like that with no ill effect.

We did have TNT Road Express enabled before the upgrade, but it was giving really crazy prices right after the upgrade so we disabled it. We'd like to enable that again and probably also try the Couriers Please one that is new in there.

If you do wish to use the courier services I/w need to figure out what is causing the problem with the tpl file changes. I'm *guessing* that this probably has something to do with the AJAX code that is added to retrieve and display the suburb names. I'll not investigate this any further until/unless you confirm that the original tpl file and the correct kg/gms settings do indeed provide valid quotes without the 1st page breaking.

I've just spent a few hours going nutty reverting files and retesting. I'm beginning to get inconsistent results and that makes it difficult to tell you exactly what is happening.

I reverted to the 1.5.1 original file - No break but also no quotes, same as previously tested.

Then I restored back to the Ozpost 3.5.2 file - Breaks, but now also no quotes (this was giving me quotes upon reload yesterday, now it doesn't?).

So then I enabled debug and it shows a big message and a broken page:
http://s24.postimg.org/q2uvrnq6t/ozpost_9.jpg

I had seen this type of debug message only once previously. I will paste it below. I appears to do this when I fully wipe the cache in Chrome. When I refresh, the big message is gone from the debug display.


Ok... after more tests I was unable to get the 3.5.2 version to produce any quotes and so I've now reverted the store back to the 3.1.1 Ozpost module because that's the only one that worked and I can't leave the store without any shipping quotes. That works and is live right now.


I'll set up a secondary copy of the site with 3.5.2 on it and if you can tell me how I can configure that to help debug this, I'll do so.

Perhaps I could install some in-between versions of Ozpost on the test site if that would help nail it on a particular release?

Regards
Rob



Debug message mentioned above:
<?xml version='1.0' encoding='ISO-8859-1'?><quotes>
<quote><id>CPL5</id><cost>10.95</cost><days>Tue 12th of Nov</days><description>5kg Satchel</description></quote><quote><id>RPP</id><cost>13.35</cost><days>Wed 13th of Nov</days><description>Parcel up to 2 Kgs cubic weight</description></quote><quote><id>CPLlab</id><cost>15.65</cost><days>Tue 12th of Nov</days><description>Couriers Please Labels: (1 Metro, 2 EZYlink)</description></quote><quote><id>REG</id><cost>16.30</cost><days>Thu 14th of Nov</days><description>Parcel +Signature up to 2 Kgs cubic weight</description></quote><quote><id>PPS5K</id><cost>16.70</cost><days>Wed 13th of Nov</days><description>5kg Satchel</description></quote><quote><id>EBAYBx3</id><cost>17.45</cost><days>Wed 13th of Nov</days><description>Ebay Large box (A3)</description></quote><quote><id>PPS5Kr</id><cost>19.65</cost><days>Wed 13th of Nov</days><description>5kg Satchel +Signature</description></quote><quote><id>EXP</id><cost>21.40</cost><days>Tue 12th of Nov</days><description>Express Parcel up to 2 Kgs cubic weight</description></quote><quote><id>PPSE5K</id><cost>23.60</cost><days>Tue 12th of Nov</days><description>5Kg Express Satchel</description></quote><quote><id>RPPi</id><cost>23.80</cost><days>Thu 14th of Nov</days><description>Insured +Signature Parcel up to 2 Kgs cubic weight</description></quote><quote><id>COD</id><cost>25.10</cost><days>Thu 14th of Nov</days><description>Cash On Delivery </description></quote><quote><id>PPSP5K</id><cost>26.55</cost><days>Tue 12th of Nov</days><description>5kg Express Satchel +Signature</description></quote><quote><id>PPS5Ki</id><cost>27.15</cost><days>Wed 13th of Nov</days><description>5kg Insured Satchel +Signature</description></quote><quote><id>PLT</id><cost>29.25</cost><days>Tue 12th of Nov</days><description>Express Parcel +Signature up to 2 Kgs cubic weight</description></quote><quote><id>PPSP5Ki</id><cost>34.05</cost><days>Wed 13th of Nov</days><description>5kg Insured Express +Signature</description></quote><quote><id>PLTi</id><cost>39.70</cost><days>Tue 12th of Nov</days><description>Insured Express Parcel +Signature up to 2 Kgs cubic weight</description></quote>
<information>
<servername>svr1.ozpost.net</servername>
<serverIP>xxxxxxxxxxxxx</serverIP>
<serververs>02-Sep-2013</serververs>
<timestamp>Sat Nov 09, 2013 17:47 (SA Server Time)</timestamp>
<requesttime>18:17 (NSW Store Time)</requesttime>
<postdate>Mon 11th of Nov</postdate>
<insurance>7.50</insurance>
<surcharge>0.00</surcharge>
<egoinsurance>0.00</egoinsurance>
<stainsurance>0.00</stainsurance>
<cplinsurance>0.00</cplinsurance>
<skpinsurance>0.00</skpinsurance>
<registration>2.95</registration>
<sod>2.95</sod>
<fromsuburb>CAMPERDOWN</fromsuburb>
<destsuburb>MELBOURNE</destsuburb>
<zone>0</zone>
<tnt_response_time>0</tnt_response_time>
<fw_response_time>0</fw_response_time>
<trd_response_time>0</trd_response_time>
<ego_response_time>0</ego_response_time>
<cpl1_response_time>0</cpl1_response_time>
<cpl2_response_time>0.874</cpl2_response_time>
<sms_response_time>0</sms_response_time>
<sta_response_time>0</sta_response_time>
<skp_response_time>0</skp_response_time>
<origstate>NSW</origstate>
<expires>162</expires>
</information>
</quotes>

[robax]

Ok, this started off bad this evening and only went downhill.

I had restored the site to run 3.1.1 of the mod as per previous post, but then it simply refused to give me any quotes.

So then I ripped the whole module out of the site so nothing was left other than the database tables.

Then I randomly picked version 3.4.0 off the downloads page and installed that.

This version seems to work - No page break and it gives me quotes.

Do you think this version is fine to use with ZC 1.5.1?

Regards
Rob

[RodG]

I've reverted to the original 1.5.1 version of tpl_modules_shipping_estimator.php - Note that this did not break the page, but also did not produce quotes.

This is exactly what I expected.

I event went into the DB and looked for the setting.
MODULE_SHIPPING_OZPOST_WEIGHT_FORMAT is set to 'kilos'

NO! Don't do that. This will cause problems, not solve them.

To undo this change, go to the ozpost settings and select Kgs or Gms. You'll find that with the change you made this is no longer set to anything at all, and that's why you aren't getting the quotes.

We did have TNT Road Express enabled before the upgrade, but it was giving really crazy prices right after the upgrade so we disabled it. We'd like to enable that again and probably also try the Couriers Please one that is new in there.

To fix this we need to figure out what is going amiss with the tpl file changes.

I've just spent a few hours going nutty reverting files and retesting. I'm beginning to get inconsistent results and that makes it difficult to tell you exactly what is happening.

You really should have just followed the two steps I gave. Nothing more, nothing less.

I reverted to the 1.5.1 original file - No break but also no quotes, same as previously tested.
Then I restored back to the Ozpost 3.5.2 file - Breaks, but now also no quotes (this was giving me quotes upon reload yesterday, now it doesn't?).

I'll try again. You have TWO problems that are unrelated.

The 'break' problem is due to something amiss with the ozpost tpl file.
The 'no quotes' problem is because the kg/gms setting is getting unset during the upgrade and/or downgrade. This is a known bug, so you must check and reset it from the ozpost config settings whenever you upgrade or downgrade. You do NOT have to do anything with the DB itself.

So then I enabled debug and it shows a big message and a broken page:
http://s24.postimg.org/q2uvrnq6t/ozpost_9.jpg

That is what a 'normal' debug screen should show on the 1st load of the page.

Perhaps I could install some in-between versions of Ozpost on the test site if that would help nail it on a particular release?

The 'no quote' problem is due to the changes made in ozpost v3.5.2. It is just a matter of re-selecting the correct weight format.

The page break problem on first load appears to be due to a change I've made to the tpl file (in either v1.5.1 or v1.5.2). Using the original zencart tpl file will fix this problem.

Those are the only two things you need to know and do in order to get it functional.

After doing this the *only* problem you *may* have is with the courier quotes, and that will be restricted to *some* suburbs only, and the effect will be a message along the lines 'Invalid destination'. The *reason* for this is because the zencart TPL file doesn't have support for the suburb names. Even this won't be a problem for logged in users (because the suburb is then taken from their address book).....

So to repeat. For ozpost v3.5.x do a normal install but use the original zencart tpl file.
Go to the ozpost settings and check that the kg/gms setting is correct (hasn't been unset).

That's it. You shouldn't need to do anything more.

Cheers
Rod

[RodG]

Attachment 13285

I have discovered another issue as well. Please see the attached screenshot. Do you know why the methods are staggered like that? I tried switching back to the default template, but they still looked the same.

Thanks!

I've finally been able to replicate this problem and have found an easy fix.

Load /includes/modules/shipping/ozpost.php into a text editor.
Look for:
--------------------------------------------------------------------
$details = ((float)$handlingFee > 0) ? $details .= "<li>" . MODULE_SHIPPING_OZPOST_HANDLING1_TEXT . $currencies->format((float)$handlingFee / $aus_rate). MODULE_SHIPPING_OZPOST_HANDLING2_TEXT ."</li>": $details ;

$details = ((float)$serviceFee > 0) ? $details .= "<li>" . MODULE_SHIPPING_OZPOST_HANDLING1_TEXT . $currencies->format((float)$serviceFee / $aus_rate). " charges.</li>" : $details ;
$details .= "&nbsp;&nbsp;&nbsp;</ul></div>" ;
}

// store it //
---------------------------------------------------------------------

Change to:
---------------------------------------------------------------------
$details = ((float)$handlingFee > 0) ? $details .= "<li>" . MODULE_SHIPPING_OZPOST_HANDLING1_TEXT . $currencies->format((float)$handlingFee / $aus_rate). MODULE_SHIPPING_OZPOST_HANDLING2_TEXT ."</li>": $details ;

$details = ((float)$serviceFee > 0) ? $details .= "<li>" . MODULE_SHIPPING_OZPOST_HANDLING1_TEXT . $currencies->format((float)$serviceFee / $aus_rate). " charges.</li>" : $details ;
}
$details .= "&nbsp;&nbsp;&nbsp;</ul></div>" ;

// store it //
---------------------------------------------------------------------

This should be somewhere around line#2300

The change is just a matter of moving the "}" so that it is ABOVE the
line that reads $details .= "&nbsp;&nbsp;&nbsp;</ul></div>" ;

Save the file.
No other changes needed.

Cheers
Rod