Is anyone else having problems with the auspost shipping module. The delivery rate server seems to be down as of this morning. Has Australia Post made any changes to its delivery rate calculator? http://drc.edeliver.com.au
Printable View
Is anyone else having problems with the auspost shipping module. The delivery rate server seems to be down as of this morning. Has Australia Post made any changes to its delivery rate calculator? http://drc.edeliver.com.au
Hi etrader,
I think I have the SAME problem.
I am New to ZC, but I went LIVE today and Aust Post was working fine before I went Live so I thought that might have had something to do with it.
OBVIOUSLY NOT!
Are you getting the following ERROR MESSAGE on checkout:
Australia Post https://www.xa.com.au/store/includes...s/austpost.jpg
ERROR:Unable to obtain a valid quote from the Australia Post Server.
Please try again later, or contact the store owner if problems persist.
wayne
Hi Guys (and gals)
I can confirm that the Austpost Server is playing up (still non functional @ 9.45pm 17Jun2007).
Seems like they have a database server error.
This is the error message that gets produced when sending valid data directly to the server......
-------------------------------------------------------------------
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SQL Server does not exist or access denied.
/ratecalc2.asp, line 173
--------------------------------------------------------------------
I have seen this occur once before.. it took just under two days before they fixed it.
Cheers
RodG
Thanks for that Rod.
I thought I may have had a problem because it coincided with me installing SSL and going live.
How do you check if they are having problems? as I went to their drc page and it was working,but not on my shopping site.
In the meantime I have set up "Flat rate" as a quick fix so clients can still purchase.
Wayne
Hi crash,
to test the drc server, simply paste a valid string into your webbrowser... ie
http://drc.edeliver.com.au/ratecalc....000&Destinatio
n_Postcode=2000&Country=AU&Weight=1000&Service_Type=STANDARD&Height=100&Width=
100&Length=100&Quantity=1
Cheers
Rod
Thanks Rod !
I just tried it at 1300hrs. Appears it is still down.
I will keep this code for future REF.
Crash
Guys ...
I'm wondering if they've changed the rate calcs?
And is this a new addition to their web site (from their registration process);
A tad draconian? Or am I just a cynic?Quote:
Before using the DRC you must prominently post the statements contained below on your web site.
INSERT YOUR TRADING NAME HERE accepts responsibility for any loss of, damage to, late delivery or non-delivery of goods ordered from our web site. To the maximum extent permitted by law, you agree to release our carriers from any liability relating to loss of, damage to, late delivery or non-delivery of any goods you order from this web site and to assign all rights to claim compensation or insurance against our carriers to us and expressly and irrevocably do so by clicking the following box.
In rural and regional areas of Australia, delivery times for Express Parcel Services are in respect of delivery to the Post Office of the principal township in that area. Delivery to final destinations may take longer. If in doubt please check with your local Post Office.
You must ensure that your web site is constructed so that every customer who requests an estimate of delivery times or charges expressly agrees to the above statements at the time of making such request.
yes confirmed here.... darn microsoft fanboys they are...
working again 3pm SA time
Is anybody else up yet I'm down still in North Queensland 4.56pm
after a big headache trying to work out what the hell was going on because I just installed paypal express & Patch
Scary didn't kknow what was going on
I'm back all good but I must say a big thank-you for starting this thread I would have been there for hours
Hi all,
I have just installed the updated AustPost Improved Mod on a New Clean Store and am experiencing problems.
The quoting is not working and is responding with the error
"AustPost (ERROR:Unable to obtain a valid quote from the Australia Post Server.
Please try again later, or contact the store owner if problems persist.)"
I have checked the AP server using the links posted previously and the AP server is ok so I must have screwed something up.
Can any one assist.
Thanks
I did note that although this mod is obviously approved fro ZC 1.3.8 the files used in the mod are of varying versions some V1.3.8 some older.
I did a compare and merge on the three existing files. One of which is a language file and should not cause a problem. I then uploaded the files that came with the mod and no change. Still have the error.
I also noticed that although the AustPost shoed the error it also showed the price as $0 and was able to be selected and proceed to through the checkout.:shocking:
G'day Redmonds,
> The quoting is not working and is responding with the error
> "AustPost (ERROR:Unable to obtain a valid quote from the Australia Post Server.
> Please try again later, or contact the store owner if problems persist.)"
> I have checked the AP server using the links posted previously and the AP
> server is ok so I must have screwed something up.
If you are using V2.0.x of the Austpost module please be aware that this version users a different server than previous ones. The 'new' server is located at
austpost.vcsweb.com (please see the readme called 'servers.txt'' that is contained in the distribution files).
The main reason for this change is to offer a centralised server for the 'fixed costs' (eg, insurance rates, letter rates, prepaid satchel costs, etc), which aren't available from the orginal drc.edeliver server. Having said that, the server at austpost.vcsweb.com performs a redirect to the drc server for its 'regular' quotes.
As well as this, the new version of the module defaults to using the CURL method of server access (rather than the FILE method). Theory (and tests) dictate that if the CURL method fails the module will then try the FILE method. However, this code has not been widely tested.
OK, that's the preamble. Now to try to find a solution.
Since there are several possibilties for your failure to get a quote we need to do a little debugging.
First up I'll get you to bypass the CURL method of access and force it to use FILE.
You can do this by loading /includes/modules/shipping/austpost.php into a text editor.
Locate the line that reads:
if (function_exists('curl_init')) {
Change it to read
if (function_exists('XXXcurl_init')) {
Save the file and try to obtain a quote. If you can obtian a valid quote you have proven that the problem is with the FILE fallback code. If this is the case, simply leave the files as they are and hopefully I'll have a proper fix ready for the next release.
Another possible problem of failing to get a quote is if your webhost is blocking outgoing web requests via script files. There are a number of hosts that do this, but many of those have already included an exception to their rules so that requests to drc.edeliver.com.au are allowed. You can test to see if this is the case by loading /includes/modules/shipping/austpost.php into a text editor, and looking for the line that reads:
$SERVER = "http://austpost.vcsweb.com/" ;
Change this to:
$SERVER = "http://drc.edeliver.com.au/" ;
Resave the file and see if if the error goes away. If it does, you can then choose to either define your own 'fixed costs' . This is done by editing/uncomment the code that reads
/* Fees as of December 2007
costPrePaid3k=9.30
costPrePaid500g=5.30
costCOD=9.30
costREGaus=2.70
costREGints=10.85
costREGintl=17.50
costLETaus=50,1.00,1.45,2.45
costLETint=1.95,3.85,5.80,11.60
costINS=1.20,1.20,5.50,2.00
*/
OR, better yet, politely ask your webhost to allow scripted access to http://austpost.vcsweb.com (they will also need to leave the drc.edeliver.com.au accesssable).
If, after making the changes to:
if (function_exists('curl_init')) {
and
$SERVER = "http://austpost.vcsweb.com/" ;
And you STILL don't get a response from the server we are then treading on new ground and further faultfinding will be required.
PLEASE GET BACK TO ME WITH YOUR FINDINGS.
Cheers
Rod
G'day again Redmonds,
> I also noticed that although the AustPost shoed the error it also showed the price as $0 and > was able to be selected and proceed to through the checkout.
I guess I'll need to look into trying to do something about that, OR, do you think it may be better to simply leave it? What is better, to give a shipping quote of $0 and let the customer checkout anyway (you can always add shipping charges after the fact), or, the alternative is to not let them checkout at all because there isn't a valid shipping cost?
Just seeking opinions.
Cheers
Rod
Rod,
Thanks for ytour help it was the curl problem/solution that worked for me.
In regards to the aloowing checkout with and error I would definately prefer to allow the checkout and then worry about it afterwards. But perhaps something else shoudl be entered such as
'if you proceed you will be contact with correct shipping costs' or something like that.
Agains thanks for your help and a great mod.
G'day Redmonds,
> Thanks for ytour help it was the curl problem/solution that worked for me.
Thanks for your help too. At least now I know what the most likely cause is, and where to look to fix it. :-)
> In regards to the aloowing checkout with and error I would definately prefer to allow the
> checkout and then worry about it afterwards. But perhaps something else shoudl be
> entered such as
> 'if you proceed you will be contact with correct shipping costs' or something like that.
I like that idea. I'll see what I can do :-)
Meanwhile, wanna help me out with this CURL problem? If so, simply locate the CURL code and uncomment the debug lines. namely,
//$info=curl_getinfo($ch);
//echo 'INFO: <pre>'; print_r($info); echo '</pre><br />';
//echo 'ERROR: ' . $error . '<br />';
// print_r($data) ;
(just delete the '//'). Ensure it tries to use CURL again, then get a quote. A copy of the output should prove very useful.
Cheers
Rod
G'day centaur,
> I was so glad that I'm not the only one having this problem
What problem? The one back in June when the AustPost server was down?
> I have tried all the fixes above
Which version of the AP module?
What version of zencart?
What are the EXACT error messages you are seeing?
> Also - I had the same problem as an earlier post,
Does this mean you are having multiple problems?
If you could report *your* specific problem (ignoring any other posts, which may or may not be relevent) then I may be able to give some advice or suggestions specific to your problem, because from the sounds of it, you have more than one.
>Does the script convert so if Someone buys something for say 60 Euro, does the correct >postage get charged in Euro?
Currency conversion is a function of zencart itself, not the postage modules, so I guess the answer is 'yes', if someone byts your products in euro the shipping quotes will also be in euro.
Cheers
Rod
G'day Centaur,
> Very Sorry I was not Specific
No need for apologies, but generally speaking, the more info you give the better.
> Error is :- AustPost (ERROR:Unable to obtain a valid quote from the > Australia Post Server. Please try again later, or contact the store
> owner if problems persist.)
Although this is a generic error message, it does suggest to me that the problem you are experiencing is possibly not related to the server being down (or inaccessible), however this is still possible.
> My site is hosted om Servers in America, if that helps.
That wouldn't make any difference.
What would/could cause this problem though is if your products weights and/or dimensions exceed the allowable limits, so that needs to be one of the first things you can check.
If they are OK and If you've already tried disabling CURL (as per earlier this thread) could you please email me with name of your webhost/server and/or IP address. With this information I can look for a match in the log files to verify that the request is being recieved, and if so, whether there is any obvious errors in the data).
Cheers
Rod
Hi All,
I am also having the same problem...
ERROR:Unable to obtain a valid quote from the Australia Post Server.
Please try again later, or contact the store owner if problems persist. Item girth outside valid ranges
I haven't received in order since Christmas and was thinking it was a bit odd then I got a message from a customer notifying me of this.
I am using version 1.3.7
Any help to get this up and running would be very much appreciated. Thanks!
G'day bx1,
> I am also having the same problem...
A Similar problem, but not the SAME problem.
> ERROR:Unable to obtain a valid quote from the Australia Post Server.
> Please try again later, or contact the store owner if problems persist.
> Item girth outside valid ranges
This error message is telling you EXACTLY what your problem is. Namely, the item girth is outside valid range.
The Maximum dimensions for Australia Post parcels is length 105cm, girth 140cm.
The girth being ((width * 2) + (height * 2))
If your products really are larger than this, AustPost won't accept them. If your items are not this large simply define the correct dimensions and all will be well.
Cheers
Rod
Thanks RodG. Has Aust Post changed it's configuration? I only say this as I haven't changed any dimensions of my products and now none of them work. I'll fiddle around with it though and see what I can come up with.
G'day bx1,
> Thanks RodG. Has Aust Post changed it's configuration?
Yeah, they seem to have put a check in for your IP in order to give you different results than everyone else. <grin>
> I only say this as I haven't changed any dimensions of my products > and now none of them work.
None of them?
What was the last thing you changed when it stopped working?
I've just checked out your site and picked several items at random and got a valid quote each time. The only time I didn't get a valid quote was when the total item price exceeded $75, and that is a result of your free shipping over $xx module kicking in.
If you could point me to an item or two where I'm able to duplicate your girth error I'll be happy to take another look into it,
Cheers
Rod
Hi Rod,
I did not test all the products but the product that my customer pointed out was Mirenésse Secret Weapon Mascara Super Thick. I tried another mascara which was bought recently and worked and that didn't work when I tested it either (Mirenésse Secret Weapon Mascara Super Curl). All the settings are the same. I had a few orders before Christmas and haven't touched my site since (wanted the holidays hehe). So I'm a bit stumped at what went wrong :( Thanks for your help on this!
G'day bx1,
> I did not test all the products but the product that my customer pointed out was
> Mirenésse Secret Weapon Mascara Super Thick.
OK, I just tried this and got the same error. The problem is that your parcel dimensions are actually too small.
This problem only started to appear back in november (there have been discussions about it). I did release details on how to patch the AP module to circumvent this problem, and the fix has been incorporared into the latest release (V2.0.1)
You have 3 options.
1. Locate the earlier thread and patch your own copy of the module.
2. Download and use the latest version.
3. Adjust the dimensions of your items so that the girth is always going to exceed 50mm.
It is easy to 'prove' that this is a girth issue by adding two of those mascara's to the cart, because that does give a valid result.
My recommedation is to upgrade to the latest version of the AP module.
Cheers
Rod
n 16 00:53:43 2008] [error] PHP Warning: Invalid argument supplied for foreach() in /home/includes/modules/shipping/austpost.php on line 391
[Wed Jan 16 00:53:43 2008] [error] PHP Warning: file(http://austpost.vcsweb.com/ratecalc....e_Type=EXPRESS) [<a href='function.file'>function.file</a>]: failed to open stream: Connection timed out in /home/includes/modules/shipping/austpost.php on line 799
Need help here also, my austpost_improved module is also not working,
on checkout, the website just hangs there and does nothing..
I'm using 1.37 and the lastest austpost module
any idea? Thanks..:smile:
Hi poohbear,
> <a href='function.file'>function.file</a>]: failed to open stream: Connection timed out in
> /home/includes/modules/shipping/austpost.php on line 799
Timeout errors (such as this) can often be caused by transient network or server problems, so hopefully you've tried this more than once?
Assuming you have tried more than once, and the problem is persistant, I need the following information in order to give any useful advice or suggestions.
1. What is the URL of your store
2. Was the AP module working for you BEFORE you upgraded V2.0.x, or is this a first time installation?
Cheers
Rod
G'day Centaur,
> While I want to offer choice of insurance or no insurance to my
> customers, and for most parts of the world, it isn't a problem.
> It becomes a reflection on me and my site when a service is
> offered, and I cannot provide.
I can certainly appreciate the problem, but at the moment there isn't an 'easy' solution. This is because the AustPost server itself doesn't provide any insurance calculations at all, these are all done by the AustPost module based on nothing more than the current insurance rates and the value of the parcel.
In order to exclude certain destinations from having an insurance option I'd need to build my own database listing those exclusions.
Probably not a difficult thing to do, but could be time consuming (and even a nightmare to keep it updated).
Perhaps if you (or someone) could provide me with a *shortlist* of common but uninsurable destinations (such as Canada) I'll see what I can do. (no promises)
Cheers
Rod
Hi Rod,
Firstly, cheers for what you have done for the austpost module....awesome job..
Secondly, just wanted to let you know I was experiencing the same error as earlier posts regarding not being able to connect with the auspost server..
After changing the curl string as you suggested on page 2 of this thread, all is working fine...
Thanks
Jas
> After changing the curl string as you suggested on page 2 of this thread, all is working fine...
You'll be pleased to know that the version I've just uploaded (V2.1.2) now has an administrative setting to avoid the need for such code modifications.
V2.1.2 should be available for download in the next 12-24hours.
Cheers
Rod
Hi Rod,
I just loaded and tested the Austpost module.
a 2.5Kg product shows as 9$ for express post (Yellow) Does it support the express post prepaid satchels,or do we drop the express post parcel and just use the pre paid.
I am stuck with prepaid because i can only post after hours.
Cheers
P.s. i assume we were to make a new folder under the ADMIN-templates. I didnt have a folder called templates in the admin section
G'day Max44,
> a 2.5Kg product shows as 9$ for express post (Yellow)
> Does it support the express post prepaid satchels,
Yes, V2.1.x supports pre-paid express satchels. If they aren't appearing under the admin section you will need to do an uninstall-reinstall (click the button - no need to reinstall files).
> P.s. i assume we were to make a new folder under the ADMIN-templates. I didnt have a > folder called templates in the admin section
Yes - you will need to create this folder and all the subfolders.
BTW, I somehow failed to fully populate this folder so I've just uploaded another update with the missing icons (V2.1.3).
Note: If you are running on a linux box and have the ability to create symlinks, then this will be an easier way to go.. the symlink will be
/admin/includes/templates and it will need to point to /includes/templates/
Cheers
Rod
Hi Rod,
I unloaded and reloaded. All works fine. The version (V2.1.3) Is not showing yet. I guess they have to check it first or something.
Appreciate the efforts
Cheers
by the way. a 3Kg express post satchel is 10.50. Austpost shows it as $9.55, unless that is the price ex tax
The price is right. I couldnt edit the otherone quick enough.
An item weighing .2Kg ie 200Gm, doesnt give the option of a 500gm express post bag. I have my weights set to Kg's and have the weight as .2Kg in the product weight section.
Thanks again
Hi all.
I've just reinstalled a client's cart (1.3.7) onto a new hosting service and all seems to be going well other than the Aust Post module.
Before I go and upload the new version (which looks great by the way;) ) I'd like to show you my error code:
Warning: file() [function.file]: URL file-access is disabled in the server configuration in ..../includes/modules/shipping/austpost.php on line 88
Is this telling me it's a server issue and if so how do I get around it?
I've emailed server support and am awaiting a response.
Any clues here please?
Thanks in advance
D.
ps: in a bit of a hurry - this poor client has been messed around by the previous host and has lost a fair bit of money during the past week of being offline. I'm almost home....
Sorry Update:
Return email from the server states that have disabled the 'fopen' command and have pointed me here to find the work around. http://wiki.dreamhost.com/Allow_url_fopen.
I've been on this so long I feel like I'm looking and chinese.
Is this the same info as was posted on around page 2?
Thanks.
Back - tried asking nicely to allow script access to no avail.
Here's the reply to the request:
-----------------------------------------------------------------------------------
... that wiki article provides some alternatives for using that command and also instructions on how to install your own version of PHP if you absolutely need that specific command. Unfortunately we can't allow access to just certain domains as this feature is either on or off globally. Sorry that it's not available, but it's a security risk and leaving that open just wouldn't be fair to our clients that expect our service to be secure. :\
-----------------------------------------------------------------------------------
Fair call really.
But it's all looking a bit chinese to me. (pneumonia and sleep dep. - good combo for sensical analysis).
Anyone care to condense the wiki info?
Hopeful & stuffed.
D.
(wanders off in a daze to find the yellow brick road).
G'day max44,
> An item weighing .2Kg ie 200Gm, doesnt give the option of a 500gm express post bag. I
> have my weights set to Kg's and have the weight as .2Kg in the product weight section.
What are the dimensions of your product(s) ?
The module not only checks for a valid weight, it also checks to see if they'll fit in the bag.
Cheers
Rod
G'day Dusky,
> Warning: file() [function.file]: URL file-access is disabled in the server configuration in
> ..../includes/modules/shipping/austpost.php on line 88
> Is this telling me it's a server issue and if so how do I get around it?
Yes, that is a server issue.
The Australia post module has two different methods of of contacting the external servers, the FILE method (which is being denied by your hosting company), or the cURL access method.
You can select which method to use from the admin pages. There is a tickbox to enable/disable cURL. If it is disabled, the FILE method will be used.
I suggest you try enabling cURL.
Cheers
Rod
Hi Rod, Thanks for the tip on using cURL. I am new to ZenCart and don't know where in the admin pages to enable cURL. I did find something under Configuration > My Store > cURL Proxy Status = false. Is this the setting you were talking about?Quote:
Originally Posted by RodG
Thanks in advance for your help.
Wrong setting, wrong place. The one you need is among the config options for the Australia Post module. Way down near the end of the page.Quote:
Originally Posted by mfalley
Cheers
rod
Hi Rod,
Thanks for the quick reply. Once I knew where to look I realised that I was dealing with an older version of the module. When I took over I thought it was the newest version already installed. Once I installed the new version and enabled the cURL, all is great!
Thanks for a great module! :clap:
Hi Rod,
I think i have been making too many changes too late/early morning.
I have posted two questions which you answered quickly. In both cases, i should have looked harder before the post.
I am using the latest Zen card with a few other modules.
The Aust post improved is working great.
It, price, weight and options for satchel size are correct. I love being able to add the extra delivery day in.
Wonderfull
Thank you for your time and effort.
Hi Rod
Earlier on in this topic ( http://www.zen-cart.com/forum/showpo...1&postcount=15 ) you mentioned that, if we couldn't get our hosting service to allow scripted access to http://austpost.vcsweb.com, we could make the changes below to the /includes/modules/shipping/austpost.php file.
******
*****Quote:
Originally Posted by RodG
My hosting service (GoDaddy) replied to my request as follows:
". . . It appears you are attempting to have an outside source connect to your website. From your description, you may be trying to make an external connection to your site's databases. Unfortunately, this is disabled on our shared hosting environment and cannot be enabled. Your sites databases can only be accessed and written to from your hosting account. . . . "
I guess this means I'm not able to access the AP server. I tried editing my austpost.php file as you mentioned but the result is that, after adding a product to the shopping cart, when I click on "checkout" the whole site disappears - i.e. the next page is a total blank. If I revert to the original austpost.php code, the cart works properly again except for the "ERROR:Unable to obtain a valid quote from the Australia Post Server." message in the Shipping Method section.
I notice that the relevant lines in my austpost.php file are slightly different from the above, in that each of my lines is preceded with a "$" sign - e.g.
// $costPrePaid3k=9.30 ;
// $costPrePaid500g=5.30 ;
etc.
I've tried removing just the "//" as well as "// $" but in each case I get a blank screen after clicking on "checkout".
My site is www.lakinplates.com
Do you have any suggestions for me?
Kind regards
Geronimo - Philip
G'day Geronimo,
>Earlier on in this topic ( http://www.zen-cart.com/forum/showpo...1&postcount=15 ) you >mentioned that, if we couldn't get our hosting service to allow scripted access to >http://austpost.vcsweb.com, we could make the changes below to the >/includes/modules/shipping/austpost.php file.
If you read that post a little more carefully, that isn't what I said at all. You may have got that impression if you didn't really follow the entire message though.
> My hosting service (GoDaddy) replied to my request as follows:
> ". . . It appears you are attempting to have an outside source connect to your website.
> From your description,
You obviously didn't provide a good desription, ot they simply misinterpreted what you wrote.
> you may be trying to make an external connection to your site's databases.
Most definitely not.
> Unfortunately, this is disabled on our shared hosting environment and cannot
> be enabled.
And rightfully so. It takes extreemly rare and unusual circumstances for it to be permissible to allow external access to a database backend on a publicclly accessible server.
> Your sites databases can only be accessed and written to from your hosting account. "
Just as they should be.
Anyway, lets try to sort out your problem...
Step one. Define the problem.
It is best if you do this. I can only guess that you are getting:
"AustPost (ERROR:Unable to obtain a valid quote from the Australia Post Server.
Please try again later, or contact the store owner if problems persist.)"
If you are getting anything other than this error message you should ignore anything that follows and get back to me with what the error message actually says.
Step2.
Because you have edited the "austpost.php" file I insist you restore it with an original copy from the distribution files, then go back to step number 1.
Do not proceed to step 3 until you have satisfied steps 1 and 2.
Step3.
Log into the admin section of your store, go to the austpost module settings, and see if the 'use cURL' checkbox is ticked. If so, untick it. Save the settings, EXIT your webbrowser, start a new browser session and see if you can get a quote (using the storefront).
If it works, you are done.
If it still doesn't work repeat step#3, but this time tick the checkbox. DON'T FORGET TO CLOSE YOUR BROWSER after making this change.
(the reason is, some zencart lookups get cached, which can often make it appear that a change has had no effect).
Open a new browser and try getting another quote.
If it works, youre done, esle step#5
Step#5
If it still doesn't work and you have performed ALL of the steps above, then, and only then should you edit the php file. You only have to make ONE change (as detailed in msg#15)
----------------------------------------------------
/includes/modules/shipping/austpost.php into a text editor, and looking for the line that reads:
$SERVER = "http://austpost.vcsweb.com/" ;
Change this to:
$SERVER = "http://drc.edeliver.com.au/" ;
Resave the file and see if if the error goes away.
------------------------------------------------------------------
I think you missed that last line when you read msg#15, because you apparently went on to change other lines, and got yourself in an even deeper hole than what you were in, which is why you need to go all the way back to step#1. DON'T try to take any shortcuts, because you'll probably just end up going araound and around in circles.
I can almost guarantee that if you follow those steps, you'll have it working before getting to step#5 - and if it isn't working I would be expecting you to see a different error message than "Unable to connect to server". In which case you should NOT procede beyond the point that the error message changes (because then we are going to be looking for a different problem, and need to take different steps to solve it).
Hopefully this will help keep your sanity a little longer..... or not. ;-)
Cheers
Rod
Hi Rod
Thanks for your detailed reply. Before I do anything further I'll just confirm exactly which error I'm receiving. I replaced the austpost.php file with the original from your download and cleared all cookies, temp internet files, history and form data, then closed IE and restarted it again.
With cURL set to "yes" I get this error message when I order a product and enter the Shopping Cart page where the "Estimate Shipping Costs" table appears.
------------------------
ERROR:Unable to obtain a valid quote from the Australia Post Server.
You may still checkout using this method and we will contact you with postage costs as soon as possible.
------------------------
I then shut down IE and set cURL to "off" accessing the admin screen in Firefox. I received exactly the same error message as before. Each time it lists $0.00 in the rate column.
Is this error message the equivalent of the one you mentioned in your reply to me? I'll wait for your answer before I look at changing anything else.
Kind regards
Geronimo - Philip
Hi Philip,
Please follow Dr.Byte's instructions on how to use cURL with godaddy here:
http://www.zen-cart.com/forum/showthread.php?t=61528
Then ensure you have cURL enabled in the Australia post module.
That should/possibly/maybe get it working for you. If not, get back to me and I'll tell you the next step.
Cheers
Rod
Hi again Rod
I've checked these instructions and note that my settings are already set to: "proxy.shr.secureserver.net:3128". I experimented with the suggested older alternative just now - 64.202.165.130:3128 but the result of that was that when I clicked to display my cart, the page only partly loaded - no sideboxes, no menu along the top and none of the section below the cart that displays the shipping estimate (well...that displays the error anyway - lol).
Setting it back to the former setting - proxy.shr.secureserver.net:3128 - got those things working again.
I have cURL Proxy Status set to "True". I installed my Zen Cart through GoDaddy so I think these settings would have been automatically installed for me. My PayPal Website Payments Standard is working well, by the way. Does that give you any clues as to whether my site has access to the AP URL's?
I plan to phone GoDaddy shortly to see if I can get a better answer than the written one I received yesterday.
Thanks for continuing to follow this one through, Rod. Please let me know if you can think of anything else I should test.
I believe I have a shared hosting plan. Is that a problem?
Kind regards
Philip
Quote:
Originally Posted by RodG
Hi Rod
I've just got off the phone to GoDaddy and they assure me that they are NOT blocking access by script files to the http://austpost.vcsweb.com/ URL. I've checked my shopping cart again and am still getting the same error message.
I've also tried removing then re-installing the module just now but it makes no difference. I closed down my web browser in the meantime.
In summary:
I have ZenCart hosted with GoDaddy and am using the apple-zen template.
I have cURL set to True with proxy set to proxy.shr.secureserver.net:3128 as auto installed by GoDaddy.
GoDaddy assure me that my site has access to the Austpost URL.
I've got the Austpost module set to use cURL.
Please let me know if there is anything else I can tell you that would help you to pinpoint the problem - or what I'm doing wrong.
Kind regards
Philip
You've jumped the gun a little, but no big deal. I'll continue as I'd planned.Quote:
Originally Posted by Geronimo
As you have possibly gathered from other threads, this may very well be your issue. However I'm still not willing to give up just yet.Quote:
Originally Posted by Geronimo
That shouldn't have any bearing on this problem.Quote:
Originally Posted by Geronimo
Alas, I have very little faith in what many webhosts have to say, so please bear with me a little while longer.Quote:
Originally Posted by Geronimo
OK. I think that you should leave it that way from here on in. The reason being is that from what I've been reading the cURL method is the only method that godaddy will support, so regardless of the actual problem, this is now a confirmed 'must use'.Quote:
Originally Posted by Geronimo
Don't go blaming yourself, well, not at least until I say you can <g>Quote:
Originally Posted by Geronimo
Anyway, here's the situation so far.
1. I have determined that godaddy requires the use of cURL, so don't try anything without this option set.
2. The server @ austpost.vcsweb.com doesn't show ANY accesses coming from any of the godaddy servers (if there are any they aren't being identified as such). Sadly this is a bad sign because I can't confirm that other godaddy users aren't also having a problem. It is possible you are the first Aust zencart user hosted by godaddy.
3. The server @ austpost.vcsweb.com doesn't show any accessess with your webstore URL (www.lakinplates.com).
These are the facts that I/we know.
What we don't know for sure is whether godaddy is blocking access to austpost.vcsweb.com or not. We only have some dweeb on the help desk that has told you that (apologies to any helpdesk dweebs). I reckon they wouldn't know the difference between austpost.vcsweb.com & drc.edeliver.com (the 'official' server for austpost quotations).
Anyway, I'd like to eliminate this possibility if I can, so with curl enabled and configured (so it doesn't crash your system), could you please proceed to step#5 of my earlier instructions, namely:
Step#5
If it still doesn't work and you have performed ALL of the steps above, then, and only then should you edit the php file. You only have to make ONE change (as detailed in msg#15)
----------------------------------------------------
/includes/modules/shipping/austpost.php into a text editor, and looking for the line that reads:
$SERVER = "http://austpost.vcsweb.com/" ;
Change this to:
$SERVER = "http://drc.edeliver.com.au/" ;
Resave the file and see if if the error goes away.
------------------------------------------------------------------
Get back to me with the results (which may or may not change).
Only one thing to be aware of: If it does return a result after making this change, the result may not be accurate (it will only have some of the required data). We can take care of that if need be. The point at the moment is to see if there is ANY change at all.
If nothing changes, return the austpost.php file back to how it was.
Cheers
Rod
Philip,
I keep forgetting to mention this, but when debugging the AP module it often pays to enable all possible shipping options. The reason being that there is a chance you may have some items that can't be shipped using the methods you have made available.
Example. Your number plates possibly weight less than 500gm, and if you only have the prepaid 500gm option enabled, and the plate dimensions are larger than the bag size, the module won't have any other viable shipping methods to offer.
I don't think this IS your problem though, 'cos I should still be seeing access to the server for the cost of the bags, but I do seem to recall that there are some errors or conditions that get detected before getting to this stage , so it is a remote possibilty.
Cheers
Rod
Hi Rod
You're working late!
OK, the bloke at GoDaddy seemed pretty keen to be genuinely helpful. He put me on hold and went off for quite a while to check up with other people. I gave him the http://austpost.vcsweb.com/ and he checked the exact spelling with me so I'm assuming he checked it properly. I guess we can't be totally sure though.
I've now made sure ALL the postage options are ticked, cURL is selected and the proxy setting is the one that works with GoDaddy. I've edited the austpost.php file per your instructions - NO other changes - and tried accessing the shopping cart on my other computer, my lappy.
Unfortunately, the exact same problem appears.
I'll go back and load the original austpost.php file from your zip file again and await further instructions. :)
Rod, I certainly appreciate the time your spending on MY issue. I hope, at the end of it all, we don't find it's something stupid I've done.
Kind regards
Philip.
Hi Rod
I just added a new product with a weight of only 10 grams (I've modified everything to work in grams instead of kgs) and if I order only that item, the module quotes for me!!! However, if I add one of the plate brackets (400gms) I get the same error.
I'll mess around a bit with different weights and package sizes and see if I get any sense from it. Perhaps this might give you a clue too.
The new product is a spacer in the Accessories category.
Thanks yet again.
Philip
Yeah. I need too. Not enough hours in the day otherwise.Quote:
Originally Posted by Geronimo
You seem reasonably confident, and your latest test doesn't prove anything different.Quote:
Originally Posted by Geronimo
Bummer. I'm now starting to run out of ideas.Quote:
Originally Posted by Geronimo
It really wouldn't matter either way as far as I'm concerned. A problem is a problem, and it needs to be fixed. Assuming it is fixable.Quote:
Originally Posted by Geronimo
OK, so where to go from here..... Well, I'm still not seeing any accesses from godaddy to the austpost.vcsweb.com server, so I'm still of the opinion that it is godaddy related, but I can't think of an easy way of proving or disproving that.
I was a bit hopeful with one of your earlier observations that PayPal works ok for you, until I realised that you were only using the standard/basic module. I THINK it is only the PayPal express that uses cURL (perhaps dr.byte might step in and clarify this?).
This may be a long way around things (or not), but is it possible for you to install the PayPal express module and see if that works?
What I/we need to do is confirm with 100% certainty that the cURL is fully functional (or not). And we need to temporarily take the Australia Post stuff out of the equation. The easiiest way that I know of to do this is to use another module that uses cURL, and PayPal Express uses this for sure.
If you find that cURL itself is working fine for PPexpress then we are once again looking back at something with the AP module, however, I have a gut feeling you will have problems with that too, in which case I can only refer you back to godaddy, BUT, this time you'll have the benefit of having log files produced that will help show that there is a problem. The PayPal express module keeps some very useful logs that the AP module doesn't.
Oh, speaking of debuging, it probably won't help much, but if you reload the austpost.php file into a text editor again, and look somewhere arout line #180 you'll see part of the line reads
"debug = 0'
Change this to debug = 1 then resave the file.
The output may not be pretty, but it may reveal some useful information. If the output doesn't make much sense to you let me know what you see anyway.
The *minimum* output that you should see is:
"C - W - H - L - I "
With various numbers just b4 the dashes.
You might like to try this before playing around with PPexpress. Just incase.
Cheers
Rod
Hi Rod
I've discovered that it's the dimensions that seem to be upsetting things. If I keep HxLxW in cms below 5,000 I get results in the estimation module. However, it's only quoting the amount I've entered in the module for P&H. It doesn't seem to actually be getting information from AP.
It also doesn't make any difference what weight the item is. e.g. It's telling me now that an item weighing 65,000grams (65kgs) can be posted in a 3kg Express satchel for just $2.00!
I'll leave it now and see what you suggest next. :-)
Kind regards
Philip
Aust post have a maximum dimension limit of 105cm and a max girth of 140cm . Keep thing below that and you should be ok.Quote:
Originally Posted by Geronimo
Actually, I thought the AP module through out an error message along the lines of 'dimensions exceeded' under these conditions (rather than the more generic unable to get valid quote). Oh well, not to worry.
And I'm still not seeing anything in our log files, at least nothing that I can identify as coming from your host. If I can see the request data from the log files I'll be able to verify that your weights, dimensions, etc are correct or not.Quote:
Originally Posted by Geronimo
I now have three suggestions for you.Quote:
Originally Posted by Geronimo
1. Add a new item to your store with the dimensions 10x10x10 and a weight of 100gms. Add it to an empty cart and try to get a quote. Use the destination postcode '1234'
2. Add the debug = 1 (as per previous message), and let me know the values of "C - W - H - L - I' when trying to get a quote.
3. Go to your admin/configuration/shipping & packaging and set the tare weights to 0:0
If none of the above work, could you please add an item to your store that I can log in to 'purchase'. I still want to see something in the server log files to ensure you are actually getting out, and this may be easist done if I watch the logs while trying to get a quote (since I can't find anything that matches so far).
No rush for these.. I'm about to call it quits for the night and won't have chance to get back to you again until tomorrow evening.
Oh, FYI, the debugging info is as follows: C = the cube of the parcel, the W = width, H = height, L = length and I = number of items.
What we see here are the parameters that are passed to the server. All dimensions will be in mm's and the weights in grams (even if you weigh in kg and measure in cm).
Cheers
Rod
Thanks for all the feedback Rod.
I've changed the "0" to a "1" in the debug line and have added a product under Make/Model->Accessories->Spacers->Giant test spacer with H10W10L10 and weight 100gms.
The output is interesting:
via sessionoverideC 1000 - W 10.00 - H 2.5 - L 10.00 - I
via sessionoverideC 1000 - W 10.00 - H 2.5 - L 10.00 - I
I note that it lists H as 2.5. I have default parcel dimensions set as 17,40,2.5 - also Height dimension of the two plate brackets for the Audi are currently set at 2.5cm. The output of the log is read in mm though isn't it? So why does it correctly pick up the Width and Length of the Giant test spacer but come up with a figure of 2.5mm for the Width?
If I order just one item I'm given the option of Express Satchel 500gm or Prepaid Satchel 500gm, both costing $2.00 which is the P&H I set in the AP module.
However, if i order TEN of the same item, I receive the AP error message again - the same one as before! In both cases, the log is the same - nothing after the "I".
I wonder if this provides any more clues for you Rod.
Kind regards
Philip
PS, would it help if I gave you my admin details temporarily? As you can see my site has only test products loaded at the moment.
I'd rather you didn't give me admin details. I have no need or reason to have them (nor does anyone else).Quote:
Originally Posted by Geronimo
I've only just got home and haven't had time to digest the results of your previous tests. I'll get back to you in a couple of hours (9-10pm Adelaide time).
Meanwhile, assuming you read this before then, if you haven't already done so, please ensure you run a couple of tests using "1234" as the destination postcode.
I think we really are getting things narrowed down now. Hopefully we'll have the answer (if not the solution) b4 calling it quits tonight.
Chatya L8tr
Rod
Ok, thanks Rod.
Just to confirm - this is the readout I get when ordering just a single product with details set to: 100gm, W10, H10 and L10:
via sessionoverideC 1000 - W 10.00 - H 2.5 - L 10.00 - I
via sessionoverideC 1000 - W 10.00 - H 2.5 - L 10.00 - I
Note that H reads 2.5. I get a postal quote but only for the P&H that I've set in admin, not for the cost of the postage itself.
If I order 10 of the same product and again select 1234 as the Pcode I get this readout:
via sessionoverideC 10000 - W 10.00 - H 2.5 - L 10.00 - I
via sessionoverideC 10000 - W 10.00 - H 2.5 - L 10.00 - I
AND the postal error appears so I get no quote.
I'll be up when you get back into it Rod, so will reply quickly.
CYA then.
Philip
'Evening Phillip,
If I were allowed to swear in this forum I'd have to say "its got me @#$%ed".
Thanks to your tests, and what I'm seeing in the austpost log files things *should* be working for you. I say should because I'm seeing several things that just don't add up, and I can't really explain.
I DID find a bug in the AustPost module, but the bug is in the debugging code (how ironic). That H = 2.5 that you have commented on is a bug. I'm displaying the wrong variable. That is the default value, not the value being used.
'course, that took me around in circles a bit.
I suppose some good news for you won't go astay though. Thanks to your '1234' postcode test I can now confirm that you have connectivity to the server(s). This means that your cURL related stuff is correctly set up and therefore you no longer need to play around with that side of things.
Now, before I go any further in depth with my findings, earlier in this thread (msg#48 I think), you stated "My site is www.lakinplates.com".
Can you tell me, or do you know anything about www.iibuy.com.au?
Cheers
Rod
Hi Rod
At least we have connected to the Auspost site. I guess that's good news.... not sure where to go from there though. :)
I haven't come across the iiBuy site before. I've just brought it up and am looking at it now.
....later - it looks to be as new as my site though. :)
.... and that he uses your module which seems to WORK for him.
I think the good news just went bad. I was looking for a '1234' postcode in the server logs hoping to identify where your connections were coming from (if anywhere). There were only a couple of entries, all in the last 24 hours (out of 3 months worth of logs), so I was assuming they were you. Alas, I guess not. IOW, I think we are once again back to a server connectivity problem. Just to be sure, or not, can we try another test product 100x100x100 to postcode 1010 instead of 1234. ThanksQuote:
Originally Posted by Geronimo
Rod
Hi Rod
I made the new product 8 x 8 x 8 and 150gms weight. I've estimated shipping a few times using 1010 as the postcode. I wonder if that's shown up....
Sorry Philip, but I'm afraid it is all bad news from here. There is nothing in the logs to signify any accesses using the 1010 postcode, so that means you are back to a connectivity related problem, and for that you are back at the mercy of the folks at godaddy.Quote:
Originally Posted by Geronimo
About the only other advice I can give at this stage is when testing, always use a dummy product with the dimensions 10x10x10 and a weight of 100gms (or 0.100kgs). These values actually have a special meaning to the server(s) (assuming you can get that far), so by using them, you can concentrate on the connectivity issue rather than a possible invalid data issue.
The debug information (debug = 1 ) proved (other than the bug that it revealed) that your zencart has been installed correctly, the data from the users shopping cart is being extracted and passed to the AP module ok, and that the AP module itself is performing the correct calculations.
What it isn't doing is connecting to the server(s).
I'll get back to you if I can think of anything else, but I honestly think we have succesfully eliminated every other possible cause and explored every possible work around.
Cheers
Rod
ps. If you can get hold of that helpful person at godaddy perhaps you can get him to go through their logs to see exactly what their server is doing to requests to either austpost.vcsweb.com or drc.edieliver.com.au, because they definitely aren't getting to the servers, even if they do say it isn't being blocked.
Thanks for your exhaustive checking and testing Rod. I'll call GoDaddy again and see if I can get more detailed info from them. I'll post it here in the next few days.
Thanks again.
Kind regards
Philip
Philip,
If you are still up, and don't mind a bit more debugging, if you load austpost.php into a text editor, somewhere around line#885 is a commented out line that start like "echo 'INFO <pre> .... "
If you can uncomment the line by removing the leading // then resave the file and try another quote. I have a feeling that this may give us some useful info.
Cheers
Rod
Hi Rod
I must have knocked off a few minutes too soon. :)
OK, I've found the line you mentioned. It's followed immediately by four other lines as shown below. I've only uncommented the first line though. I hope that's correct.
// echo 'INFO: <pre>'; print_r($info); echo '</pre><br />' ; echo 'ERROR: ' . $error . '<br />'; print_r($data) ;
// if ($data != '') {
$myfile = explode("\n", $data);
return $myfile ;
// }
So it now looks like this:
echo 'INFO: <pre>'; print_r($info); echo '</pre><br />' ; echo 'ERROR: ' . $error . '<br />'; print_r($data) ;
// if ($data != '') {
$myfile = explode("\n", $data);
return $myfile ;
// }
By the time you see this, I will have tried quoting again. I'll use a product with H, W and L set to 10cm and weight to 100gms and will use postcode 1010. I'll do some quotes with postcode 1234 as well.
Let's see what it gives us.
Regards
Philip
Well, here's the result of the change to the austpost.php file:
********************
INFO:
ERROR: Received error code 403 from proxy
via sessionoverideC 1000 - W 10.00 - H 2.5 - L 10.00 - I
INFO:
ERROR: Received error code 403 from proxy
INFO:
ERROR: Received error code 403 from proxy
INFO:
ERROR: Received error code 403 from proxy
via sessionoverideC 1000 - W 10.00 - H 2.5 - L 10.00 - I
INFO:
ERROR: Received error code 403 from proxy
INFO:
ERROR: Received error code 403 from proxy
********************
Does that tell you it's GoDaddy blocking the request, or would it be something I need to change in my files, I wonder?
Thanks again, Rod.
Regards
Philip
Yes, that tells us without any doubt whatsoever that it is godaddy that is blocking the request. "error code 403' is a 'permission denied' error, and the error is clearly coming from the cURL proxy server (which means that all of your cURL settings are almost certainly correct.Quote:
Originally Posted by Geronimo
I reckon that if you report this error message , exactly as given,
ERROR: Received error code 403 from proxy", to the 'helpful' person you spoke to before they won't have any other choice than to investigate further as to why they are giving you a permission denied.
BTW, the reason why you saw several of these same error messages is because out of necessity the AP module has to do seperate lookups for each of the available shipping methods, and each error line is a result of the same error; ie, permission denied.
I really have heard bad things about the 'helpfullness' of godaddy's support, so I wish you the best of luck. However, you now have *evidence* that the problem is theirs, and not something that you have messed up (the error message is produced by *their* server, not the ap module), so go get 'em :yes:
Cheers
Rod.
Mmmm, well wish me luck then - I'm about to phone them. :)
Thanks Rod.
Regards
Philip
Hi Rod
I've just got off the phone from GoDaddy. They pointed me to a section of their help system which seems to address our situation. It give some php code to ensure that any scripts go through their secure proxy server.
I know I've got Zen Cart set up to use the appropriate protocal - proxy.shr.secureserver.net:3128 - set via Configuration->My Store, but I wonder if a variation of this particular piece of code needs to be incorporated in the austpost module to be effective.
The help screen is at http://help.godaddy.com/article/289 It is set to give access to the paypal server so I figure (with the appropriate austpost URL substituted for the paypal one) it may work for me.
The problem, of course, is that I have no idea where it should go in my system. So my questions are:
Am I headed down the right track, and can you tell me where to put it - in a manner of speaking?!
Thanks yet again....
Kind regards
Philip
It would help if I gave you the code wouldn't it? :)
From the help screen:
Note: On our shared hosting, any CURL applications that make secure HTTP connections (HTTPS over port 443) need to pass through a proxy server. The address for this proxy server is proxy.shr.secureserver.net and connections must specify the use of port 3128. The code below already includes this information.
<?
$URL="https://www.paypal.com";
if (isset($_GET["site"])) { $URL = $_GET["site"]; }
$ch = curl_init();
echo "URL = $URL <br>n";
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt ($ch, CURLOPT_HTTPPROXYTUNNEL, TRUE);
curl_setopt ($ch, CURLOPT_PROXYTYPE, CURLPROXY_HTTP);
curl_setopt ($ch, CURLOPT_PROXY,"http://proxy.shr.secureserver.net:3128");
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt ($ch, CURLOPT_URL, $URL);
curl_setopt ($ch, CURLOPT_TIMEOUT, 120);
$result = curl_exec ($ch);
echo "<hr><br>n";
echo 'Errors: ' . curl_errno($ch) . ' ' . curl_error($ch) . '<br><br>';
echo "<hr><br>n";
curl_close ($ch);
print "result - $result";
echo "<hr><br>n";
?>
This may work for PayPal (which uses https), but it won't work for the AP module because it uses regular http rather than https, so even if you did set up this way you will possibly get the external access, but they will be trying to connect to the wrong server port.Quote:
Originally Posted by Geronimo
<10 mins later>
Just to prove a bit of a point, I have just reconfigured the austpost.vcsweb.com server so that it will accept https requests.
What you need to do is load the austpost.php script into a text editor, locate the line that reads
$SERVER = "http://austpost.vcsweb.com/" and change it to
$SERVER = "https://austpost.vcsweb.com/"
(this will be somewhere around line#123)
Save the file and try getting a quote on our test product.
All being well you should get a valid quote for the delivery methods that *don't* require a connection to the drc.edeliver server (in other words, the only quotes you'll see are the prepaid satchels).
Unfortunately, I have no control over the drc.edeliver servers so I can't do anything for you in that regard, so although not a 'cure' it should go to prove the point that we are now looking at a http vs https issue.
Godaddy *may* have another proxy or port number to handle the non https requests. (As per the details in the servers.txt file, the austpost.vcsweb server handles the 'fixed price' items, and everything else gets redirected to the drc server).
Cheers
Rod
I probably should have responded to this one first. Yes, you are heading down the right track, but you don't need to put that godaddy supplied code anywhere. It is already incorporated into zen-cart and the AP module. The code isn't exactly the same, because the zencart code makes use of a few more variables, which is why zencart can have 'global' settings for the cURL proxy/port, rather than being hard coded into each of the modules that require them.Quote:
Originally Posted by Geronimo
Having said that, if you take a look at the cURL related code in the austpost.php script (where you commented out that debug line) you will find that the code is very similar to what you found on godaddy.
Bottom line.... nothing for you to do in this regard, especially if you can get a quote on the prepaid satchels by making the http/https change as per previous message.
Cheers
Rod
Hi Rod.
Just got back home again. I've added the "s" to the http in the relevant line of the austpost.php file and checked again. I get a different error message this time:
ERROR: SSL certificate problem, verify that the CA cert is OK
via sessionoverideC 1000 - W 10.00 - H 2.5 - L 10.00 - I
The estimate I get for the prepaid satchels is still only what I've entered as P&H though...
I'm going to look on GoDaddy help to see if there is any proxy info for http requests.
Regards
Philip
I was a little bit afraid of something like that. That error is caused because we use a self-signed certificate.Quote:
Originally Posted by Geronimo
It does prove that the https requests are actually working though (in order to get that error the proxy server must have made a connection to our server).
Unfortunately, that is because of the certificate problem (it is now connecting to our server, but the error is preventing the transfer of data).Quote:
Originally Posted by Geronimo
It isn't exactly what I was hoping for (obviously), but it does prove the same point that I was hoping to prove, in that it really is an http/https issue.
I've already taken a look around and didn't find anything relevent, other than the fact that much of their text implies that they do support non SSL cURL (but don't give any details in regards to the proxy settings). It seems odd that they give details for the https but not the other.Quote:
Originally Posted by Geronimo
This does make it easier for you to explain the situation to them though, 'cos all you have to do is get them to understand that https is fine, but http to the exact same server is being blocked, and you *require* non-SSL cURL support.
Cheers
Rod.
ps. Unless you want to keep the debugging information enabled for your own interest you can probably revert the austpost.php code back to the original. You won't need to change anything in this code for things to work for you once godaddy either fixes the problem or gives you more info on how to make non-SSL cURL work. (in which case the changes will be in the zencart/admin/config rather than anything to do with the AP module.
I found the same as you did, Rod, with GoDaddy. Nothing really to help. I'll contact them again and see if I can get details of NON SSL cURL, and will switch off the error reporting too.Quote:
Originally Posted by RodG
In the meantime, I've set up a basic table rate system and named it Australia Post for the screen display. I've got it to use the AP logo you supplied - I hope that's OK. I'm keen to get some products listed and be able to point people to the site soon.
I'll post again if I have any luck with GoDaddy. It may help someone else with a similar problem.
Thanks HEAPS for what I consider to be an amazing effort in supporting me with my "issues". :) I sure appreciate your time and expertize.
Kind regards
Philip
That's IF you have any luck. From comments made in the past by Dr.Byte I personally don't hold out too much hope, but who knows, they may be waiting for just one more person to report the problem before doing anything about it, and you may just be that one person :smile:Quote:
Originally Posted by Geronimo
Oh, I forgot to ask. Where do I send my bill too? <big grin>Quote:
Originally Posted by Geronimo
Seriously though, you have probably helped me as much as I've helped you. What with all the testing and checking that you have done (and I thank you for your patience during all this) you have given me some valuable insights and methods of improving my debugging techniques, and have even provided information that will aid in future debugging of similar problems, so any time and effort that I've spent is ultimately to my own benefit anyway. :smartalec:
My only regret being that although we've completely isolated the problem, it hasn't actually solved your problem.. at least not yet.
Cheers
Rod
Philip,
Would you care to do me a favour?
Load austpost.php into a text editor, find the cURL related code (near where you commented out that debug line).
Find the line that reads something like:
messageStack->add_session('cURL communication error'......)
Then immediatly after that line add:
echo $error ; exit ;
Please let me know what you see when you try ro get a quote (try both with https://austpost.vcsweb.com and again with just http://vcsweb.com.
It should give the same error message(s) that you were getting with that debug line uncommented. If it does, just leave the code in place, because I'll be incorperating similar in the next release, which should make it easier for me to identify this problem if others experience it.
Cheers
Rod
I'm just doing a backup of the site now, Rod. I'll follow up on your last message later on Friday and post the results for you.
Regards
Philip
OK Rod, I've done that and I've got AustPost activated. I did the mods on my desktop then closed the browser on my lappy and opened it again, went in and added the test product to my cart. The Cart shows along with the error message: "Received error code 403 from proxy".Quote:
Originally Posted by RodG
Also my main (java I think) menu under the header pic and all my sideboxes fail to show. The menu at the top of the page shows and the breadcrumb menu shows.
I get exactly the same results with either URL. Just to confirm I've done exactly what you requested, here is the bit of code with your mod in place:Quote:
Originally Posted by RodG
===============
if ($error != '') {
global $messageStack;
$messageStack->add_session('cURL communication ERROR: ' . $error, 'error');
echo $error ; exit ;
}
===============
I don't think it's what you wanted to happen so let me know if I can try something else for you.
Kind regards
Philip
Thanks Philip.Quote:
Originally Posted by Geronimo
Just to confirm, the change you made is/was correct.
The results you reported were pretty much exactly what I wanted/expected to see. What I was looking for was a verification that some sort of "useful" error message would appear on your screen (which it did). The fact that it 'broke' your menus and sideboxes is merely a side effect of the premature exit command that I had you type in. If you remove the "exit ; " part of that line I had you add you'll probably find things will revert back to how they were. What I'm not sure of is whether you'll actually *see* the error message if/when you remove it, because there is a possibility the screen refresh will erase it faster than you see it (which is why I forced the exit).
The important bit for me is knowing that I'm trapping this error in the right place (and only when there IS an error). Your test with a 'broken' server, and my test with a working server has confirmed that the code logic is correct. I thought it would be (because I tested by producing 'fake' errors), but that is no substitute for the real thing.
I really don't think there is anything else that I need you to try for me. You've done everything I can expect and then some more. I can take care of making the error report a bit prettier using my fake errors, safe in the knowledge that it will work the same with real errors.
Thanks again for all of your help.
Cheers
Rod.
PS. Did you have any more luck with godaddy and the http/https situation?
Hi Rod
I'm pleased it gave you what you expected. I haven't spoken to GoDaddy again yet. I'm working on other parts of the site to get it ready to go with just the table rate set-up initially until I can get yours working for my situation.
I've installed an SSL certificate and am working on a few other basic things.
No doubt I'll beg for help again in a week or so when I re-attack the GoDaddy issue :)
Kind regards
Philip
Hi Rod,
I can't checkout when the austpost module is activated, it was working fine yesterday. When you login in to an account and click on checkout, it takes quite a while for anything to happen and then you are redirected to the shopfront instead of checkout. I deactivated austpost and used flat rate and it worked as per normal.
I'm not sure if the issue I have is related to the auspost server. Any suggestions on what I can do to fix this?
Thanks,
Phil.
Additional note to the above: When austpost module is active logging in to your account after clicking on checkout also takes a very long time (2-3 minutes).
I'm having problems with the auspost mod also, it will not let you checkout. To get aroung this I have turned the auspost mod off, and set up a flat rate till auspost fix the problems!
Hi Guys.Quote:
Originally Posted by Jour
The problems you are experiencing (Saturday 17 May 2008) are due to a problem with the Australia Post servers. It is NOT a problem with the AP module.itself, so please don't waste your time trying to fix things. It'll only make it worse.
I'm not sure exactly what is going on with the AP servers, but both the drc.edeliver server (which is what we use) and the public www.austpost.com.au servers are timing out.
Sadfly, the only thing you/we can do at the moment is wait it out (or disable the AP module to prevent those horrible timeouts).
Previous experience has indicated that when these servers go down on the weekend they don't tend to get fixed until the following Monday. There have been exceptions, so I guess it depends on the nature of the problem.
Cheers
Rod
Hi Rod,
Thank you for the information.
Is this a common occurance with auspost servers?
Phil.
Common enough to be an annoyance, but not common enough to consider it a major issue. I'd say it occurs only 2 or 3 times a year.Quote:
Originally Posted by Jour
Hopefully, when I get more time (hahaha) I'll be considering methods of replicating the data that is provided by the Australia Post servers so that we are no longer dependent on them.
On the other hand, by relying on the AP servers means I don't need to update anything whenever they change their postage rates.
Cheers
Rod
Auspost website is back up and running now! http://drc.edeliver.com.au/
Auspost website (server) is back up and running now!
is the server down? i installed this mode over 1 week ago and still havent had it work at anytime...
i dont get any other errors except the server is down..
www.store.engynit.com.au
Nope. It hasn't been down since May.Quote:
Originally Posted by Eagle75au
When the server has gone down I've never known it to be down any longer than 48 hours (and that was over a weekend).Quote:
Originally Posted by Eagle75au
That is amazing, on account of the fact that such an error message simply doesn't exist. (when will people learn that the exact wording of error messages generally mean something?).Quote:
Originally Posted by Eagle75au
Can I *assume* that the error message you are seeing is
"ERROR:Unable to obtain a valid quote from the Australia Post Server."
There are MANY different causes for this message. The server being down is just one of them, and probably the *least* most likely cause.
Other than connectivity issues (generally resolved by swapping server access methods from FILE to cURL (or vice verci) the more common reasons why you will get the "ERROR:Unable to obtain a valid quote from the Australia Post Server." are invalid weights (over 20kg) or invalid dimensions (length >100cm, girth > 140cm).
However, in your case, I think you have something a lot more 'sinsister' going on.
If I didn't know better I'd think your store was being hosted on a Commodore C64 .... it is SLOOOOooooowwwwww.
I tried to do a couple of quick tests and checks for you to see if I could offer a more definitive reason for your problem, only to find that you seem to be having a problem with the popup shipping estimator itself (nothing to do with any particular module). Instead of the estimator opening a new window (as it should based on your current configuration), it is opening up in the same window as the shopping cart, and in doing so it appears to be emptying the cart(?)
That is as far as I've got. I'm finding your site to be far too slow to do any further testing, and as I've said, you appear to have something far more wrong that just issues with the AustPost module.
Did I mention that your site is Slooooowwwwwwww...
Cheers
Rod
An update to my earlier reply.Quote:
Originally Posted by Eagle75au
I checked your site again a short while ago and whatever was causing it to be slow has apparently been resolved. This time the shipping estimator popup did work as it should, and I was able to invoke the error message.
I then checked the log files from the austpost server and noted that there were no requests arriving from your store.
In other words you have a connectivity issue.
In most cases, swapping from 'FILE' access to cURL access (or vice verci) will resolve this issue. In some (rare) cases it will only half solve it.
Either way, if you could toggle the access method you are using (this is a setting under the admin function for the AP module) and let me know when you have done so I'll recheck the log files for further clues (that is assuming the change doesn't fix it for you).
Please *don't* just change this setting, notice it has no apparent affect and then change it back again. *I* need to check the logs with this toggle in the opposite state to what it is *currently* set for.
You can ignore the request above if the act of changing this toggle produces a *different* error message, in which case by all means put it back how it was but let me know *exactly* what the 'new' error message says.
This is step one in the fault finding process. Until we solve the connectivity issue you can *ignore all other possible causes*.
Cheers
Rod
Hi Rod (and everyone else)
I have the dreadful error problem as so many others :( so any help will be appreciated. Now the important details first:
Using:
zencart v.1.3.8
austpost__improved_2-1-3 (it is the only shipping module in use)
Paypal (it is the only payment module)
Web site is (it is my wife's :smile:): http://www.dollswithsoul.com
Best products for testing are in category: Snowmen
Error message:
ERROR:Unable to obtain a valid quote from the Australia Post Server.
You may still checkout using this method and we will contact you with postage costs as soon as possible.
I have tried everything and nothing seams to work at this stage. I tried the curl on/off on server as well as on the module, results are the same (error). I have tried all the codes (as suggest in the forum) to see if I get an error and still nothing. Basically I am not getting any errors or any that I can see anyway.
I have tried with different Tare weights no difference. I have maximum weight set to 20kgs and use kgs throughout.
When I use the measurement of 10x10x10 (as suggest in message 72) I do get a quote with no problem. Nevertheless the quote is the same for any postcode in OZ. When I try
international codes get the error again.
Messages with error debugging on:
Product working :
http://www.dollswithsoul.com/index.p...products_id=44
via sessionoverideC 1000 - W 10.00 - H 2.5 - L 10.00 - I
via sessionoverideC 1000 - W 10.00 - H 2.5 - L 10.00 - I
Product not working:
via sessionoverideC 27000 - W 30.00 - H 2.5 - L 30.00 - I
via sessionoverideC 27000 - W 30.00 - H 2.5 - L 30.00 - I
Now I think it is a connection problem because I am running also a localhost web server on my computer for testing purposes and everything works fine. The site is a complete duplicate.
So the question is what could the server be doing that stops me from connecting to the post server. My web site is hosted in US but have pretty much total control of it. So any ideas will be greatly appreciated :smile:
Thanks in advance
Tassos
Firstly, thanks for all the information you have supplied. It makes my job so much easier :-)Quote:
Originally Posted by hrinfo
Anyway, I can confirm without any doubt that you have a connectivity problem.
I can also state with 100% certainty that it is not related to the redirection issues mentioned elsewhere in these threads.
Unless it breaks things in a really bad way, can I get you to change your current cURL setting to the opposite state that it is currently in and send me a note to let me know when it is done.
It may not make any difference from your perspective, but it is important that I check this just incase there is more than one issue at play.
Cheers
Rod
Hi Rod,
Thanks for the quick reply. The curl was turned on (server side) and now it is turned off.
Tassos
Bad news I'm afraid. You still don't have any connectivity.Quote:
Originally Posted by hrinfo
You will need to work with your ISP with this one.
I've not come across an ISP yet that prohibits both types of access methods (file and cURL), yet this is what appears to be the case here.
If an ISP only allows one type of method it will usually be cURL (these days), and some of these require the use of a proxy server (GoDaddy is a good example of this), so I suggest this is where you need to start looking and working.
Having said that though, generally if the 'file' access method is restricted the AustPost module usually bombs out with an 'error in line 6xx' type message, so you might even be looking at a firewall related problem instead.
My recommendation, contact your ISP or search their help files for 'cURL proxy settings'.
Enter the settings you find into /admin/configuration/my Store/
Ensure the 'use cURL' toggle in the AP module is ticked.
In theory, that should get things going.
Cheers
Rod.
PS. You'll find that as long as this problem exists you'll not be able to use the PayPal (and some other) modules either.
Hi Rod,
Thanks, you were correct. They block outbound connections for security purposes and they only open them on request and verification. So I gave them the server names from Aus Post and will let you know how it plays out.
Tassos