ozpost shipping module

wakeleymb:

You are correct in saying I can view existing products with dimensions in them. I haven't tried to edit them in case hey get overwritten, but I guess if it was saving the data to the tables, we wouldn't be having this problem. :D
I'm guessing that if you did try to edit them it would have no effect. The changes won't be apploed, and the existing data wouldn't be zeroed out.

wakeleymb:

Dangerous goods field DOES exist.

Good news at last. This is suggesting that it is only the one file (update_products.php) that isn't being filly patched.

wakeleymb:

I will modify the file with what you have given me and provide a report shortly.

If you haven't done this already, I suspect that if you uninstall ozpost (via the admin screen) then replace your update_product.php file with a Zencart original and try the installation again then the correct patching/update will take place.

If this is the case, it will confirm my suspicion that this files has been modified by something else at some stage and that is what is causing the failure.

If this suspicion is correct I will somehow need to figure out what those changes were so that I can take them into account with the next update.

Hhhhm... lots of guessing and 'if's" going on here.

I appreciate your help and feedback in this matter.

Cheers
RodG

Hi Rodg
pls remember that we had your add-on installed by some one else I have checked the files as you asked and the following is my findings

/YOURADMIN/includes/modules/product/collect_info.php_ozpRestore this does not exist in fact the folder called product is not there either.

/YOURADMIN/includes/languages/english.php_ozpRestore this one does exist

Does the FOLDER /cache/ozpost/ exist? not there

YOURADMIN/includes/modules/update_product.php no such file

as I said I didn't install it

regards
john

Catching Angels:

pls remember that we had your add-on installed by some one else

I'm an old man. My memory isn't what it used to be <g>

Catching Angels:

I have checked the files as you asked and the following is my findings

/YOURADMIN/includes/modules/product/collect_info.php_ozpRestore this does not exist in fact the folder called product is not there either.

OK, I can understand the ozpRestore file not existing, but how the heck does your store function without the /product/ folder???????

Catching Angels:

YOURADMIN/includes/modules/update_product.php no such file

This can't be right either. Hmm, This could be explained if you are looking specifically for "YOURADMIN" rather than the actual name of your admin folder (which mustn't be revealed).

Either way, since it seems that you probably aren't up to making code changes, and that a definitive solution hasn't been found yet, you can either wait until a solution has been found and a new update made available OR for a more speedy fix please go to
http://shop.vcsweb.com/index.php?mai...roducts_id=219 and fill in the order details. Select Cheque or money order as your payment method, but DO NOT PAY. I will head over to your site and fix the issue for you (and this will also aid me in identifying exactly where things are going wrong so that I can provide a proper fix for the few others that are now reporting the same problem).

Cheers
RodG

Those lines you typed out don't exist. I've cut and pasted the UPDATE_PRODUCT.PHP file for you to have a look at. I'm going to insert the code and see what happens.

<?php /** * @package admin * @copyright Copyright 2003-2010 Zen Cart Development Team * @copyright Portions Copyright 2003 osCommerce * @license <http://www.zen-cart.com/license/2_0.txt> GNU Public License V2.0 * @version $Id: update_product.php 15636 2010-03-07 07:00:40Z drbyte $ */ if (!defined('IS_ADMIN_FLAG')) { die('Illegal Access'); } if (isset($_GET['pID'])) $products_id = zen_db_prepare_input($_GET['pID']); if (isset($_POST['edit_x']) || isset($_POST['edit_y'])) { $action = 'new_product'; } elseif ($_POST['products_model'] . $_POST['products_url'] . $_POST['products_name'] . $_POST['products_description'] != '') { $products_date_available = zen_db_prepare_input($_POST['products_date_available']); $products_date_available = (date('Y-m-d') < $products_date_available) ? $products_date_available : 'null'; // Data-cleaning to prevent MySQL5 data-type mismatch errors: $tmp_value = zen_db_prepare_input($_POST['products_quantity']); $products_quantity = (!zen_not_null($tmp_value) || $tmp_value=='' || $tmp_value == 0) ? 0 : $tmp_value; $tmp_value = zen_db_prepare_input($_POST['products_price']); $products_price = (!zen_not_null($tmp_value) || $tmp_value=='' || $tmp_value == 0) ? 0 : $tmp_value; $tmp_value = zen_db_prepare_input($_POST['products_weight']); $products_weight = (!zen_not_null($tmp_value) || $tmp_value=='' || $tmp_value == 0) ? 0 : $tmp_value; $dangerous_goods = (($_POST['dangerous_goods']) == 1) ? 1:0; $tmp_value = zen_db_prepare_input($_POST['manufacturers_id']); $manufacturers_id = (!zen_not_null($tmp_value) || $tmp_value=='' || $tmp_value == 0) ? 0 : $tmp_value; $sql_data_array = array('products_quantity' => $products_quantity, 'products_type' => zen_db_prepare_input($_GET['product_type']), 'products_model' => zen_db_prepare_input($_POST['products_model']), 'products_price' => $products_price, 'products_date_available' => $products_date_available, 'products_weight' => $products_weight, 'products_height' => $products_height, 'products_width' => $products_width, 'products_length' => $products_length, 'dangerous_goods' => $dangerous_goods, 'products_status' => zen_db_prepare_input((int)$_POST['products_status']), 'products_virtual' => zen_db_prepare_input((int)$_POST['products_virtual']), 'products_tax_class_id' => zen_db_prepare_input((int)$_POST['products_tax_class_id']), 'manufacturers_id' => $manufacturers_id, 'products_quantity_order_min' => zen_db_prepare_input($_POST['products_quantity_order_min']), 'products_quantity_order_units' => zen_db_prepare_input($_POST['products_quantity_order_units']), 'products_priced_by_attribute' => zen_db_prepare_input($_POST['products_priced_by_attribute']), 'product_is_free' => zen_db_prepare_input((int)$_POST['product_is_free']), 'product_is_call' => zen_db_prepare_input((int)$_POST['product_is_call']), 'products_quantity_mixed' => zen_db_prepare_input($_POST['products_quantity_mixed']), 'product_is_always_free_shipping' => zen_db_prepare_input((int)$_POST['product_is_always_free_shipping']), 'products_qty_box_status' => zen_db_prepare_input($_POST['products_qty_box_status']), 'products_quantity_order_max' => zen_db_prepare_input($_POST['products_quantity_order_max']), 'products_sort_order' => (int)zen_db_prepare_input($_POST['products_sort_order']), 'products_discount_type' => zen_db_prepare_input($_POST['products_discount_type']), 'products_discount_type_from' => zen_db_prepare_input($_POST['products_discount_type_from']), 'products_price_sorter' => zen_db_prepare_input($_POST['products_price_sorter']) ); // when set to none remove from database // is out dated for browsers use radio only $sql_data_array['products_image'] = zen_db_prepare_input($_POST['products_image']); $new_image= 'true'; if ($_POST['image_delete'] == 1) { $sql_data_array['products_image'] = ''; $new_image= 'false'; } if ($_POST['image_delete'] == 1) { $sql_data_array['products_image'] = ''; $new_image= 'false'; } if ($action == 'insert_product') { $insert_sql_data = array( 'products_date_added' => 'now()', 'master_categories_id' => (int)$current_category_id); $sql_data_array = array_merge($sql_data_array, $insert_sql_data); zen_db_perform(TABLE_PRODUCTS, $sql_data_array); $products_id = zen_db_insert_id(); // reset products_price_sorter for searches etc. zen_update_products_price_sorter($products_id); $db->Execute("insert into " . TABLE_PRODUCTS_TO_CATEGORIES . " (products_id, categories_id) values ('" . (int)$products_id . "', '" . (int)$current_category_id . "')"); /////////////////////////////////////////////////////// //// INSERT PRODUCT-TYPE-SPECIFIC *INSERTS* HERE ////// //// *END OF PRODUCT-TYPE-SPECIFIC INSERTS* //////// /////////////////////////////////////////////////////// } elseif ($action == 'update_product') { $update_sql_data = array( 'products_last_modified' => 'now()', 'master_categories_id' => ($_POST['master_category'] > 0 ? zen_db_prepare_input($_POST['master_category']) : zen_db_prepare_input($_POST['master_categories_id']))); $sql_data_array = array_merge($sql_data_array, $update_sql_data); zen_db_perform(TABLE_PRODUCTS, $sql_data_array, 'update', "products_id = '" . (int)$products_id . "'"); // reset products_price_sorter for searches etc. zen_update_products_price_sorter((int)$products_id); /////////////////////////////////////////////////////// //// INSERT PRODUCT-TYPE-SPECIFIC *UPDATES* HERE ////// //// *END OF PRODUCT-TYPE-SPECIFIC UPDATES* //////// /////////////////////////////////////////////////////// } $languages = zen_get_languages(); for ($i=0, $n=sizeof($languages); $i<$n; $i++) { $language_id = $languages[$i]['id']; $sql_data_array = array('products_name' => zen_db_prepare_input($_POST['products_name'][$language_id]), 'products_description' => zen_db_prepare_input($_POST['products_description'][$language_id]), 'products_url' => zen_db_prepare_input($_POST['products_url'][$language_id])); if ($action == 'insert_product') { $insert_sql_data = array('products_id' => $products_id, 'language_id' => $language_id); $sql_data_array = array_merge($sql_data_array, $insert_sql_data); zen_db_perform(TABLE_PRODUCTS_DESCRIPTION, $sql_data_array); } elseif ($action == 'update_product') { zen_db_perform(TABLE_PRODUCTS_DESCRIPTION, $sql_data_array, 'update', "products_id = '" . (int)$products_id . "' and language_id = '" . (int)$language_id . "'"); } } // add meta tags $languages = zen_get_languages(); for ($i=0, $n=sizeof($languages); $i<$n; $i++) { $language_id = $languages[$i]['id']; $sql_data_array = array('metatags_title' => zen_db_prepare_input($_POST['metatags_title'][$language_id]), 'metatags_keywords' => zen_db_prepare_input($_POST['metatags_keywords'][$language_id]), 'metatags_description' => zen_db_prepare_input($_POST['metatags_description'][$language_id])); if ($action == 'insert_product_meta_tags') { $insert_sql_data = array('products_id' => $products_id, 'language_id' => $language_id); $sql_data_array = array_merge($sql_data_array, $insert_sql_data); zen_db_perform(TABLE_META_TAGS_PRODUCTS_DESCRIPTION, $sql_data_array); } elseif ($action == 'update_product_meta_tags') { zen_db_perform(TABLE_META_TAGS_PRODUCTS_DESCRIPTION, $sql_data_array, 'update', "products_id = '" . (int)$products_id . "' and language_id = '" . (int)$language_id . "'"); } } // future image handler code define('IMAGE_MANAGER_HANDLER', 0); define('DIR_IMAGEMAGICK', ''); if ($new_image == 'true' and IMAGE_MANAGER_HANDLER >= 1) { $src= DIR_FS_CATALOG . DIR_WS_IMAGES . zen_get_products_image((int)$products_id); $filename_small= $src; preg_match("/.*\/(.*)\.(\w*)$/", $src, $fname); list($oiwidth, $oiheight, $oitype) = getimagesize($src); $small_width= SMALL_IMAGE_WIDTH; $small_height= SMALL_IMAGE_HEIGHT; $medium_width= MEDIUM_IMAGE_WIDTH; $medium_height= MEDIUM_IMAGE_HEIGHT; $large_width= LARGE_IMAGE_WIDTH; $large_height= LARGE_IMAGE_HEIGHT; $k = max($oiheight / $small_height, $oiwidth / $small_width); //use smallest size $small_width = round($oiwidth / $k); $small_height = round($oiheight / $k); $k = max($oiheight / $medium_height, $oiwidth / $medium_width); //use smallest size $medium_width = round($oiwidth / $k); $medium_height = round($oiheight / $k); $large_width= $oiwidth; $large_height= $oiheight; $products_image = zen_get_products_image((int)$products_id); $products_image_extension = substr($products_image, strrpos($products_image, '.')); $products_image_base = preg_replace('/'.$products_image_extension.'/', '', $products_image); $filename_medium = DIR_FS_CATALOG . DIR_WS_IMAGES . 'medium/' . $products_image_base . IMAGE_SUFFIX_MEDIUM . '.' . $fname[2]; $filename_large = DIR_FS_CATALOG . DIR_WS_IMAGES . 'large/' . $products_image_base . IMAGE_SUFFIX_LARGE . '.' . $fname[2]; // ImageMagick if (IMAGE_MANAGER_HANDLER == '1') { copy($src, $filename_large); copy($src, $filename_medium); exec(DIR_IMAGEMAGICK . "mogrify -geometry " . $large_width . " " . $filename_large); exec(DIR_IMAGEMAGICK . "mogrify -geometry " . $medium_width . " " . $filename_medium); exec(DIR_IMAGEMAGICK . "mogrify -geometry " . $small_width . " " . $filename_small); } } zen_redirect(zen_href_link(FILENAME_CATEGORIES, 'cPath=' . $cPath . '&pID=' . $products_id . (isset($_GET['page']) ? '&page=' . $_GET['page'] : '') . (isset($_POST['search']) ? '&search=' . $_POST['search'] : '') )); } else { $messageStack->add_session(ERROR_NO_DATA_TO_SAVE, 'error'); zen_redirect(zen_href_link(FILENAME_CATEGORIES, 'cPath=' . $cPath . '&pID=' . $products_id . (isset($_GET['page']) ? '&page=' . $_GET['page'] : '') . (isset($_POST['search']) ? '&search=' . $_POST['search'] : '') )); }

COLLECT_INFO.PHP does not have those lines either. Will be inserting them now.

I tried to manually enter those lines of code in and when i try to go in and edit an existing product, it just gives me a blank screen. (Collect_Info.PHP). So i removed the code.

Then when I try to complete an edited product, I get a WEBPAGE EXPIRED message in Explorer. So I'm going to redownload the ZenCart and replace the UPDATE_PRODUCT.PHP, remove OzPost and reinstall and see how that goes.

wakeleymb:

Those lines you typed out don't exist. I've cut and pasted the UPDATE_PRODUCT.PHP file for you to have a look at.

Thanks for that. The cut n paste shows that some of the needed lines have been added, but not all of them.

These are the ones that are missing. I shall use what you have supplied to try to figure out why it is failing.

$tmp_value = zen_db_prepare_input($_POST['products_height']); $products_height = (!zen_not_null($tmp_value) || $tmp_value=='' || $tmp_value == 0) ? 0 : $tmp_value; $tmp_value = zen_db_prepare_input($_POST['products_width']); $products_width = (!zen_not_null($tmp_value) || $tmp_value=='' || $tmp_value == 0) ? 0 : $tmp_value; $tmp_value = zen_db_prepare_input($_POST['products_length']); $products_length = (!zen_not_null($tmp_value) || $tmp_value=='' || $tmp_value == 0) ? 0 : $tmp_value; $dangerous_goods = (($_POST['dangerous_goods']) == 1) ? 1:0 ;

wakeleymb:

COLLECT_INFO.PHP does not have those lines either. Will be inserting them now.

Are you sure about that? If those lines are missing I don't think it would be able to obtain the dimensions from existing products, which is contrary to your previous report???

Cheers
RodG

wakeleymb:

I tried to manually enter those lines of code in and when i try to go in and edit an existing product, it just gives me a blank screen. (Collect_Info.PHP). So i removed the code.

Based on your previous feedback, the collect_info.php file didn't need any further modification, so if you somehow managed to duplicate what was already there the blank screen results don't come as much of a surprise.

In short, I think (I'm sure) that you've taken a step backwards by doing this. :(

wakeleymb:

Then when I try to complete an edited product, I get a WEBPAGE EXPIRED message in Explorer.

Now you are really confusing me. If the changes you made to the collect_info.php causes a blank screen, then how can you try to 'complete an edited product'?

wakeleymb:

So I'm going to redownload the ZenCart and replace the UPDATE_PRODUCT.PHP, remove OzPost and reinstall and see how that goes.

Alert: Order is important. You must remove/uninstall ozpost via the admin menu BEFORE replacing the update_product.php file. If you do it in reverse order, the ozpost uninstaller will replace the newly copied file with its own backup file so when you re-install ozpost again it will be trying to update the same file that it is already having troubles with (not your newly copied file, which will be simply deleted).

You can negate this behaviour by deleting the ozpRestore files before uninstalling/re-installing ozpost itself. If ozpost can't find its backup files it will leave whatever files that do exist alone, regardless of whether they are ZenCart originals or something that has been modified by another add-on.

I can appreciate that all of this may appear convoluted, because it is, but the purpose of doing it this way is so that the ozpost module can install or remove itself without affecting any changes made by other modules and to avoid the need for any manual merging. Until this latest update the system has worked well.

I could supply you with ozpost modified files to replace your existing ones and the ozpost problem will be solved, but in doing so, if your existing files have already been modified by something else, it will break whatever that 'something else' was.

It is this 'something else' that I need to determine and account for.

Cheers
RodG

wakeleymb:

I've cut and pasted the UPDATE_PRODUCT.PHP file for you to have a look at.

Problem solvered (He says cautiously).

An update has been uploaded to the ozpost servers and is currently available via the auto-updater.

I'll be creating a new .zip distribution and uploading it to ZenCart in the next day or two (assuming the problem is confirmed to be fixed).

Cheers
RodG

tried to manually enter those lines of code in and when i try to go in and edit an existing product, it just gives me a blank screen. (Collect_Info.PHP). So i removed the code.
Based on your previous feedback, the collect_info.php file didn't need any further modification, so if you somehow managed to duplicate what was already there the blank screen results don't come as much of a surprise.

In short, I think (I'm sure) that you've taken a step backwards by doing this.

I used ftp and viewed the file, I tried to search for a string that you had typed up and nothing came up matching the results.

Then when I try to complete an edited product, I get a WEBPAGE EXPIRED message in Explorer.

This is after I removed the code from collect_info.php with code still in update_product.php. I would have cut and pasted the file but it was too long for the board (collect_info.php). I can e-mail you if you'd like.

I have no other mods to the update_product.php file except for autotweet and imagemagick I believe.

Problem solved with the update!!! I kept a log of what it says for you.

Thanks Rod.

---

The ozpost shipping module has been updated. Please check your settings.

Your previously installed module has been saved as ozpost355

$Id: ozpost.php,V3.5.5 Mar 9th 2014

Tweaked output formatting

Updated tpl_modules_ahipping_estimator.php file

Added email field for where to send subscription reminders

Added session variable to minimise server requests for latest version info

$Id: ozpost.php,V3.5.6 Apr 15th 2014

Removed backslash from update code (creates errors with older versions of PHP)

Fixed issue with the update_products.php not being correctly patched with all installations.

Ozpost v3.5.6 Upgrade successful.

The ozpost module has been updated. Please CHECK YOUR SETTINGS and click the UPDATE button at the bottom of this page.

---

Database and file versions differ (3.5.5 / 3.5.6)

wakeleymb:

Database and file versions differ (3.5.5 / 3.5.6)

I'm still struggling with the DB/File discrepancy issue. Simply pressing the button once or twice will take care of this for you though.

Thanks for the feedback.

Cheers
RodG

hi rodg

I have done as you asked the website is as yet not live it is in a folder call catcing -new

regards John

Hi,
Sorry if this is the wrong thread to post this in ...

I've been playing with free shipping for a new site and have encountered a couple of problems (which I think I've now solved).
I need to offer free shipping for certain products only and only to certain areas (in this case Australia). Setting them as "Free Shipping" does the trick, but only locally. If I want to be able to send them O/S but charge postage then I want the ozpost module to kick in and work it out.
What I found is that if I ONLY select free shipping products then the ozpost module is never even run.
If I have a mixture of free and paid shipping products then it is and works things out correctly for the free zone (AUS).
If I have a mixture and want to send O/S ozpost still considers the free ones to be free and ignores them.

I've figured out where the ozpost module is disabled when ALL products are free (includes/functions/functions_general.php) and tweaked that so that other modules are no longer disabled when all products are free.

The next step is to make ozpost include the free products when the destination is not in the free zone.
By inserting a bit of code from the freeshipper module that does its zone checking into ozpost and adding an extra condition to the free shipping check I believe it has the desired result (testing seems to give the right sort of output).

Now the ozpost module kicks in no matter what and gives a cost for O/S postage for every product, even if it's set to free locally. It ignores locally free products and gives a cost for charged ones and still doesn't show up at all if ALL products are fee and sent locally.
It's not perfect in that I want to give slightly discounted international post for the locally free items, but I can do that by manipulating their weights (it'll end up close enough).

I'm not sure if this is a modification you'd want to include, Rod, (especially as it also requires modifying another file outside ozpost) but it's a possible idea to add to the list (you're probably sick of me wanting changes after I beat you over the head for weeks with the SkippyPost bit :wink:). Even if it's not something to be included, it might help someone else or maybe somebody can come up with a better or more comprehensive solution.

Here's what I added to ozpost.php (around line 546)

		if ((int)MODULE_SHIPPING_FREESHIPPER_ZONE > 0) {
			$check_flag = true;
			$check = $db->Execute("select zone_id from " . TABLE_ZONES_TO_GEO_ZONES . " where geo_zone_id = '" . MODULE_SHIPPING_FREESHIPPER_ZONE . "' and zone_country_id = '" . $order->delivery['country']['id'] . "' order by zone_id");
			while (!$check->EOF) {
			  if ($check->fields['zone_id'] < 1) {
				$check_flag = false;
				break;
			  } elseif ($check->fields['zone_id'] == $order->delivery['zone_id']) {
				$check_flag = false;
				break;
			  }
			  $check->MoveNext();
			}
		}

        if ((($type->fields['product_is_always_free_shipping'] == 0) && ($type->fields['products_virtual'] == 0)) || $check_flag) {

EvoCivic:

Setting them as "Free Shipping" does the trick, but only locally. If I want to be able to send them O/S but charge postage then I want the ozpost module to kick in and work it out.
What I found is that if I ONLY select free shipping products then the ozpost module is never even run.

This is normal/expected behaviour. No point in ozpost (or any other shipping module) doing all the processing if the shipping is free anyway.

EvoCivic:

If I have a mixture of free and paid shipping products then it is and works things out correctly for the free zone (AUS).
If I have a mixture and want to send O/S ozpost still considers the free ones to be free and ignores them.

Free is Free. Ozpost is designed to ignore products with free postage.

EvoCivic:

I've figured out where the ozpost module is disabled when ALL products are free (includes/functions/functions_general.php) and tweaked that so that other modules are no longer disabled when all products are free.

Ok, this places you one step ahead of me.

EvoCivic:

The next step is to make ozpost include the free products when the destination is not in the free zone.

OK, I suspect this will need custom coding coding somewhere or other.

EvoCivic:

By inserting a bit of code from the freeshipper module that does its zone checking into ozpost and adding an extra condition to the free shipping check I believe it has the desired result (testing seems to give the right sort of output).

Ok...

EvoCivic:

Now the ozpost module kicks in no matter what and gives a cost for O/S postage for every product, even if it's set to free locally. It ignores locally free products and gives a cost for charged ones and still doesn't show up at all if ALL products are fee and sent locally.

OK....

EvoCivic:

It's not perfect in that I want to give slightly discounted international post for the locally free items, but I can do that by manipulating their weights (it'll end up close enough).

This goes against the principles on which the ozpost module is based. The product weights entered need to be the exact weight of the actual products. If you wish to make adjustments to the quotes you should do so using the 'handling fee' settings. Negative values are allowed to provide this functionality.

EvoCivic:

I'm not sure if this is a modification you'd want to include, Rod,

No. It isn't. In fact at the very early design stage of the ozpost module I opted to ignore the 'zone' settings on the basis that for shippng/quote purposes only two zones are needed for australian merchants, namely, Australia and Overseas. It is true that ozzies may/will require the use of the zones settings when using other shipping modules (unless they plan to use a static rate Australia Wide), but the ozpost module correctly calculates the rates to different states and countries with needing the State/Country zones configured.

Although what you are wanting to do is perfectly correct/valid, it isn't something most Aussie merchants will ever need. The main reason I removed the zone related code from the ozpost module (besides not being needed by most) is because when it was included it resulted in an endless number of support questions from people that either didn't set them up correctly in the 1st place ("Why aren't I getting quotes for destination WA" ) or simply didn't have a clue what a 'shipping zone' meant in relation to the way the ozpost module functioned, which left me with a lot of trying to explain why even though the setting existed, it wasn't actually needed (for most).

You are actually the 1st and only person that has 'discovered' (or at least reported) that ozpost is about the only shipping module that is 'lacking' in this regard.

I'm not saying that this negates your needs in any way, its just that your needs are too 'unique' to consider (re)adding the code that results in more support questions for me, and more confusion for the majority of users.

EvoCivic:

(especially as it also requires modifying another file outside ozpost)

Doubly so when it involves the functions_general.php file, which tends to get modified by a lot of other addons as well.

EvoCivic:

but it's a possible idea to add to the list (you're probably sick of me wanting changes after I beat you over the head for weeks with the SkippyPost bit :wink:). Even if it's not something to be included, it might help someone else or maybe somebody can come up with a better or more comprehensive solution.

As you should probably know, I do take all suggestions to improve or enhance the ozpost system seriously, but this is one case where I feel that the changes suggested is not in the best interests of the majority.

Having said that, it is quite possible that I'm actually missing some important point here. If you can see what that may be could you please follow this up in email.

Cheers
RodG

SERVER ISSUES APRIL 25th -> current

One of our hosts decided to migrate us over to a new server. This was planned to take effect from 25apr and was expected to take a day or two to complete. We were told, and were expecting, zero downtime, especially as this was one of the backup servers being moved.

Alas, this also turned out to be the same server that holds all of our DNS records, and it now appears that many of these records were changed or reset to ‘default’ values either during, or as part of this migration. This is having devastating effects on all sites that use our nameservers, including many (but not all) of our own sites.

As a result, two of the three ozpost quotation servers are now offline. We’ve no estimated time for how long this issue will persist, but we have taken steps to redelegate all servers to point to the server that remains in operation, and the effect of these changes will/should come into effect within the next 24hours (less for many people).

We hope/expect to be back to full functionality within a few days, but at the moment we are at the mercy of the host performing the migration.

Regards
RodG

RodG:

This is normal/expected behaviour. No point in ozpost (or any other shipping module) doing all the processing if the shipping is free anyway.

This goes against the principles on which the ozpost module is based. The product weights entered need to be the exact weight of the actual products. If you wish to make adjustments to the quotes you should do so using the 'handling fee' settings. Negative values are allowed to provide this functionality.

No. It isn't. In fact at the very early design stage of the ozpost module I opted to ignore the 'zone' settings on the basis that for shippng/quote purposes only two zones are needed for australian merchants, namely, Australia and Overseas. It is true that ozzies may/will require the use of the zones settings when using other shipping modules (unless they plan to use a static rate Australia Wide), but the ozpost module correctly calculates the rates to different states and countries with needing the State/Country zones configured.

Although what you are wanting to do is perfectly correct/valid, it isn't something most Aussie merchants will ever need. The main reason I removed the zone related code from the ozpost module (besides not being needed by most) is because when it was included it resulted in an endless number of support questions from people that either didn't set them up correctly in the 1st place ("Why aren't I getting quotes for destination WA" ) or simply didn't have a clue what a 'shipping zone' meant in relation to the way the ozpost module functioned, which left me with a lot of trying to explain why even though the setting existed, it wasn't actually needed (for most).

You are actually the 1st and only person that has 'discovered' (or at least reported) that ozpost is about the only shipping module that is 'lacking' in this regard.

I'm not saying that this negates your needs in any way, its just that your needs are too 'unique' to consider (re)adding the code that results in more support questions for me, and more confusion for the majority of users.

Doubly so when it involves the functions_general.php file, which tends to get modified by a lot of other addons as well.

As you should probably know, I do take all suggestions to improve or enhance the ozpost system seriously, but this is one case where I feel that the changes suggested is not in the best interests of the majority.

Having said that, it is quite possible that I'm actually missing some important point here. If you can see what that may be could you please follow this up in email.

Cheers
RodG

All perfectly reasonable.

As far as using the handling fee to give a discounted price, in this particular case it won't work as that will affect ALL O/S calculations, whereas I only want to discount particular products (the ones that are locally free).

I fully understand your reluctance to include anything to do with zones as it took me some time to figure out how they work (seems to be a very American-centric sort of thing with a highly un-intuitive interface) and it does not surprise me in the slightest that it confuses a lot of people.

The whole thing is a bit of a hack and it was the simplest way I could think of to make it do roughly what I want. It probably is a situation that is rarely likely to crop up again. Until I can find the time to think up a better solution I'll run with my slightly modified version of ozpost (I just have to remember to re-modify any upgrades).
You can blame my wife for this as it's her shop and it was her idea to sell some things with free Australian postage...

Hi Rod,
We are getting a warning message saying
E-go : The calculator API has been updated on Monday 19th May. Please see details on http://www.e-go.com.au/infopage.do?page
Do we just need to update the ozpost version to fix this?

vandiermen:

We are getting a warning message saying
E-go : The calculator API has been updated on Monday 19th May. Please see details on http://www.e-go.com.au/infopage.do?page
Do we just need to update the ozpost version to fix this?

I love the way these companies just spring these changes without advance warning (not).

No, you'll not need to update the ozpost client code to resolve this. I'll be doing it server side later this evening.

Having said that though, I had also planned to release another ozpost module for zencart this evening anyway (but I'll be holding off on this in case eGo have introduced any new methods).

It seems that this is the month of many changes. Australia Post have separated themselves from the 'Ebay' offerings and introduced some new Click n Send methods, and Transdirect have made some significant changes to their API, as well as adding some new methods and dropping others. The server changes for these have already been made, and the client code has been updated to reflect the changed methods. IOW, even though you shouldn't need to update the ozpost module to resolve the Ego problem, it would be prudent to do so anyway.

Cheers
RodG