ozpost shipping module

[Mike_Dean]

Hi Rod,

Long time between correspondence.


I've just updated my test site (ZC 1.3.9D) with OzPost 3.4.1 and confirmed it was working as it should be. I tried the BETA 3.5 and I lose the shipping estimator, such as I see no rates or shipping options after adding items.

Have you seen this error in your initial tests ?

Turing on debugging and error messages didn't offer up any clues.

I'm about to do a full clean install to ZC 1.5.1 and see what happens.

Thanks,
Mike

[RodG]

Long time between correspondence.

Yeah. *Ages*.

I've just updated my test site (ZC 1.3.9D) with OzPost 3.4.1 and confirmed it was working as it should be. I tried the BETA 3.5 and I lose the shipping estimator, such as I see no rates or shipping options after adding items.

Have you seen this error in your initial tests ?

I've not seen or experienced it for myself, but the problem appears because the /cache/ folder is unwritable.

I think the deeper issue is that the 'define' path isn't set when I'm trying to use it. The end result is the same. The installer isn't able to write its files to the cache folder, leaving an incomplete install.

The ozpost module gets the folder name from the 'DIR_FS_SQL_CACHE' constant (in the configure.php files)

That should fix the problem.

Cheers
Rod

ps. latest beta is v3.5.0f

[Mike_Dean]

Hi Rod,

Thanks for replying and apologies for my delay in showing appreciation.
Not long after starting my upgrade process my pc fritzed itself and I'm just back to where I started with test sites etc.

I've now got my 1.3.9d site and also a clean 1.5.1 site locally.

My plan is to get your latest version of ozpost (hopefully 3.5.0f) working on my 1.3.9d and publish that update to my live site and then start on a brand new site, new look etc....


Soooooo back to the original issue with losing the shipping estimator on 1.3.9d when trialling 3.5.0f.

Am I reading correct that if I change the permission of the cache file, that should resolve the issue ? or did I miss something in the translation ? :-)

Thanks,
Mike

[Mike_Dean]

Update...


Installed 3.4.1 on ZC 1.3.9d and it worked fine.
Uploaded the ozpost.php file for 3.5.0f and I lose the shipping estimator


On a clean 1.5.1, initially installed OZ 3.4.1, checked, all good. Uploaded the 3.5.0f ozpost.php file, removed and re-installed via Admin and Viola, all good..
Its returning rates via the shipping estimator and I can complete the order process.

Mike

[Mike_Dean]

And some more info to dwell on.

I should have made mention of this error when I do the remove/install via Admin on 1.3.9d with 3.5.0f installed

Warning The file (C:/wamp/www/zencart139/admin/includes/languages/english/product.php) has already been modified. This alert can be ignored
Warning The file (C:/wamp/www/zencart139/admin/includes/modules/update_product.php) has already been modified. This alert can be ignored
Warning The file (C:/wamp/www/zencart139/admin/includes/modules/product/collect_info.php) has already been modified. This alert can be ignored

Success Ozpost v3.5.0f Installation successful.
You will need to modify the settings and press UPDATE to complete.

I neglected to mention it, as the last part This alert can be ignored had me doing just that.. But perhaps its pertinent as the same error warning is not thrown up on ZC 1.5.1 using OZ 3.5.0f

[RodG]

And some more info to dwell on.
Warning The file (C:/wamp/www/zencart139/admin/includes/languages/english/product.php) has already been modified. This alert can be ignored
< snip>
I neglected to mention it, as the last part This alert can be ignored had me doing just that.. But perhaps its pertinent as the same error warning is not thrown up on ZC 1.5.1 using OZ 3.5.0f

Do you remember way back in the distant past when you 1st installed the ozpost module? You were required to ether edit or replace some files in the /admin/ folder? Well. the newer code doesn't require the user to do this because the installation code does this automatically.

So, what this warning/alert is telling us is that those files have already been modified from one of the earlier installations and don't need to be modified again.

Success Ozpost v3.5.0f Installation successful.

If you get to see this message you can be pretty confident that you have a good/working installation.

Cheers
Rod

[Mike_Dean]

Hi Rod,

I think I have sorted it..

I went through and manually removed all files that were affected by the ozpost module, replaced them with the original core files, then installed 3.4.0 and let it upgrade the db to 3.4.1.

Confirmed all was ok, then planted the ozpost.php file from 3.5.0f and its seems to be working (kinda)

A couple of points, not sure if this one is a feature or a bug ?

1. If I enter a postcode, wait a few seconds and then from the presented list, click on one, a rate is returned, all good. But if I hover my mouse back over the country code, or postcode selector area, it clears the rates that were returned and re-presents the available suburbs for the entered postcode, and I can lather rinse and repeat the process over and over...

Tried it on both Firefox and IE and the same result.

2. There is no boarder around the rates, is that intentional or has my css screwed up ?

Loving it so far (apart from above 2 points.!)

Thanks,
Mike

[RodG]

I went through and manually removed all files that were affected by the ozpost module, replaced them with the original core files, then installed 3.4.0 and let it upgrade the db to 3.4.1.

That'll get rid of the "alerts" for good (mostly). There wasn't a *need* to do what you did, but it is/was a good thing to do.

Confirmed all was ok, then planted the ozpost.php file from 3.5.0f and its seems to be working (kinda).

Oooeerrrr... 'kinda' implies a problem has been found <g>

A couple of points, not sure if this one is a feature or a bug ?.

A feature, definitely a feature.

1. If I enter a postcode, wait a few seconds and then from the presented list, click on one, a rate is returned, all good. But if I hover my mouse back over the country code, or postcode selector area, it clears the rates that were returned and re-presents the available suburbs for the entered postcode, and I can lather rinse and repeat the process over and over...

Tried it on both Firefox and IE and the same result.

That is to provide a means for the customer to select a different suburb in case they make an accidental choice, for example, North Adelaide vs West Adelaide.
If the same suburb is selected the screen should instantly redraw using the previously retrieved data.
If the same suburb is selected 3 times it 'locks' that suburb in, until the postcode is changed.

2. There is no boarder around the rates, is that intentional or has my css screwed up ?

That'll be a CSS issue (probably related to the 'table' displays).

Loving it so far (apart from above 2 points.!)

Thanks. I'm looking forward to making this one available for the masses. I've gone back over my notes, and unless I'm mistaken, this current update supports just about every feature ever asked for (where possible). :)

Cheers
Rod

[Mike_Dean]

Hi Rod,

Help if I may ask for it !

I want to remove the following from the shipping estimator

(1.21 Kgs) CANTON BEACH 2263

and replace it with

Delivery to:

Reason, I often drop ship so its probably better off not having this showing;

I edited the tpl_modules_shipping_estimator.php file at line to the following: Its probably a crude way to do it, but it works. is there a better way ?

Perhaps its a feature/option that can be added to the admin side of it ?


//if(isset($_SESSION['parcelweight'])) echo "(".$_SESSION['parcelweight']. " Kgs) " ;

// echo MODULE_SHIPPING_OZPOST_ORIGIN_SUBURB . " " . MODULE_SHIPPING_OZPOST_ORIGIN_ZIP . " to " ;

echo " Delivery To " ;

I commented out the second line above, in case I decide to put it back, at least then its just a matter of un-commenting the line..

Thanks,
Mike

[RodG]

I edited the tpl_modules_shipping_estimator.php file at line to the following: Its probably a crude way to do it, but it works. is there a better way ?

The way you did it was the correct approach. There isn't a better way, at least not at the moment.

Cheers
Rod