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
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".
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:
===============
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.
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.
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.
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
Bookmarks