Cheers Rod, I'll see how that goes..
Thanks,
Mike
Printable View
Cheers Rod, I'll see how that goes..
Thanks,
Mike
I don't know if FEC is compatible with this module or not.Quote:
Originally Posted by gee38l
Aus Post improved hasn't worked properly for almost a year.Quote:
Originally Posted by gee38l
ozpost is a completely different module so no overwriting the existing files will take place. If you just upload/install the ozpost module you'll end up with two modules, austPost and ozpost. There is no *need* to remove/disable the unused module, but it is strongly recommended so as to avoid any possible confusion.
Cheers
Rod
Worked a treat, inserted straight after // store it //.Quote:
Originally Posted by Mike_Dean
Now, how do I remove the words "Australia Post," as well.
I tried using the same formula, but using "Australia Post'" instead, but it did not work.
The reason I want to remove it, is that we don't always use Aust Post, but we do use the prices it quotes. So I don't want people automatically assuming it is Aust Post that will deliver.
The 'dirty' way to to this would be to add a line reading:Quote:
Originally Posted by Mike_Dean
$carrier = "" ;
This will need to be added just before/after the other line of code you added.
A simpler/better way would be to modify the /languages/modules/shipping/ozpost.php file and redefine he carrier name to your choosing (including '' )
The $carrier variable and the various 'defines' were introduced along with the TNT and Fastway functionality.
Cheers
Rod
Hi Rod,
I'm still getting errors with shipping calculation. Not sure if there has been an update to fix yet.
If a customer orders too many of a particular item/s then it will get to a point where ozpost can't calculate the shipping cost and give the Error and AP flat rate.
"ERROR: (18+53.00) x 2cm exceeds the Maximum 140cm girth allowed. Using AP Flat Rate." etc..
I've noticed on ebay, I believe its using the Auspost rates to calculate shipping automatically if wieght, size/dimensions have been entered for each product. The shipping calculates the same costs as ozpost, but doesn't give an error when more products (qty) are added.
Any update on this?
Michael
As far as I'm aware, your problem was solved months ago. The last posting from you stated "If I choose items/qtys so that it does not exceed the restrictions, everything works perfectly".Quote:
Originally Posted by giftpackaging
Yes, that is what it is *supposed* to do. The only other options are to return no quote at all, or a quote on a parcel that is too large for Australia post to accept anyway.Quote:
Originally Posted by giftpackaging
What do you think the module *should* do? Compress the parcel so that it will fit the allowed dimensions? Split the parcel into multiple parcels even though this may be physically impossible to do without damaging the goods?
A better method of 'packing and stacking' would alleviate the problem somewhat, but having already attempted several different methods, each which introduced their own problems I agree with many others in that this is the 'holy grail' of shipping modules no matter what ecommerce software is being used.. Besides, even with a *perfect* packing and stacking code, sooner or later the parcel is going to reach limits that will require you to use a different shipping method.
This is more a statement of fact rather than an error. It really doesn't matter what I do with the code, (18+53.00) x 2cm is always going to exceed the Maximum 140cm girth allowed by AustPost.Quote:
Originally Posted by giftpackaging
If you can provide a URL I'd be happy to take a look at what is being used, and how they perform this feat, but my gut feeling tells me that it will only be quoting on weight alone.Quote:
Originally Posted by giftpackaging
It is a trivial task to have the module ignore any size errors, simply by ignoring the calculated parcel size and substituting fixed dimensions instead. It may come as a bit of a shock when you actually go to post the parcel though.Quote:
Originally Posted by giftpackaging
Although I've no 'real world' data to back myself up, my hunch is that this problem will occur far more due to mulitple quantities of a single item being added to the cart than it would with single quantities of multiple items being added, and this being the case, and it is a serious issue, then the solution is to use 'bulk packing' for the items in question. By this I mean create a cart item for a box of (say) 10 somethings, and then enter the actual dimensions of these 10 items packed together so that when people buy the 10 pack the module will only see this as a single item and it won't need to use the very simple stacking code. In other words, you literally need to pre-pack the items where you are likely to get sales of multiple quantities.
As before, this will only really help minimise the error, because sooner or later we just have to obey the laws of physics. :D
Cheers
Rod
Hi Rod
I tried to load 2.0.5 onto 139c localhost but it would not install.
All I got was this error message
Network Connectivity test FAILED
Is cURL installed on your server? (it needs to be). If so, this may be a temporary glitch, try again in a few minutes.
Installation will NOT continue.
I have curl enabled in php5.2.9, but also tried it unenabled.
I tried switching lines 70-71 of \includes\modules\shipping\ozpost.php ie
$this->SERVER = 'ozpost.vcsweb.com';
// $this->SERVER = 'http://localhost/zencart/' ;
but to no avail. Are there other switches?
In doing the upgrade, however, I did note that one of your files was based on a 139b version.
There is no way that it will work without cURL.Quote:
Originally Posted by dw08gm
No reason to expect that to work either, unless you happen to be running a quotation server on your own machine :-)Quote:
Originally Posted by dw08gm
No.Quote:
Originally Posted by dw08gm
Firstly, I have no idea if you are referring to an upgrade of the ozpost module, or if you are referring to an upgrade of zencart to 1.3.9b. Perhaps both.Quote:
Originally Posted by dw08gm
Either way, I must ask the question, was your previous install of ozpost working correctly, and if so, what version was it.
As for "I did note that one of your files was based on a 139b version" this isn't quite true, it (actually, "they" as there are three of them) are based on a much older 1.3.7 or 1.3.8 version of zencart.
The purpose of them is clearly detailed within the .txt files that are supplied with all ozpost distribution packages.
Anyway, as for solving your problem, the error message is clearly indicating that there is (or was) a problem connecting to the server. A problem with cURL is just one of the *possible* causes of this problem. Other possible problems include temporary failure of the server, a firewall issue (client or server end), a routing/networking issue. a problem with the nameservers, and so forth.
The *first* thing you need to do though is ensure that cURL really is availalble and working. zencart has a program for this in the 'extras' folder.
After confirming that cURL is ok you/we will need to start to investigate why it can't (apparently) connect to the ozpost server. Depending on your skills/knowledge you may need to involve your webhost with this, however it is possible that there is a bug/flaw in the code that does the checking, so I propose this may be the easiest next step..
To do this, load /modules/shipping/ozpost.php into a text editor, then comment out (or delete) lines 525 - 532 and resave the file. Please report your results.
Cheers
Rod
Hi Rod,
I'm not suggesting parcels are to be compressed to fit the dimensions of auspost requirements. But I know if you walk into a auspost outlet, with 10 items, they aren't going to give you an error and say they can't post them because the sum of the parcels is too large.
I really think your module works perfectly except for when customers either purchase an item which is too large or add too many items to the cart that then eventually exceeds the 'requirement'.
I have just put tissue reams on ebay and used the estimate postage costs. I put in dimensions and weight of 1 ream, allowed regular and registered postage options.
http://cgi.ebay.com.au/ws/eBayISAPI....m=130390584392
Click on the postage tab, and you can enter a postcode and change qty amount. On our website, it will give an error once you go over 4 reams.
This is true only if you make the each of the parcels small enough for them to accept. In *some* cases this may not be possible, ie, where a single item will exceed the allowed dimensions.Quote:
Originally Posted by giftpackaging
This, in itself isn't a shortcoming of the module. It is still a matter of physics.Quote:
Originally Posted by giftpackaging
X number of Y products is eventually going to exceed any allowable size (or weight) limitation.
Alas, I am unable to tell from this link exactly what it is that is being sent to the quotation servers. I am still of the strong opinion that the dimensions are being ignored.Quote:
Originally Posted by giftpackaging
I understand what you are saying, but it really doesn't change anything. All this means is that unless they are using code that is too complex for me to understand (possible) the quotes that they are providing under such conditions are probably inaccurate in that it obtains a quote for a single item and multiplies it by the number of items purchased (thus over quoting when multiple items can be placed into a single package, OR it may possibly work similar to the default zencart code whereby the dimensions are non-existent/unused and the weights are simply added together and if the resulting parcel weight over the 20kg limit the purchase gets split into multiple parcels and quoted accordingly ... eg, 60kg of 'product' will be quoted at 3x 20kg parcels.Quote:
Originally Posted by giftpackaging
On the surface this appears to be a good working solution, until you get into the following situations (examples only).
3 items weighing 13kg each will create a 39kg parcel, which will be 'split' at the maximum weight setting (20kg) producing a quote for TWO parcels weighing 19.5kg each.
Unless one of the items itself can be cut in half (without damage) you will not be able to create the two parcels being quoted - you'd need to pack them into 3 parcels @ 13kg each - and I can assure you that the cost of 3 parcels @ 13kg each isn't going to cost the same as two parcels @19.5kg each. The postal charges simply aren't that linear.
Another example:
Suppose you have two items in your store, one weighing 19.7kg, the other weighing 400gm, and a person orders both. The total weight of both items exceeds the 20kg limit - If we split by weight we'll be quoted for 2x 10.05kg parcels. Clearly the 'best' way to ship these items would be 1x 19.7kg parcel and perhaps a 500gm prepaid satchel for the other. The shipping costs between the two methods is going to be significantly different (and it may not be possible to cut the 19.7kg item in half).
The same problem occurs when attempting to divide/split the parcels by size. There is no way of knowing if any given item can be physically 'split' or not, and this one is even harder to overcome than splitting by weight.
These are just very simple examples - The more items that get added to the cart (especially if the items are all different weights and sizes) the more complex this all becomes).
Bottom line is that although it is easily possible to prevent both weight and dimension errors by attempting to split parcels into allowable sizes, the quotes returned cannot be accurate unless the items themselves can actually be split in the same manner as the underlying code suggests they could.
I have spent literally *months* trying to find a practical solution to this dilemma, and there really doesn't seem to be one (which is why it is still known as a holy grail), so the options are 1) to report an error when limits are exceeded, or 2). Circumvent the limits (by dividing parcels in somewhat arbitary ways that may not even be possible) and then returning quotes that cannot be possibly be accurate.
I'd rather have ozpost produce error messages and accurate quotes rather than have it quote for parcels that may not be be possible in a real world situation or quotes that may be a long way from being even close to the real costs.
Hopefully this clarifies the situation a little better for you.
Cheers
Rod
Hi RodQuote:
Originally Posted by RodG
1.
Before committing to your response, I rechecked all of the 2.05 file edits. The file that I said was a 139b version should have read 139c, and was
admin/includes/modules/product/collect_info.php. However, I doubt this edit is material, as the only difference concerns $oFCKeditor->Value =...
2.
Upon remming lines 525 - 532 of includes/modules/shipping/ozpost.php, all except the following shipping modules in Admin > Modules > Shipping disappeared,
Flat Rate
Free Shipping Options
FREE SHIPPING!
Per Item
Returning to Admin > Home, unremming lines 525 - 532, and then returning to Admin > Modules > Shipping, resulted only with
Flat Rate
But upon returning again to Admin > Home, and then to Admin > Modules > Shipping, all shipping modules re-appeared. There is now a green light against the OZpost module and an error message at top of screen:
Error cURL communication ERROR: Could not resolve host: ozpost.vcsweb.com; No data record of requested type
Error Unable to connect to Ozpost server
Upon clicking OZpost to select for install, the screen gyrated for about 10 seconds, and then the list of OZpost Multiquote options appears in column right below Remove/Edit buttons.
Upon clicking Remove, the Install button reappears in column right, and then clicking Install, I get the white screen with error message
Network Connectivity test FAILED
Is cURL installed on your server? (it needs to be). If so, this may be a temporary glitch, try again in a few minutes.
Installation will NOT continue.
3.
In between this remming, I got three of the following myDEBUGs:
PHP Parse error: parse error, expecting `T_FUNCTION' in ...\includes\modules\shipping\ozpost.php on line 742
4.
Upon uninstalling 2.05 and reinstalling 1.02, just by replacing the two ozpost.php files, I get no curl errors and 1.02 loads.
Upon uninstalling 1.02 and reinstalling 2.05, just by replacing the two ozpost.php files, I get the curl errors and 2.05 fails to load.
5.
Upon running http://localhost/MYSTORE/extras/curltester.php (after reinstalling 1.02), I got this result
Array
(
[url] => "http://www.zen-cart.com/testcurl.php"
[content_type] =>
[http_code] => 0
[header_size] => 0
[request_size] => 0
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 0
[namelookup_time] => 0
[connect_time] => 0
[pretransfer_time] => 0
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => 0
[upload_content_length] => 0
[starttransfer_time] => 0
[redirect_time] => 0
)
I gather this result is correct when running on localhost. For comparison sake, could someone please provide live test result.
ps
This week may be remembered as the week of the long posts.
Interminable troubles of infinitesimal trickiness - how I love and hate IT.
This is the 'guts' of your problem.Quote:
Originally Posted by dw08gm
As for the errors you were getting when remming the code, it is quite possible that I got the line numbers wrong by looking at slightly different code than you have, so I wouldn'd worry about them.
These errors are both effects stemming from the "Could not resolve host" error.Quote:
Originally Posted by dw08gm
Sadly, no. That is NOT a good result.Quote:
Originally Posted by dw08gm
Here's my result (also running from localhost)Quote:
Originally Posted by dw08gm
----------------------------------------
CURL Test Page
This page is intended for testing CURL behaviour. You should be accessing this page via CURLTESTER.PHP running on YOUR server.
You submitted the following fields and data:
Array
(
[field1] => This is a test
[statuskey] => ready
)
Data validation
Good Other Info
Your server IP address is: xxx.xxx.xxx.xxx.
Your system identifies itself as: Zen Cart(tm) - CURL TEST
Array
(
[url] => "http://www.zen-cart.com/testcurl.php"
[content_type] => text/html
[http_code] => 200
[header_size] => 275
[request_size] => 212
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 1.024883
[namelookup_time] => 0.497785
[connect_time] => 0.757249
[pretransfer_time] => 0.757299
[size_upload] => 0
[size_download] => 2181
[speed_download] => 2128
[speed_upload] => 0
[download_content_length] => 2181
[upload_content_length] => 0
[starttransfer_time] => 1.023789
[redirect_time] => 0
)
--------------------------------------------
As you can see, a very different result.
Anyway, from the only significant error message provided, it appears that there may be a problem with the DNS rather than cURL - So unless you know about such things your best option is to take it up with your webhost.
Cheers
Rod
Hi Rod
I see the light now thanks. Upon connecting my localhost to the internet, I got the following curltest result. So my CURL was enabled (via php.ini) but did not work because localhost was not connected to the internet.
CURL Test Page
This page is intended for testing CURL behaviour. You should be accessing this page via CURLTESTER.PHP running on YOUR server.
You submitted the following fields and data:
Array
(
[field1] => This is a test
[statuskey] => ready
)
Data validation
Good
Other Info
Your server IP address is: xxx.xxx.xxx.xx.
Your system identifies itself as: Zen Cart(tm) - CURL TEST
Copyright © 2003 - 2010 Zen Ventures, LLC - Powered by Zen Cart™
Array
(
[url] => "http://www.zen-cart.com/testcurl.php"
[content_type] => text/html
[http_code] => 200
[header_size] => 275
[request_size] => 212
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 1.36
[namelookup_time] => 0.156
[connect_time] => 0.531
[pretransfer_time] => 0.531
[size_upload] => 0
[size_download] => 2183
[speed_download] => 1605
[speed_upload] => 0
[download_content_length] => 2183
[upload_content_length] => 0
[starttransfer_time] => 1.36
[redirect_time] => 0
)
However, whereas OZpost1.02 only required CURL to be enabled (via php.ini but with Use cURL? No), to install OZpost2.05 on localhost requires CURL to be enabled AND a live connection to the internet. I hazzard this should have been the point of my initial post on this matter.
Perhaps an explicit note to this affect in your install documents (which I wish were all combined into one txt file) would be useful for newcomers, even seasoned novices like myself.
Hi Rod
Just wondering if you can help me. I have ozpost installed and i have set the error amount up but when a customer orders alot and it goes back to my error amount the customer can't use it. It wont let them past step 2 in the check out and when it does it brings up a error screen saying the webpage format is not supported do you know what this could be.
Thanks
I guess that explains things.Quote:
Originally Posted by dw08gm
Mind you, the cURL test program, and indeed, the ozpost module itself are only really designed to work with internet connected computers and running the curltest program on local host doesn't help solve server related issues anyway.
I'll put this way up there with a warning notice that says "Hot surface, do not touch".Quote:
Originally Posted by dw08gm
No offense intended, but I do expect zencart users to have a little bit of common sense, and if an error message along the lines of "unable to connect to server" doesn't imply that an internet connection is needed then perhaps the person shouldn't be running an online store in the first place.
Not everyone will want, or need, to read all of the text files supplied. By combining them all into a single document will create a document that I beleive will be scare many people away from even attempting a self-install.Quote:
Originally Posted by dw08gm
As indicated above, I believe that newcomers should at least have some prior experience with the Internet and website management/maintanance prior to embarking on something as powerful and flexible as zencart and its associated modules. It really isn't my position to 'teach' people that 'unable to connect to server' could mean something as simple as their modem not being plugged in, to something more complex such as cURL not being installed, or a firewall issue, etc, etc... .Quote:
Originally Posted by dw08gm
As for "seasoned novices like yoursself" - In light of this discussion I would be categorising you as a complete novice due to your inabilty to realise that a localhost needs to be connected to the internet in order to access an internet server.
That said, you DID eventually realise this, as will all 'newcomers'. some will take a little longer than others, but once again this is basic computing 101 - the ozpost module documentation isn't really the place for such lessons.
Cheers
Rod
Hi Rod,
Just a piece of assistance if you wouldn't mind.
I want to remove the bracketed delivery method that appears at step 2 of the checkout process., such as
Delivery (3Kg Prepaid Satchel) and replace it with
Delivery - Prepaid Satchel. (ie remove the brackets and the reference to the 3Kg)
Thanks,
Mike
I'll need to check/verify this somehow.Quote:
Originally Posted by uniqueliving
If I don't get back to you in a day or 2 please send me a reminder :-)
Cheers
Rod
Removing the "3kg" reference can be achieved in a similar manner that has previously been discussed.Quote:
Originally Posted by Mike_Dean
Removing the brackets is something I can't really help with. They are not added by the ozpost module, but rather by the checkout page(s) themselves, so that is where you'll need to be looking.
Cheers
Rod
Thanks for your help Rod Much appreciated. :DQuote:
Originally Posted by RodG
Thanks Rod,Quote:
Originally Posted by RodG
I manged to get rid of the brackets... :clap:
but the other part has got me stumped.. :censored:
The earlier efforts removed the 3Kg from the shipping estimator, but I cant seem to fathom where, and in what file to edit to remove the reference from the checkout process pages.
What version of ozpost are you running? At a glance it looks like V1.0.x. The bug you have described was fixed in 1.0.4 or 1.0.6. The current version is 2.0.5Quote:
Originally Posted by uniqueliving
Cheers
Rod
The checkout process pages will get this data from the ozpost module.Quote:
Originally Posted by Mike_Dean
In the places where you altered ozpost.php to remove the 3Kg from the shipping estimator I seem to recall we were modifying the $description variable, correct? If so, you'll need to add more code to modify the
$quote->description variable as well.
Don't let the funny looking name scare you .. it is just another variable that the ozpost module uses in places where icons aren't suitable.. IOW, whereas "$description" is the iconised/tabulated "prettied up" description, the $quote->description variable is the "raw text".
Cheers
Rod
I have learned my lesson but I think you have missed my point that 2.05 is the first module I have encountered that requires a live connection to the internet in order to install. Included amongst the other modules I had installed without going live are your AustPost and OZpost1.x series and several payment modules. If installing live is now the new order, then obviously I am learning a new lesson.Quote:
Originally Posted by RodG
Cheers
Things change, and generally for the better.Quote:
Originally Posted by dw08gm
In this case the checks that have been put in place that allow the module to be installed have been added as a result of repeated installations on systems without the pre-requisite software requirements, specifically, PHPv5 and cURL.
In short, the module now checks whether it is *capable* of working on any given system *before* it will allow itself to be installed. The idea being to categorise and minimise support questions by segregating installation/network issues from configuration and other issues.
As a 'side effect', these checks are repeated each time you go to the /admin/modules/shipping section of the site, which gives a consistent and reliable feedback system that indicates the whether the server is accessible or not (and if not, hopefully a bit more information as to why not).
Another 'side effect' is that by using the ozpost version number as the response string from the server it is now possible to notify users when an updated module is available.
Soooo, even though this change may have caused *you* to learn a new lesson, for many others (those that haven't followed the same upgrade path) it is all 'new' anyway, so they won't have to un-learn the older methods, which is why I don't see the need to document this particular change.
Cheers
Rod
Hi RodQuote:
Originally Posted by RodG
This is what i am using and my settings and the site is www.dreamcatchersdirect.com.au
ozpost V2.0.5
Enabled
True
Dispatch Postcode
4209
Shipping Methods for Australia
Registered Letters, Registered Parcel, Express Parcel
Shipping Methods for Overseas
Registered Air Parcel
FastWay Franchise
FastWay frequent user?
No
TNTaccount
TNTuser
TNTpassword
Handling Fee - Letters
2.00
Handling Fee - Regular parcels
5.00
Handling Fee - Overseas parcels
8.00
Handling Fee - Registered and/or Insured parcels & letters
2.00
Handling Fee - Express parcels
5.00
Handling Fee - Prepaid Satchels
4.00
Handling Fee - Prepaid Satchels - Express
5.00
Handling Fee - COD
12.00
Handling Fee - ECI Documents
10.00
Handling Fee - ECI Merchandise
10.00
Handling Fee - TNT Merchandise
5.00
Handling Fee - FastWay Labels
1.00
Handling Fee - FastWay Satchels
0.00
Hide Handling Fees?
Yes
Cost on Error
45.00,99.99
Error cost Type
Flat Rate
Default ITEM Dimensions
29,25,2.5
Parcel Weight format
kgs
Hide parcel rates if letter sized ?
No
Icons type
jpg
Postage Delay (days).
2
Tare percent.
10
Sort order of display.
0
Tax Class
GST
Enable Debug?
No
Thanks Rod..Quote:
Originally Posted by RodG
if ( $quote->description == "3Kg Prepaid Satchel Express") { $quote->description = "Express Satchel" ; } straight after the other mod did the trick..
Much appreciated..
Mike
If you are interested in optimising this, both changes van be done at the same time as a result of just a single test.... eg:Quote:
Originally Posted by Mike_Dean
if ( $quote->description == "3Kg Prepaid Satchel Express") { $quote->description = "Express Satchel" ;
$description = "Express Satchel" ;
}
Cheers
Rod.
ps. This will only improve performance by a few microseconds, so don't expect any observable difference. In isolation it isn't enough to worry about, but such optimisations repeated throughout any given code has a cumunilative effect that can be quite significant.
any chance that a couriers please module will be added?
Hi Rod
Just wondering if you had a chance to look at my problem yet
Thanks
Probably not.Quote:
Originally Posted by gabbytwin
Whether intentional or not Ccouriers Please haven't made their quote server/pages easily scriptable.
Cheers
Rod
Here it is again just incase you missed itQuote:
Originally Posted by uniqueliving
Yup. You found a bug. You can download the update with the fix here (Until it is made live in the downloads section)Quote:
Originally Posted by uniqueliving
Cheers
Rod
Thanks RodQuote:
Originally Posted by RodG
Just one thing with the update i have an extra 2 empty boxes under postage delays is this normal..
Thanks again much appreciated.
Click on the 'Remove' button, then the 'Install'.Quote:
Originally Posted by uniqueliving
This will update the database and populate the empty boxes with a couple of new options/features.
Cheers
Rod
Thanks Rod all fixedQuote:
Originally Posted by RodG
Quote:
Originally Posted by RodG
I went to download this and I get a "page can not be found" error.
Kind Regards Casey
Hi Rod
It's been ages ;-)
I've finally gotten around to updating my AusPost module and discovered your new OzPost module! Very nice. Installed this morning and after a little tweaking and checking I'm now reasonably confidently running it 'live'!!! :P
Great job! :D
Note that I've also replaced my previous Fastway module with your OzPost version and like the greater options and satchel quotes which will help a great deal for my NSW store quoting freight to the non-East Coast destinations. I expect some very happy customers with lower satchel pricing.
Anyways, couple of questions...
1. Can we limit minimum Fastway label cost i.e., minimum label cost is Zone 1 - Red? I don't bother purchasing Local or Shorthaul labels and previously forced quotes based on Red label minimum which I use for everything up to Zone 1.
2. Express Post Platinum? I thought I saw it on 2.0.5 but I updated 2.0.6 moments later. Express Post Platinum 500g and 3kg satchels are a great option for me as they have tracking, sign for receipt and express service i.e., Express Registered ;-)
3. Express Post XL... I use their new 5kg Express Post satchel but not sure if this is the same thing to OzPost? OzPost seems to mention 3kg XL...
4. Are satchel dimensions specified somewhere that can be changed? My products are all dimensioned but mostly based on actual dimensions not packaged dimensions. Some larger (longer) items I have may seem like they fit in a satchel based on the specified dimensions but not after packaging or taking into account height factors which reduce maximum length. I want to avoid customers selecting satchel options when one or more products physically cannot fit.
EDIT:
5. Is there a way to limit shipping options to 'tracked' or 'signed' options only for orders with values exceeding a specified amount? E.g., Orders with value >$200 must be shipped via tracked services only.
Many kudos to you again Rod for a great shipping module and for all the effort you put into supporting it and your fellow Zenners.
Cheers
Greig
What can I say? (Read the message again).Quote:
Originally Posted by integrity_designs
Cheers
Rod
I was just pointing it out to you that the page was not working :shocking:Quote:
Originally Posted by RodG
In all seriousness, I wouldn't know one label from another. The Fastway server doesn't make any distinction between them, so the short answer is 'no'.Quote:
Originally Posted by GAM
The longer answer is that it will probably be a trivial task to modify the code so that if the quote is less than some minimum cost it will be reset to a fixed value.
Must've been your imagination.Quote:
Originally Posted by GAM
There's no reason why I *haven't* included Express Post Platinum, other than until now, no one has asked for it.
The 5kg Express Post XL is now included with the 'pre-paid express satchels' setting as this is now an officially listed and stocked product.Quote:
Originally Posted by GAM
The 3kg XL is listed separately because they are not listed in the current AustPost pricelists and are only available from some outlets.
No. The Satchel dimensions reside on the server and are not user changeable.Quote:
Originally Posted by GAM
However, due to the nature of the satchels what can be fitted into them (by dimension) is somewhat variable and far from an exact science, so if need be I'm happy to tweak the settings.
I follow what you are saying, but the solution is to use packaged dimensions for your products. If I make the satchel dimensions larger than they really are it is going to really mess things up for everyone. Including you.Quote:
Originally Posted by GAM
An allowance has been made for this.Quote:
Originally Posted by GAM
As mentioned, this isn't an exact science, and I'd be happy to tweak the figures if you find that this is consistently occurring. However, allowances have been made to take height factors into account, and if anything you should find that the module will err on the side of caution, in that you are more likely to find items will fit, even though the module suggests they won't, rather than the items not fitting and the module suggesting they will.Quote:
Originally Posted by GAM
No, but as with your question about minimum label costs, it shouldn't be too difficult to hack the code to perform this task.Quote:
Originally Posted by GAM
I can't see me adding it as a feature, mainly on account of the fact that it will require quite a complex user interface for the admin settings (what is the order value, what are the tracked services, are all the tracked services enabled or just some of them, how does the user select them, etc, etc.
By hacking/modifying the code these decisions and preferences can be performed 'as needed' without the overhead of what could be a confusing interface.
Cheers
Rod
I'm not sure why you expect it TO work?Quote:
Originally Posted by integrity_designs
"It'll probably take a week or so before the devs check and release it, so UNTIL this time, for those that simply can't wait, you can currently download it from here"
This was written 12th May2010. It is now June 1st. (a lot more than a 'week or so'). The "Until" has long passed, and the "currently" is no longer current. :shocking:
Cheers
Rod:smile:
My apologies. I did not see the date it was posted etc. I just noticed it was a new update from what I currently had installed.
Please accept my apologies.
I should take notice of the dates in future.
I have since downloaded and installed the v2.0.6 and it is working great accept i get this Error message for some reason:
ERROR: module not loaded due to missing language file: ....../store/includes/languages/english/modules/shipping/paypal_logo.php
Kind Regards Casey
Hi Rod,
This module is a real treat, thanks for all your work on it.
I've upgraded from the ast Austpost-improved one to OZPost 2.0.5 and that worked out fine. I've got the 2.0.6 release from the thread here and have a couple of questions before I upgrade this time.
1. Do I need to remove the module from the admin, shipping modules page and then install it again there afterwards, or is it sufficient to just overwrite the files?
2. Is there anything special needed to get the TNT part to work? I have a valid account and can sign into the TNT website to get quotes there, but I can't seem to get any result out of the module in ZC. I put my details into the module and enabled the TNT methods, but nothing shows up in the estimator other than the Austpost methods that are also enabled. I'm wondering if it is meant to work in place of the Austpost methods, or can those remain enabled as well?
Thanks heaps for any advice on this.
Regards
Rob
Although this isn't connected to the ozpost module in any way, I can tell you a few things that will probably help fix this.Quote:
Originally Posted by integrity_designs
Each module consists of a minimum of two files. Both files will have the exact same file name, but they are located in different folders/directories.
In your case, these are:
/store/includes/languages/english/modules/shipping/
and
/store/includes/modules/shipping/
Ozpost, for example, has the following two files:
/store/includes/languages/english/modules/shipping/ozpost.php
/store/includes/modules/shipping/ozpost.php
The error message is telling you that the module
/store/includes/modules/shipping/paypal_logo.php cannot find its associated language file at:
/store/includes/languages/english/modules/shipping/paypal_logo.php
Solution#1. Remove
/store/includes/modules/shipping/paypal_logo.php so that it no longer looks for its language file.
Solution#2. Find out where the missing paypal_logo.php file is, and place it back into its correct location.
Before deciding on a solution, I will add that I'm not familiar with any paypal_logo.php module in relation to the shipping modules, so it could be an errant file placement, somehow.
Cheers
Rod
If upgrading from 2.0.5 to 2.0.6 all you really need to do is overwriteQuote:
Originally Posted by robax
/includes/modules/shipping/ozpost.php with the new copy, then click on the remove/install buttons from the admin panel (to activate the new features).
You probably still need to register for "TNT Online"Quote:
Originally Posted by robax
http://www.tntexpress.com.au/interac...gistration.asp
Hhmmm... or was it "myTNT"
https://my.tnt.com/myTNT/login/LoginInitial.do
The TNT Site/pages are a real nightmare and I still don't really know what account/login does what. I do know that to register for either service an existing account was required.. Oh, and it also took a few phone calls to TNT before they managed to sort things out from their end for it to work.
Enter "11111111" as your TNT account number. This will activate a 'test' account so you can see it working.Quote:
Originally Posted by robax
This test account number can be discontinued at any time without notice, so don't rely on it in lieu of working out your issue with TNT.
Tip: With TNT enabled, and your login details entered, try enabling the ozpost 'debug' option. It *should* report the reason why the TNT connection failled (as well as lots of other data that probably is of little interest).
Cheers
Rod
Excellent, thanks for the tips on upgrading and on TNT.
I'll have another go with the TNT bits tomorrow and update the thread here with the results.
Thanks again
Rob
Hi Rod, I installed your ozpost 2.0.5 yesterday and was working a treat until i tried to edit my products. All I got was a blank white screen, I tried a few times, but still no luck. So I restored my files (ozpost no longer installed) and all went back to normal. I noticed that you have released a new version and so I tried that, and the exact same problem. Have you heard of this before? or know how to over come this problem as I would really like to use this module.
Kind Regards,
Shane
A blank screen is often the result of a blank line at the end of a .php file.Quote:
Originally Posted by thewickedgiftstore
ozpost requires the replacement of three files in the admin/folder. Are these being correctly replaced? You're not leaving any backups laying around in the directory are you?
You aren't trying to edit the files in any way are you? If so, how?
What are you using to upload the files? Are you using binary or ascii mode transfers.
Other than trying it a few times, what have you tried to solve the problem?
I'm sure one of those questions will probably contain the answer.
Cheers
Rod
Hey Rod,Quote:
Originally Posted by RodG
Alot of that did not mean much because I am not the technically minded, but I did manage to change to FTP settings to ASCII, I tried that, and everything seems to be working fine at the moment. Is that the way it should of been done? I hope so because it worked.
Thank you very much!
Cheers,
Actually, FTP in ASCII mode is far more likley to cause problems than FTP in Binary mode - as a general rule.Quote:
Originally Posted by thewickedgiftstore
I can't really explain why this is apparently the opposite for you .. it could be simply because the original uploads failed for other reasons.
No matter, if it is working now then all must be installed as it should be and its probably not worth dwelling on the why's or why nots'
Cheers
Rod
Hi RodQuote:
Originally Posted by RodG
Thanks for all your answers. Much appreciated and understood.
I don't mind hacking the code. I'm not very skilled but skilled enough to customse the earlier AustPost Improved module to get it working flawlessly for me. Same with the old Fastway module.
Btw, A2 vs A3 Fastway satchels were throwing me in regards to item length vs satchel length. The way it is now, I think the price is the only thing that distinguishes between an A2 or A3 satchel, as 'A2/A3' seems to be specified in both cases.
My wishlist:
1. Assistance with code hacks for Fastway minimum cost.
2. Inclusion of Express Post Platinum
3. Dimensions factor... like 'Tare percent' weight factor. Or assistance to hack code myself.
4. Assistance (point me to the correct file) for modifying Order Confirmation email text and Order History text. I want to include the Fastway Label Colour and/or Satchel Type and Transit days as I use these in dispatch functions to determine best option for my dispatch and for advising transit time when sending out dispatch advices to customers.
5. Assistance with 'Tracked services only for Order Value and PayPal payment method' hacks.
I realise I'm asking a lot and understand if you're not able to offer too much assistance but pointers in the right direction at least would be a great help for me.
Cheers
Greig
'A2/A3' is how this text data is returned by the FastWay server, and as you say, price is the only thing that distinguishes them. Almost...Quote:
Originally Posted by GAM
The ozpost server code doesn't change the data from the Fastway server in any way, but it *does* set a 'flag' based on the parcel dimensions, and it indicates this by the weight display (3kg = A2 size , 5kg = A3 size).
If you think it would be less confusing to modify the A2/A3 so that it shows one or the other then I've no problems with doing that.
Around lines 427-432 of ozpost.php you'll see where the checks are made for the FastWay methods.Quote:
Originally Posted by GAM
eg:
case "FWL";
if(in_array("FastWay Labels", $this->allowed_methods)) $handlingFee = MODULE_SHIPPING_OZPOST_FWL_HANDLING ;
break;
Modify this to something like:
case "FWL";
if(in_array("FastWay Labels", $this->allowed_methods)) { $handlingFee = MODULE_SHIPPING_OZPOST_FWL_HANDLING ;
if (($quote->cost > 0) && ($quote->cost < $aa.bb ) ) $quote->cost = "$xx.yy" ;
break;
I would've done that already, but I'm helping you with this instead :-)Quote:
Originally Posted by GAM
Around line 220 you'll see " // save dimensions for display purposes on quote form"Quote:
Originally Posted by GAM
Immediatly before this line you'll see a couple of places where the dimension data gets its 'final' manipulation. Insert any changes you need somewhere inbetween..
eg : $parcelwidth = $parcelwidth+2 ; will add 2cm to the width of the parcel being quoted.
Sorry, can't help on either. Hmmm, I'm sure the order confirmation emails contained the shipping info by default.Quote:
Originally Posted by GAM
(checks) -- Yup, it all shows in out store ok.
A setting somewhere perhaps?
Find the lines for methods that you wish to dissallow when order value exceeds you limit: eg:Quote:
Originally Posted by GAM
if(in_array("Regular Parcel", $this->allowed_methods))
Modify such lines to include the checks required: eg:
if(in_array("Regular Parcel", $this->allowed_methods)) && ($order->info['total'] < $xxx.yy )
This test requires both the Regular Parcel as an allowed method to be true AND the value of the order less than the amount specified in order to allow the quote. If either are 'false' - eg, if the total amount exceeds the specified amount then the expression will be 'false' and this method won't be shown.
There are many methods that you will need to disable this way. I suggest you do one at a time, and make regular backups.
Cheers
Rod
G'day Rod ...
Firstly, thank you for the contribution, it's much appreciated.
I for one, would certainly utilise 5kg Express Post and Express Post Platinum (3kg) satchels. They both form a big part of our daily shipping regimen, depending on workload.
Cheers.
V2.0.5 & V2.0.6 support the 5kg Express Post satchels by default. You just need to 'create' a parcel of valid weight & dimensions for it to show.Quote:
Originally Posted by Wingz
I still need to look into the Platinum before giving a yes/no response, There may be a reason why I haven't included them.
Cheers
Rod
Nope, 3kg vs 5kg indication is fine. Thanks.Quote:
Originally Posted by RodG
Excellent. I hope to be able to look at this later tonight or in the morning. Thanks again.Quote:
Originally Posted by RodG
LOL, indeed you are and I'm very grateful. When I can pay the rent again, I will forward donation. ....hopefully soon. :unsure:Quote:
Originally Posted by RodG
Excellent! Thank you.Quote:
Originally Posted by RodG
Yup, agreed. I stand corrected. The only thing missing for me is the 'transit time' i.e., 3 days, etc.Quote:
Originally Posted by RodG
Hmm, this last one could be tricky but well worth my while sorting it out.Quote:
Originally Posted by RodG
Thanks very much Rod. Hopefully I can respond later with results and working examples and not need further assistance (bug you ;)).
Please PM me your donation payment details. I will endeavour to get some goodies money to you soon.
Cheers
Greig
Even that shows OK on our systems.Quote:
Originally Posted by GAM
Do keep in mind that the examples I gave may not be entirely accurate, especially in regards to syntax.. Use as a guide only.Quote:
Originally Posted by GAM
[/quote]
Cheers
Rod
Hmm.Quote:
Originally Posted by RodG
"Sub-Total: $...
Australia Post (500gm Prepaid Satchel Express): $... Goods & Services Tax: $...."
Above is example of what appears on both order history and order confirmation email. I will look into it. Quite likely then to do with something I changed from modding my cart for the late AustPost Improved and Fastway modules.
I've also just noticed that 'Goods and Services Tax...' was on new line before (not sure whether 2.0.5 or 2.0.6) but now no line break again, which is what I've been used to in the past.
Yep, understand 'example' conditions and only expected such. I appreciate the pointers and should be all I need to hack away successfully. ;)
Thanks Rod.
Cheers
Greig.
Hi Rod
I've discovered issues this morning to do with cubing.
Customer has multiple small items and two larger items (litre bottle size). The AustPost Improved code cubes it differently and more accurate when comparing quotes.
Example - AustPost Improved:
C 10721 - W 15.00 - H 5 - L 30.00 - I
3.5357kgs
Example - OzPost:
Submitted: Length=105.00cm. Width=30.00cm. Height=15.00cm Weight=3889.27gms NumBoxes=1
47790cc 11.9475Kgs
Massive difference in quotes, obviously. AustPost Improved quote is accurate. These items would also fit in a satchel but option not provided obviously due to package length of 105cm. ;-)
I'm not sure whether this is a bug or just due to difference in the way the modules work but either way I NEED the old cubing system or something more like it.
I was wondering why I wasn't getting many orders recently... grossly exagerated shipping quotes would be a reason ;-)
I have to revert to AustPost Improved until I can resolve this. Hopefully won't be long.
Hopeful for your urgent assistance.
Cheers
Greig
Hrmm. Looking at this further to see whether I can resolve it or identify something that is wrong and I can't work it out. Not sure there is a feasible solution. The old module doesn't seem to work it out correctly either but the net result i.e., parcel shipping quotes, are more accurate in this instance. I wasn't dealing with satchels before though and none of my products or orders ever exceed carrier maximums so this was never really an issue. :(
When I was dealing with 'letter' rates in the past, I worked out a system by doctoring heights according to how many of an item could fit into a large letter and then halving it for good measure. E.g., say 10x item1 physically fit into a large letter, I simply made the product height 2cm/10. Far from accurate but it worked, mostly, for those items that could be shipped as 'large letters'.
...back to the mental drawing board.
Cheers
Greig
Perhaps.Quote:
Originally Posted by GAM
The cube calculation is a constant. What has changed is the way the items are 'stacked' - The AustPost Improved code used to split and manipulate the items in many more ways than the ozpost method. It made for much more 'efficient' packing, at the expense of splitting some items in ways that were physically impossible.Quote:
Originally Posted by GAM
The main difference that I see here (that will cause a change of quote) are the dimensions. Example - OzPost:Quote:
Originally Posted by GAM
Submitted: Length=105.00cm.
This may be a bug, It is suspiciously the same length that I am using to constrain maximum dimensions.
Yeah, that's the real issue ... why is the length coming out as 105cm. You'd think I'd notice something like that wouldn't you.Quote:
Originally Posted by GAM
Although the 105cm apparent length will affect the cube (well, maybe, but that's another matter), the difference in the calculated cubes isn't going to affect the quotes, on account of the fact that the module doesn't actually use the cube data for anything other than the debug display. Only the weight and dimensions are passed to the server.Quote:
Originally Posted by GAM
I'll take a look and get back to you shortlyQuote:
Originally Posted by GAM
Cheers
Rod
Hi Rod.
I have 'constrain dimensions' enabled. 105cm may have been exceeded but the main problem for me is still the same... the calculated parcel dimensions.
On another example....
Product dims: 5 x 5 x 2.1 cm.
Quantity: 100 units
Parcel dimensions (OzPost): 5.00x2.10x100 (cm)
These 100 fittings fit into a little box or bag easily and if fractionally lighter would be shipped in a 500g satchel, but otherwise 3kg satchel. The 100cm parcel dim means no satchel option.
[EDIT: actually the product dims are smaller in reality than specified, more like 5x2x2, hence easily fitting into a small bag.]
Cheers
Greig
Please don't make me repeat my spiel about the holy grail of shipping modules, because that is what we all want.Quote:
Originally Posted by GAM
That looks wrong to me.Quote:
Originally Posted by GAM
5 x 5 x 2.1 x 100 should come out as 5x5x210 (cm)
Hmmm, perhaps that's wrong too... how about...
50x50x2.1 (cm) or perhaps
50x5x210
It all depends on how they are packed/stacked. For multiple quantities of any given size this is quite easy to figure out and demonstrate. It gets *really* complicated when multiple items of different sizes are added.
Of the examples just given, which one is 'correct' and 'why'?
Can you suggest any 'rules' that can be applied by the module that will work in all cases for all users (or even most cases for most users?). If so, I'll be more than happy to lead you on your way down the slippery slope until even you give up after a few weeks/months.
The solution is simple. Pre-pack these fittings into bags of 100 and sell them as such. You can still sell them singularly of course, but the customers will soon realize that buying 1pack of 100 is going to save them a fortune in P&H over ordering 100 individual items.Quote:
Originally Posted by GAM
Besides, if someone wants an odd amount, such as say 80 .. They'll be more inclined to buy the 100 pack because the cost difference will probably outweigh the postage difference. Furthermore, as these are now prepackaged you don't need to waste time counting out 80 of them. It's a win-win, the customer will get more product for less $outlay, and you'll sell more product with less work/handling.
I really have given this a LOT of thought and consideration and honestly believe that this is the best way to go.
The difference you observe between the AustPost and the ozpost modules is where AustPost *attempted* to solve the issue by parcel splitting based on dimensions, the ozpost module no longer even tries.
I can appreciate that the old method worked well for you, but several others were reporting problems because it expected one (or more) of the items in the cart to be able to be split. (eg, quoting for a brick and a feather resulting in two parcels, each containing half a brick and half a feather, rather than one parcel for the brick and another for the feather..
Sorry I don't have better news for you on this one, but hopefully I have somehow managed to convince you that the best solution isn't in the code (aka, The holy grail) but in the pre-sales packing. :yes:
If you wish to go it alone and revert back to what AustPost used something like the following should work: (Insert in code just before the dimensions get saved as session data)
if ( $parcellengh >= 105 ) {
$parcellengh = $parcellengh / 2 ;
$parcelwidth = $parcelwidth * 2 ;
}
Half the length, double the width.
*Ideally* after this, the parcel should be re-oriented again, because the new width may now be the 'length' and *it* could possibly exceed the 105 limit itself, and if so repeat again. I think AustPost performed 2 such recursions before ending up in a black hole, but a single test *may* suffice for your needs.
Cheers
Rod.
Thanks Rod.
I do appreciate the complexities of this matter (we have also discussed it in the past with AusPost) and I don't want to drag it all out again. ;)
I'm aware of the pre-packaging benefits you mention but it can only be applied to a handful of items in my case. There are hundreds of different fittings that people will order in 1's, 2's, 3's... Some of the main ones maybe in 10 or 20. The 100x was for example purposes... there may be 100 'similarly' sized fittings in an order though, but to make it worse, these will be included with an item 500x200x100!!!
No easy solutions.
My head hurts with this stuff. ;) I realised earlier today that this path was trouble. I will look at the splitting as that might work out okay in many cases, however what I thought I could do for myself, as far as simple 'rules' go, would be to try something like the following.
If max dims < satchel dims
and cube < satchel max cube
and weight < satchel max weight
then offer satchel
(Customer chooses at own risk)
FYI, when I went to upgrade to latest AustPost I wasn't even expecting there to be any conditions on 'satchel' options other than weight. I was going to put the onus on the customer to choose wisely. They benefit from the lower satchel rates where reasonable instead of being charged parcel rates in ALL cases. So the addition of dimension checking was a bonus but also now a devil in disguise in my case. :)
Also considered default package sizes for 'small' items, i.e., items like fittings but realise the difficulties which your example illustrates so nicely ;)
"That looks wrong to me.
5 x 5 x 2.1 x 100 should come out as 5x5x210 (cm)
Hmmm, perhaps that's wrong too... how about...
50x50x2.1 (cm) or perhaps
50x5x210"
There is no easy answer.
Thanks again for your help and time Rod.
Cheers
Greig
Oh, btw, satchel issues aside, I think the parcel dimensioning is creating issues.
The Australia Post server must be quoting based on whatever is greater, Cube Weight (assuming calculated by Australia Post server based on submitted dims) or Actual Weight, as the quote for Express Post for the original example was around $115.00 instead of the more accurate $45-50. When I checked with the online postage calculator it seemed the quote was based on the cube weight of 12kg and not the actual 3-4kg.Quote:
Originally Posted by RodG
This is why I am currently running both OzPost and AustPost as the customer can choose the lower of the quotes while I get this sorted out.
Cheers
Greig
These aren't likely to cause any excessive dimension problems.Quote:
Originally Posted by GAM
Even lots of 10-20 shouldn't cause any excessive dimension problems if the items are less than 5cm high.Quote:
Originally Posted by GAM
Yes, there may be, but how often has this *actually* happened?Quote:
Originally Posted by GAM
I do a fair bit of online shopping myself, but rarely to I ever place an order for more than a few items at a time. I *used* to, when I had my repair business, but that was also when I was buying in wholesale from a wholesaler - which is a whole new ballgame, at least as far as postage & delivery was concerned.
There's actually lots of 'easy' solutions, but none of them work in all cases, all of the time.Quote:
Originally Posted by GAM
Mine too ..... I even occasionally think I have *the* solution, until I think it through all scenarios.Quote:
Originally Posted by GAM
I don't know how well this will gel with the server, which has its own ideas as to what will fit into a satchel. If the server doesn't think it'll fit, based on weight & dimensions then it won't return a quote.Quote:
Originally Posted by GAM
However, since this is essentially a fixed cost item it wouldn't be hard to re-add it locally. Sorry. No help with this one.
AustPost and ozpost have always used dimensions & weights.Quote:
Originally Posted by GAM
Customers won't do that, they'll choose cheaply.Quote:
Originally Posted by GAM
Sorry, but I've kinda forgotten what your problem was with satchels (I'm good at forgetting difficult questions and problems) <grin>.Quote:
Originally Posted by GAM
There isn't any way to set a default package size, only a default item size.Quote:
Originally Posted by GAM
I agree, and we are both so much smarter than any computer.Quote:
Originally Posted by GAM
My pleasure.Quote:
Originally Posted by GAM
Cheers
Rod
It can't do that. The sole purpose of dimensions is to prevent issues :-)Quote:
Originally Posted by GAM
This is correct - for parcels over 1kg.Quote:
Originally Posted by GAM
I'll not comment on which is the "more accurate" figure until I know what the input data is/was in both cases.Quote:
Originally Posted by GAM
Are we still referring to the parcel that exceeded the maximum dimensions and was constrained to 105cm? If so, then the higher cubed rate will probably be correct if verified with the online postage calculator using the same dimensions.Quote:
Originally Posted by GAM
Sorry if I appear to be a little confused, but I'm a little confused as to what you need to sort out, other than doing everyone a favour and creating bulk packs of items (where suitable) and then relying on 'normal human behavior' which 'limits' the number of items purchased in any given store at any one time to no more than a handful of products anyway, which aren't likely to exceed the practical limits. Also bearing in mind that no matter how good the code is to divide/split/limit there is still nothing to prevent someone from adding more and more different things that sooner or later you'd need several trucks to ship. (ok, an exagerration).Quote:
Originally Posted by GAM
Seriously though, If you think that you have identified a problem that is *likely* to occur during the normal course of business I'm more than willing to see what, if anything, I can do about it - But if the problem is due to somewhat unrealistic scenarious (such as bulk sales where bulk packs are not offerered) or expecting someone to purchase 100 different items in one sitting then there really isn't anything more that I can do or say, other than agree that it could be a problem, but one we need to learn to live with.
Cheers
Rod
Hi, I'm having a problem installing the ozpost module on a fresh install of ZC 139c.
My install is running on a Win32 Pro XP machine and I'm using MOWES HTTP server v2.2.3.
HTTP Server: Apache/2.2.11 (Win32) PHP/5.2.10
PHP Version: 5.2.10 (Zend: 2.2.0)
Database: MySQL 5.1.35-community
PHP Safe Mode: Off
CURL is not installed
ozpost_v2.0.6
I first did a WinMerge - I did find some minor changes to the in the ZC 139c files which I kept. Accessing the MODULE/SHIPPING through the admin panel, the Ozpost Module shows however, when I click on the INSTALL button, I get a dead page with error "The website cannot display the page". the URL displayed is
localhost/139c/admin/modules.php?set=shipping&module=ozpost&action=install
I then tried just a straight copy & paste of the ozpost package - still the same problem.
Any help appreciated
Thanks
OZ
There are only 3 files that would possibly need merging (all located under /admin/), but unless you have other modules that also use these files you won't need to merge, simply replace the originals with the replacements.Quote:
Originally Posted by ozetrade
Not much of a clue really.Quote:
Originally Posted by ozetrade
Do the other shipping modules install/uninstall OK?
Can you increase the debugging level somehow so we can get some idea *why* the page couldn't be displayed? (file not found, bad permissions, bug in code, etc, etc.
Oh shoot.... I just went to preview this post and have spotted your problem..Quote:
Originally Posted by ozetrade
"CURL is not installed"
So, how did you manage to install zencart? (which complains loudly if cURL isn't available).
Cheers
Rod
so if a "curl not installed error" appears and nobody is there to read it did it really happen?Quote:
Originally Posted by RodG
i think the term loudly is directly proportional to the emphasis a user places on reading rather than winging it
Hi Rod.Quote:
Originally Posted by RodG
I had a feeling it might be CURL that was the issue. Yes, during the installation of ZCv139c there are loud warnings regarding the abscence of CURL. These warings do go on to say that some payment and shipping modules may not function without CURL.
I have not had an isssue with earlier versions of ZC as I've always built them on this type of platform i.e. minus CURL and I've always been able to install and configure modules - payment and shipping. I don't test full function until I upload to a host provider. I've just never aexperienced this type of install failure. I would guess it has to do with your full rewrite of the module.
Never mind. :smile: I'll upload to the host provider and check it.
Thanks
OZ
I think you misunderstand. It is zencart v1.3.9 that 'complains loudly' if cURL isn't installed, so the theory is you must've jumped a few hoops to get IT installed before you could even get to the ozpost installation stage.Quote:
Originally Posted by ALiepinieks
The ozpost module doesn't check to see if cURL is installed, but it does check that it is functional and can contact the quotation servers, and if it can't IT will loudly complain that the install can't continue.
I was figuring there wouldn't be a need to duplicate the check to see if cURL is installed or not, but apparently there probably is a need.
Cheers
Rod
ozpost being one such module.Quote:
Originally Posted by ozetrade
If you still wish to install without cURL you'll need to modify the ozpost.php code a little:Quote:
Originally Posted by ozetrade
Somewhere around line 552 is a line that reads // version check / network check. Comment out the next 5 or six lines (down to and including the first/next closing brace "}".
Cheers
Rod
Sadly, Rod, not everyone actually READS what pops up on the screen - until that message keeps reappearing over and over again. And even then the complaints keep flooding in .... we can't please all of the people all of the time :no:Quote:
Originally Posted by RodG
G'day Rod,
I am using ozpost with curl on version 1.38 and it usually works fine. But lately contact to the server seems to be going down quite often.
Do you suggest i do the upgrade to the latest ozpost version? Has there been some fixes in this area for better contact to oz post server?
Is there a link you can supply me that tells me the oz post server is down, somewhere i can check.
Love the module, best regards Sean
The log files don't indicate any problems so the problem may not be server side.Quote:
Originally Posted by sgallasch
Yes. always :-)Quote:
Originally Posted by sgallasch
No. If anything the latest version may even be worse, on account of the fact that I have reduced the timeout settings to 10seconds (down from 30secs).Quote:
Originally Posted by sgallasch
Actually it shouldn't be any worse as a valid response should be obtained in a few microseconds - so even a 10 second timeout is magnitudes longer than it really needs to be.
Something like this ?Quote:
Originally Posted by sgallasch
Also, the latest ozpost versions V2.x.x now has its own inbuilt server check that is activated whenever you go to the admin/shipping section of the site.
You'll not see anything out of the ordinary if everything is ok, but if there is a server or connectivity problem the module will provide a warning notice, hopefully with a few details as to what is amiss. If you are having consistant connection problems it will probablt be worth upgrading for this enhancement alone.
Cheers
Rod
Hey everyone,
Server appears to be down at the moment. Is anyone else having the same problems as me?
1.45 SA time - server is up. Logs show normal access.Quote:
Originally Posted by somedood
If the server is up, there's something else going wrong with the module. It's not working on any of my ZC installations all of a sudden.Quote:
Originally Posted by RodG
What version of ozpost?Quote:
Originally Posted by 7thPo
What version of zencart?
Can you provide a URL?
Any kind of clue would be useful.
Cheers
Rod
How do I find out which version of ozpost I'm running?
Hi Rod,
Been looking at my ISP but don't seem to have been any changes from their side.
Not sure of version of ozpost. I downloaded and installed oct last year. From the text documents I think it's V2.
Zen cart is version 1.3.8a
I'll have to PM you the URL.
If you don't know then you probably need to upgrade :smile:Quote:
Originally Posted by 7thPo
v2.0.6 is the latest.
Cheers
Rod
ozpost V2.x.x has only been available for a month or so, which means you are either using V1.x.x or you are not using ozpost at all, but the much older AustPost - Improved.Quote:
Originally Posted by somedood
If you are using AustPost - Improved this stopped working for most people about a year ago <???????>
Cheers
Rod
Hi
I also am having problems? Nothing has been changed on my site and when I get to the page in the checkout I get the message
Unexpected error (no valid methods). Using AP Flat Rate. $99.99+
Any ideas please
Johanne
The Horsemans Shop:shocking:
Hi Rod,Quote:
Originally Posted by RodG
Definitely using ozpost, and most likely V1.x.x.
I'll give the upgrade a shot, and we'll see. It looks like some others are having the same problem though...I suspect it's a server related problem?
Two things look 'odd'.Quote:
Originally Posted by somedood
1. The shipping estimator page is indicating that your products (or at least the one I tested at random) doesn't contain any dimensions.
2. The client requests appear to be lacking version information.
I'm not sure which of these are causing the problem (if either), but these are both things that warrant further investigation.
Cheers
Rod
Seems server related to me. I have a range of installations all using different versions which were working fine up until about 1pm Australian EST today.Quote:
Originally Posted by somedood
I agree, there has been a rather abnormal increase in reported problems over the last 24 hours. Still nothing really abnormal showing in the logs though and it has been a few days since I've made any changes to the server code..Quote:
Originally Posted by somedood
I'm still watching and looking for any patterns that may give further clues.
Cheers
Rod
Rod,Quote:
Originally Posted by RodG
Dimensions are definitely there. No data has been changed.
I'm not too sure about version information, i'm not really that code savvy. I'd prefer not to upgrade if everything's working fine, but I suppose i'd have to give upgrading a try if we can't locate the problem soon. Let me know if you come up with anything else.
Thanks mate.
Hi,
I have checked with 2 other people who also are zen cart shops and their OZPOST is also not working??
Johanne
The Horsemans Shop
We are also having problems with all our sites using Oz Post.
If you post the URL directly into a browser it returns a correct quote but if you send it to the server via CURL it fails. The errors message is "Invalid input Data [UNKNOWN MODULE VERSION]"
What version are you running?Quote:
Originally Posted by phoenix2010
What version(s) of ozpost are they running?Quote:
Originally Posted by jld
Cheers
Rod
Good news - ours fails with the v1 module but upgrading to the new module and doing nothing else fixes the problem. Will try on some other sites, but it looks like the fix is to upgrade to the new version of the module.
Interested to know from Rod what the new module does differently in terms of passing the quote to the url and getting back the response via curl? Besides straight bug fixes how does the module work differently with the new version? Compared the code and there are huge number of differences but suspect most of these are to accommodate the multiple quotes from different carriers...?
Well, I guess that's good news ... and maybe even a clue.Quote:
Originally Posted by phoenix2010
A lot of the changes are related to the quotes from other carriers, but there have also been lots of changes/additions in regards to error and fault reporting. It is rather ironic that apparently one of the changes made appears to have broken functionality for some(?) older versions.Quote:
Originally Posted by phoenix2010
It has also been a few weeks since I've made any changes to the server code that could possibly cause a problem like this - So I'm now starting to think that whatever I did it must've been the accidental deletion of a line of code, or a mistyped variable, etc.
I think the problem is a little bit deeper than changes between V1 and V2 because the logs are still showing regular access by folks using V1.0.2 and V1.0.4 (curiously, no versions older than that, but I don't think versions prior to then were sending version information anyway.
Hopefully more clues will be forthcoming from others.
Cheers
Rod
Hi Rod, Can I suggest something that would help us with this issues? A button to request a postage quote on that page, instead of the error showing? Is that possible?
Also are the servers down at the moment?
Thanks
Jazzah
Hi Rod - thanks for your comments. Actually, Zencart will install without CURL, no hoops or sidesteps. I've done it many times.Quote:
Originally Posted by RodG
I do appreciate your comments in a later post suggesting a work around to solve the install issue.
FRANK. Your comments indicate you like to "Categorize People". I can tell you now I have enough experience with Zencart (6-7 years if I remember correctly) to understand what is required to install the package. Like you, I have developed many sites. I do read the warnings (and click on the links that provide additional information) and the statement I made earlier regarding the CURL warnings was correct however based on your comments, it's obvious you don't.
This screen capture confirms my earlier statement.
http://ozetrade.net/images/curl.jpg
If you actually read the text in the popup, it advised that some payment & shipping modules require CURL to talk to to there respective servers to get real-time quotes and payment authorizations - there is no mention of installation issues, and as I haven't had any installations issues with earlier versions of the ozpost module, I personally had no issue asking for advise in this instance.
Regards
OZ
hi, sorry, just read previous posts, we will upgrade as well and see if the error improves. I meant the button for when the package exceeds the size limit!Quote:
Originally Posted by jazzah
v2.0.6 includes an option to 'constrain' the parcel size. Although this will negate the cubing rules it will allow the quote to succeed based on weight alone.Quote:
Originally Posted by jazzah
V2.x.x no longer shows these as 'errors' - Instead, it provides a fallback mechanism to allow a quote to be produced based on flat rate, cost per item, or cost per kilo.Quote:
Originally Posted by jazzah
Also, I guess a 'button' is possible, but the question is, exactly what should this button *actually* do? Generate an email to admin? Allow the customer to checkout anyway, but prevent payment until postage is known? Prevent checkout and store cart the cart contents somewhere for the merchant to calculate charges some other way? I'm open to suggestions.
Cheers
Rod
Where can 2.0.6 be downloaded from? the download version on the ZC addons site is stil 2.0.5