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?
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.
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 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 is *no* connection between payment methods and the shipping methods.
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).
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.
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)
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)
Yup, that's an error in the text file. The actual folders are correct.
Cheers
Rod




IR_FS_ADMIN, DIR_WS_LANGUAGES . "english/product.php" (this premodded file was needed with ozpost v3.3.2 and below)
Reply With Quote


Bookmarks