Printable View
I've reverted to using a flat rate for the time being..Quote:
Originally Posted by remoteone
Most of my items I can get away with it like this.
I'll lose a little on freight on some, and perhaps gain a little on others.. Swings and Roundabouts..
But at least customers can checkout and not notice any errors..
I'm using ZC 1.3.7 and the above work around appears to be working almost perfectly for me - except strangely the 3kg express satchel option has disappeared. I can live with that quite comfortably for a while. Customers have since checked out and all went smoothly. Huge big thank you Sean (sgallasch) for providing that info!!Quote:
Originally Posted by sgallasch
RodG - I've silently wished you much good fortune for providing your Aust. Post modules. It's been such a help and I truly thank you - hope I can buy you a coffee or three one day! Sorry that you're experiencing pain with your ISP and I wish you all the best!
Cheers,
Joanne
1. Yes, you SHOULD upgrade to ozpost rather than AustPost. If for no other reason than I no longer maintain current pricing for the older module.Quote:
Originally Posted by sgallasch
2. The ozpost server is back online now. (Since a few hours ago).
3. The AustPost server is NOT back online (another reason to upgrade). I don't consider this one to be a priority .... I still have another 40-50 domains to restore from backups onto the new servers.
Need sleep. Haven't had any for 2 days
Cheers
Rod
This is/was one of the shortcomings of the AustPost module .. it needs access to both the drc AND the Austpost servers in order to obtain a full set of quotes.Quote:
Originally Posted by jojo11
Please see my previous post in regards to the current status of the austpost server. I *strongly* suggest you upgrade to the 'ozpost' module instead (if you want the full set of quotes).
Cheers
Rod
I thought I was using the current ozzy post..
Turns out I was not.. So I have updated to the ozpost..
I have it running on my test server at present, and I have found a spelling error on one of the freight options..
The 3Kg Prepaid Satchels, actually displays as 3Kg Prepaid Stachels on the checkout page.
I've used the developer to try and find the error, and it tells me there is no such file/word as Stachel in the 1467 files I have..????
Anyone else uncover/discover this and know of a fix ???
Thanks,
Mike
Quote:
Originally Posted by Mike_Dean
Some addtional issues..
The above error is only showing on the Shipping Estimator of the cart page, and only when I turn off the Icons for this Mod in Admin.
Which also then in turn creates another issue.
With the Icon switch set to off, there is now no shipping option to select on the checkout page..
In summary..
With the Icons off and the Estimator on, the spelling error appears, but then proceed to checkout and the shipping options do not show, and you can therefor, not checkout.
With the icons on, the spelling error is no longer, and you can checkout..
My problem is, I prefer it nice and clean with no logos or icons etc.
Hi,
I've just installed ozpost into a zencart 1.3.7 install. I've previously been using the auspost package.
When I try to checkout or eastimate shipping, I get the following errors.
Any clues to what is going on?Code:Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: Entity: line 1: parser error : Start tag expected, '<' not found in /home/homann/public_html/store/includes/modules/shipping/ozpost.php on line 345
Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: 2d8 in /home/homann/public_html/store/includes/modules/shipping/ozpost.php on line 345
Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: ^ in /home/homann/public_html/store/includes/modules/shipping/ozpost.php on line 345
Fatal error: Uncaught exception 'Exception' with message 'String could not be parsed as XML' in /home/homann/public_html/store/includes/modules/shipping/ozpost.php:345 Stack trace: #0 /home/homann/public_html/store/includes/modules/shipping/ozpost.php(345): SimpleXMLElement->__construct('2d8??<?xml vers...') #1 /home/homann/public_html/store/includes/classes/shipping.php(114): ozpost->quote('') #2 /home/homann/public_html/store/includes/modules/pages/checkout_shipping/header_php.php(170): shipping->quote() #3 /home/homann/public_html/store/index.php(36): require('/home/homann/pu...') #4 {main} thrown in /home/homann/public_html/store/includes/modules/shipping/ozpost.php on line 345
Cheers,
peter.
Ok.. Sorted my issues out (I think..!!)
I took the files that had been modded by "Remote One" a few pages back and incorporated them into the mod, as I assumed that was their purpose.
I went back, and installed the mod plain and simple from the downloads section and at least with no Icons, I can still go through the checkout process.
However, the spelling mistake is still evident on the 3Kg Prepaid Satchel Express, it still shows as 3Kg Prepaid Stachel Epxress.. :wacko:
Thanks Rod, will do.Quote:
Originally Posted by RodG
Regards
Sean :flex:
Hello Rod or anyone who knows the new OZ POST module well,Quote:
Originally Posted by RodG
I have a question i hope you can help me with:
Firstly i love the new module, very cool coding :)
Could you point me to the script area in the new module to change the wording "Aussie Post" that comes up in the cart and the estimates page. I would like to delete the Aussie bit out.
Any help here would be muchly appreciated.
Regards
Sean :flex
Quote:
Originally Posted by sgallasch
Go into your admin, click on tools, then Developers tool kit.
In the bottom field, type in Aussie Post, then on the check box beside that, select All files - Catalogue/Admin, then click search
That will tell you what file "Aussie Post" is in..
It's a great tool for finding files, saves searching high and low...
Worked a treat!Quote:
Originally Posted by Mike_Dean
Thanks Mike :flex:
Hello,
Is it possible to use the newer ozpost with php4 ?
As I just figured our austpost scrip no longer works for the meanwhile, so I just tried the newer script. But it appears php version requires to be updated.
Thanks!
Actually, i just noticed that i can upgrade my PHP to 5.2, so its all good now. Will give it a go when the transfer is complete.
The next question I have is the photo of the shipping module appears not to show up at the moment, is that normal? Thanks
Sorry again for all the post, you can ignore the ones above.Quote:
Originally Posted by poohbear
Ok I have another small problem - I would like to use this module only for Australia, but it seems that the international rates (specifically, letter rates) appear even though "oversea" shipping methods are all disabled. Is there any way around that as I would only require International Express for international.
(Ps i'm using ozpost 1.02)
Any help would be appreciated.
For the past week my shipping estimator has been showing an error message:
I assumed this was due to the server problem Rod posted about but as he has advised that the Ozpost server has been restored, does anyon else have any idea what might be wrong?Quote:
Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: Entity: line 1: parser error : Start tag expected, '<' not found in /home/charcool/public_html/shop/includes/modules/shipping/ozpost.php on line 345
Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: a0 in /home/charcool/public_html/shop/includes/modules/shipping/ozpost.php on line 345
Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: ^ in /home/charcool/public_html/shop/includes/modules/shipping/ozpost.php on line 345
Fatal error: Uncaught exception 'Exception' with message 'String could not be parsed as XML' in /home/charcool/public_html/shop/includes/modules/shipping/ozpost.php:345 Stack trace: #0 /home/charcool/public_html/shop/includes/modules/shipping/ozpost.php(345): SimpleXMLElement->__construct('a0??<?xml versi...') #1 /home/charcool/public_html/shop/includes/classes/shipping.php(114): ozpost->quote('') #2 /home/charcool/public_html/shop/includes/modules/shipping_estimator.php(133): shipping->quote() #3 /home/charcool/public_html/shop/includes/templates/charcool/templates/tpl_shopping_cart_default.php(173): require('/home/charcool/...') #4 /home/charcool/public_html/shop/includes/templates/charcool/common/tpl_main_page.php(121): require('/home/charcool/...') #5 /home/charcool/public_html/shop/index.php(97): require('/home/charcool/...') #6 {main} thrown in /home/charcool/public_html/shop/includes/modules/shipping/ozpost.php on line 345
I notice someone else had the same problem but couldn't find a response.
thanks
Hi,
I've just tried the new Ozpost module. I was previously using the AUStpost_improved version but that seems to have stopped working due to the server being down at Australia post.
Unfortunately I can't seem to get the OZpost module working either. I've installed it but when I click on "estimate postage" or just travel through the checkout process I just get a blank screen. If I do a refresh of the page it seems to show the appropriate shopping cart page but there are no shipping options listed. There are no errors shown.
I'm using zencart 1.3.8, on a Zues server. My host provider uses shared sessions if thats an important factor.
does anyone have any ideas as to what this is?
Hi Rod,Quote:
Originally Posted by RodG
I would like to suggest one thing.
I was using the austPost module and I didn't know that it is no longer supported and didn't know about the ozPost.
Could you edit the austpost module download page and say that is no longer supported and also put the link to ozPost download page.I think this way everybody will migrate to ozPost and avoid problems.
Which was my case!
Cheers!
At the moment, nothing is 'normal'.Quote:
Originally Posted by poohbear
Seriously, if you are referring to the vcsweb logo, this probably hasn't been uploaded to the new servers yet. This'll probably 'fix itself' as we get more and more data migrated over).
At the moment we are concentrating on functionality rather than good looks.
In case you are unaware, due to 3rd party abuse we lost access to our servers last weekend. As well as all of our 'free' services we have over 50 domains (paying clients) that need to be migrated. Many with custom programming that needs updating for various reasons, so needless to say, these take priority.
Cheers
Rod
If you have debug enabled, then disable it and the problem should go away.Quote:
Originally Posted by poohbear
If debug is not enabled, then you may have found a bug (how ironic, eh), in which case, please remind me about it in a few weeks.
Cheers
Rod
This is a new one on me. Is it consistant or intermittent?Quote:
Originally Posted by Arliss61
Cheers
Rod
Quote:
Originally Posted by p1drobert
Possibly need PHP5
Too much turmoil to even consider at this stage. However, this is GPL software, so *anyone* is welcome/encouraged to take up your suggestion.Quote:
Originally Posted by ferreirabraga
Hi, Rod:Quote:
Originally Posted by RodG
Just checked that The version for PHP is 5.2.9. But still have the problem as above.
Do you have any idea how to resolove it?
Cheers
Jimmy
Hi Rod,Quote:
Originally Posted by RodG
thanks for your response. no, debug mode is not on, so it might be a bug then ?
If you have time, we shall await the new fix for that. thanks :)
So many people with so many problems, some due to still using the obsolete AustPost module, some because they don't have php5 installed/enabled, and some with as yet undiagnosed problems.Quote:
Originally Posted by Jimmyyu1998
I'm startting to lose track with who is suffering which problem.
Anyway, to sum up the current situation and resolve most, if not all problems.
This is general info for everyone (I just happened to pick you message to reply too).
1. Ensure you are using ozpost and not AustPost.
2. Ensure PHP5 is installed and enabled.
3. If problems persist (and in some cases they will) please download the zip file that is posted here:
http://www.zen-cart.com/forum/attach...7&d=1252290889
IMPORTANT: This link does NOT provide a "full" set of distribution files, but it does provide an updated ozpost.php file that fixes a somewhat 'rare' problem (details elude me at the moment).
If after performing all 3 steps above you STILL have a problem, please enable the debug option and see if that gives any clues.. it is most likely something amiss with your input data (items too heavy or large for Australia Post).
Unlike the AustPost module, the ozpost module doesn't make any attempt to split large/heavy items into smaller parcels. This is because a lot of people were finding the parcels were being split in ways that weren't physically possible.
Hopefully this info will help solve a few issues for a few people.
For anyone waiting and hoping that the old AustPost module will ever start to work again, the answer is NO. This module has already been supplying incorrect quotes since Australia Post increased their prices back in July.
Cheers
Rod.
Hi RodQuote:
Originally Posted by RodG
Thanks. I can see how busy you are.
Well it looks permanent now. I assumed from the error message there was something wrong with the ozpost.php file in includes/modules so I renamed the old one x ozpost.php and uploaded the original file.
Initially I though it was fixed because the shopping cart didn't show the error message just the estimator with walk in as the only option.
OK, maybe I needed to reconfigure the shipping options so I went to the shipping module in my control panel to open Ozpost but have the following:
So I can't open the module to uninstall or change any options from the control panel and the original error message in the shopping cart has reappeared.Quote:
Warning: include(/home/charcool/public_html/shop/includes/languages/english/modules/shipping/x ozpost.php) [function.include]: failed to open stream: No such file or directory in /home/charcool/public_html/shop/admin/modules.php on line 174
Warning: include() [function.include]: Failed opening '/home/charcool/public_html/shop/includes/languages/english/modules/shipping/x ozpost.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/charcool/public_html/shop/admin/modules.php on line 174
Fatal error: Cannot redeclare class ozpost in /home/charcool/public_html/shop/includes/modules/shipping/x ozpost.php on line 783
For some reason it appears to be stuck looking for the x ozpost.php file and I can't open any of the modules (eg FREE SHIPPING!) in the control panel.
I know you are very busy at present but hopefully it'll ring some bells
cheers
Hi,
I'm desperate for some help. (aren't we all) :smile:
I've install the new ozpost_V1-0-2 and then the patch ozpost_gif_icons
I'm getting the following XML parsing error from line 253 in the auspost.php module.
Code:Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: Entity: line 1: parser error : Start tag expected, '<' not found in /home/homann/public_html/store/includes/modules/shipping/ozpost.php on line 352
Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: 4a in /home/homann/public_html/store/includes/modules/shipping/ozpost.php on line 352
Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: ^ in /home/homann/public_html/store/includes/modules/shipping/ozpost.php on line 352
resulting in this fatel error;
Code:Fatal error: Uncaught exception 'Exception' with message 'String could not be parsed as XML' in /home/homann/public_html/store/includes/modules/shipping/ozpost.php:352 Stack trace: #0 /home/homann/public_html/store/includes/modules/shipping/ozpost.php(352): SimpleXMLElement->__construct('4a??<?xml versi...') #1 /home/homann/public_html/store/includes/classes/shipping.php(114): ozpost->quote('') #2 /home/homann/public_html/store/includes/modules/shipping_estimator.php(133): shipping->quote() #3 /home/homann/public_html/store/includes/templates/template_default/popup_shipping_estimator/tpl_main_page.php(16): require('/home/homann/pu...') #4 /home/homann/public_html/store/index.php(97): require('/home/homann/pu...') #5 {main} thrown in /home/homann/public_html/store/includes/modules/shipping/ozpost.php on line 352
As line 253 is
My guess is that the errior is in the presceeding line;Code:$xml = new SimpleXMLElement($qu) ;
Code:$qu = $this->_getAPdata($SERVER, "/postage.php?fromcode=" . MODULE_SHIPPING_OZPOST_SPCODE ."&destcode=$dcode&weight=$parcelweight&height=$parcelheight&width=$parcelwidth&length=$parcellength&value=$ordervalue&flags=$flags&$method=$method&host=$HOST&version=$VERSION") ;
Can anyone help me figure out what is going on?
Thanks,
Peter.
Quote:
Originally Posted by Arliss61
Rename this again so that it *doesn't* end in ",php"
Cheers
Rdo
this is probably a totally nOOB question but I have just updated the shipping module (installed) and got rid of the old Austpost one..
But now when I go to check out I have no Shipping Displaying just "Store Pickup"
And yeah I have the module installed and setup .. Am I missing something stupid.. I have been trawlling through here for about 2hrs looking for info.. But I'm coming up with nothing...
ah ok so it thinks the items are KG not grams, even though nothing has changed on the site only the shipping module and I have gms selected in the ozpost admin section... will keep digging..Quote:
Originally Posted by baldcat
I'm getting a blank main_page=checkout_shipping page.. God I hate Zen-cart (most of the time)
Quote:
Originally Posted by RodG
Dear Rod,
Thank you for your reply. I know all to well how stressfull it can be when everything goes wrong at once, and you're the only one available who can fix it.
Switching to php5 half worked. The estimate shipping window now comes up ok, but when proceeding through to checkout the screen still goes blank. Once I did a refresh and it came out ok, but after that all I got was blank screen.
I'll fool around some more with it myself and try to pin down the problem.
Thanks Rod.
Rod
You are wise in the way of PHP :) I now have my control panel back.
However the original fatal error persistsQuote:
Originally Posted by RodG
and appears to be the same one Peter http://www.zen-cart.com/forum/showpo...&postcount=228 is referring to although the line number is different.Quote:
Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: Entity: line 1: parser error : Start tag expected, '<' not found in.../shop/includes/modules/shipping/ozpost.php on line 345
Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: 6d in .../shop/includes/modules/shipping/ozpost.php on line 345
Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: ^ in ....shop/includes/modules/shipping/ozpost.php on line 345
Fatal error: Uncaught exception 'Exception' with message 'String could not be parsed as XML' in /shop/includes/modules/shipping/ozpost.php:345 Stack trace: #0 /shop/includes/modules/shipping/ozpost.php(345): SimpleXMLElement->__construct('6d??<?xml versi...') #1 /shop/includes/classes/shipping.php(114): ozpost->quote('') #2 /shop/includes/modules/shipping_estimator.php(133): shipping->quote() #3 /shop/includes/templates/charcool/templates/tpl_shopping_cart_default.php(173): require('/home/charcool/...') #4 shop/includes/templates/charcool/common/tpl_main_page.php(121): require('/home/charcool/...') #5 /home/charcool/public_html/shop/index.php(97): require('/home/charcool/...') #6 {main} thrown in /home/charcool/public_html/shop/includes/modules/shipping/ozpost.php on line 345
For him it's line 253 for me 345 but the ozpost.php code is identical:
In debug mode a quote is being sought from the Ozpost server and contact made.Quote:
$xml = new SimpleXMLElement($qu) ;
In the first instance the error message above appears in the shopping cart, if I refresh the screen, the estimator pops up: sometimes with just the "Walk In" option or on some products that I haven't already selected (so non cached quotes I guess?) with a quote for all AP domestic Shipping options not just the ones selected in the contol panel and with different handling costs to those nominated in the Ozpost set up.
In Ozpost I have selected only registered and express parcel options, both with with a $4 handling charge, but this is what I get back after I refresh the shopping cart when it presents the fatal error message:
Any clues? And thanks again for helping get my control panel back.Quote:
Aussie Post 0 0 days Est Delivery (Includes $0.00 Packaging & Handling ). $0.00
Aussie Post 3Kg Prepaid Satchel 3 3 days Est Delivery (Includes $0.00 Packaging & Handling ). $9.90
Aussie Post 3kg Prepaid Satchel Express 1 1 days Est Delivery (Includes $0.00 Packaging & Handling ). $11.30
Aussie Post Regular Parcel 3 3 days Est Delivery (Includes $0.00 Packaging & Handling ). $11.50
Aussie Post Cash On Delivery 4 4 days Est Delivery (Includes $0.00 Packaging & Handling ). $21.70
Aussie Post Registered Parcel 4 4 days Est Delivery (Includes $8.00 Packaging & Handling +$ 2.8 fee). $22.30
Aussie Post Express Parcel 1 1 days Est Delivery (Includes $8.00 Packaging & Handling ). $29.50
cheers
Gene
Technically speaking, that was a 'zencart' issue in that zencart loads any file it finds with a .php extension.Quote:
Originally Posted by Arliss61
Needless to say, I learned this from experience in having done exactly the same thing that you did. Had me going around in circles for several hours trying to figure out what I'd broken.
OK, this is 'normal' operation. The debug mode is designed to show what is being returned by the server *before* any filtering based on the control panel selections.Quote:
Originally Posted by Arliss61
This is telling us that the connection to the server is all ok. Well, at least during those time that you get a response.
As for the fatal errors, is this still occurring (from the time you read this reply?)
If so, then it still needs further investigation, but if all is working ok now I think I know the cause.
It appears that there was a glitch in the DNS records when we changed the delegation to the new servers. Instead of the old nameservers being replaced by the new ones, they were added in addition too the old ones, This meant that 2 of the 4 nameservers were pointing to the correct (new) quotation servers, but the other 2 were still pointing to the old servers (offline).
The end result being that approx every second quote request was being directed to a server that no longer exists.
Changes to DNS delegations can take up to 24hours to propergate around the globe, which is why it took a couple of days for the ill effects to show, a day or two for me to realise what the heck was going on, and now another couple of days for the now corrected information to repropergate.
I only made this discovery about 20hours ago, so *some* servers may still have invalid data.... All being well things *should* be fully stabilised within the next day (tops), but most servers should already be feeding out correct information.
Cheers
Rod
Hi Rod,
I'm currently using the AusPost (Serna) module, and have realised that there are now newer modules to replace it.
I've just spent a couple of hours downloading and reading up about the AusPost - Improved module, trying to see if I could expect any issues moving from the old to the new. At the last minute, I stumbled across a post which mentioned 'Ozpost'!
On checking out Ozpost, I found your comment 'Replacement module for the "AustPost Improved" (which is no longer supported)'.
I really hadn't had a hint that "Improved" wasn't the definitive Australia Post calc module until that point!
Would it be possible to add a comment to the AusPost and AusPost - Improved download pages to alert people to the fact that they have been replaced by OzPost?
Thanks!
Am also having the "Uncaught exception 'Exception' with message 'String could not be parsed as XML'" error reported by others in ozpost, on line 345.
Have just upgraded to php 5.2.10 so not sure if that is related to the problem or not..? It doesn't matter how many times I refresh, I always get a blank page and do not get it coming up every second or third time as I would expect if it was a DNS problem. Turning on debug mode for the module returns a whole lot of info about package data which suggests to me it is communicating with the server? Looks like the problem is something to do with how the response is parsed by the module...? Don't understand enough about object oriented code or xml to be able to debug this but just wanted to flag that another person was having this same problem.
Look forward to a solution or ideas that will help.... Any help with this problem appreciated!
I have nothing to do with the AusPost module.Quote:
Originally Posted by skybluepunk
I created AustPost improved (several years ago) as an improved alternative. If Serna's module has been working for you there would be no reason why it shouldn't continue to work. In which case I suggest you stay with it at least until I can resolve all of the current issues going on with ozpost.
Personally I wouldn't/couldn't do this with Serna's module, it wouldn't be right for me to do so as I am the author of an *alternative* to his module.Quote:
Originally Posted by skybluepunk
Being the author of both AustPost - Improved and ozpost I *could* in good conscience suggest that ozpost has superceded the AustPost module, but as has been highlighted, the ozpost module is still quite new and hasn't had a good long test like the austPost module (which until recently gave people the option as to whether to upgrade or not.
As a result of our current server issues, this choice has now been removed because the AustPost - Improved module is no longer operational, but I simply have far to many other more important issues to deal with before even considering updating the download page to reflect this information. THERE IS NO REASON WHY SOMEONE ELSE CAN'T DO IT though.
The current situation isn't pretty.
Serna's module may or may not work. It isn't affected by our current server issues.
AustPost - Improved will only be able to quote for parcels (no letters or satchels), and will probably be somewhat intermittent anyway, and will probably need 'patching' for reliable operation so that it only uses the 'drc.edeliver.com' server and not the 'austpost.vcsweb.com' server.
The ozpost module (the only module that I now support) *should* be working and fully functional, but it does need your ISP to support php5.
There *may* still be an issue with the ozpost module that produces .xml errors, I'm hoping this is a transient issue because some DNS servers are handing out stale data. I/we need to wait a couple of days for the DNS to stabilise before I can determine if this is the case or not.
If things do stabilise then all problems are solved.
If .xml problems with ozpost still exist in a couple of days then there is probably an as yet undetermined bug in the code that has only just revealed itself and will need further investigation.
Hopefully this clarifies the situation.
Rgds
Rod
Just an idea - In the interim could we change our ozpost modules to bypass DNS resolution and go straight to the correct server on the IP? Could you post the IP addresses of the "correct" servers so we could put them in to test whether it's a DNS resolution issue....?
Using the IP won't work. Like almost every ISP on the planet we use name based hosting (which makes it possible to host more than one domain on a single server).Quote:
Originally Posted by belabela
Testing is easy. Use the following link:
http://ozpost.vcsweb.com/postage.php...=100&value=100
If you get a valid response you are connecting to the right server. Anything else would suggest a probably DNS problem.
Feel free to change the postcodes, weights, dimensions, etc in the link if you wish to experiment.
Some web browsers display the resultant page in a more readible form than others (I suggest you use firefox).
Cheers
Rod
Hi Rod,
Thanks for your prompt reply, and the detailed update.
The original AusPost is working fine for me at the moment, but I'm looking forward to using the extended capabilities of OzPost once it's all sorted.
Hope it all calms down for you soon :-)
The link you provided is working fine - can get an xml result back from that without any problem.
Turning on debug mode for the ozpost module, and telling the module to spit out the value of $qu before it hits line 345, it seems to me that not returning data in xml format? under some conditions which is then throwing line 345 which tries to process the xml...?
Not sure what triggers it to work/not work as have another site on the same server that is working absolutely fine without any problem....? Can't find any material differences between those two sites at all.
Putting in the code die ($qu);exit after the $this->_getAPdata line in the offending module, returns
324 PPS39.94 3Kg Prepaid SatchelPPSE311.31 3kg Prepaid Satchel ExpressRPP11.6 4 Regular ParcelREG14.45Registered ParcelEXP17.3 1 Express ParcelCOD21.85Cash On Delivery 0 2.8 0
shouldn't this be xml? or did I do something wrong.
I'll sit on it until tomorrow to see if further propagation fixes it, but just wanted to raise this as a potential problem in case it raises any flags for you and is indeed a bug. hope this helps.
fingers crossed.
Velly Interllesting. Could you please do me a big favour and do the debug test on both your sites to see if you can see any difference in regards to the xml?Quote:
Originally Posted by belabela
You are doing all the right things, and yes, the data should be xml (which is why I'd like you to do this same exersice on both sites).Quote:
Originally Posted by belabela
There are three possibilities here...
1. The server isn't always returning valid xml for some reason (you should probably see the difference between your two sites).
2. The server is returning xml, but the xml tags are being stripped when displayed to screen. This is what happens when I use that test link using MS Explorer rather than Firefox.
3. Still a mystery.
Your findings could be very important and valuable clues, especially since you appear to be in a rare position to have two sites operational, one that exhibits a problem and the other doesn't. If these two sites consistantly behave this way I have a feeling that I will be relying heavily upon you to help me find the cause (and therefore the fix).Quote:
Originally Posted by belabela
As you can imagine, since none of the sites that I maintain (or have direct access too) don't exhibit any troublesome behaviour it is going to be impossible for me to work alone to solve the issue, so any clues, no matter how small is most welcome.
Cheers
Rod
ps. I wonder if it has anything to do with wether the server access is via 'cURL' or the http (file) method. Which of these do you use on your sites?
Hi Rod,
Our clients and we are seeing an error message to do with VCSWEB error?
Code:Services will be restored ASAP.
We apologize for any inconvenience.
Telnet/SSH members,if you can't login please use "herbie.vcsweb.com" instead of 'vcsweb.com"
FreeDNS Users - It was abuse of this system that has caused all of our current problems. This service is no longer available. The nameservers themselves have just been brought back online on a temporary basis. We suggest you use a network tool (dig, nslookup, etc) to recover any zone data that you require and migrate to alternate nameservers as soon as possible. We recommend www.xname.org
Web/Email Customers - We are doing all we can to migrate your data to new servers with minimum disruption to services. If you are getting authentication errors when trying to pick up your email you will need to update your LOGON name from "yourname" to "yourname@yourdomain".
No other changes should be required.
Please send us an email for any other issues. admin @ vcsweb.com
Could you shed some light on this??
Have established that the problem is not dns, but something to do with how the data gets translated after it comes back from the server. The server IS connecting and returning valid xml.
Here's how I established that:
- Put some code into the getAPdata function to write the request url to a file
- Put the request url into a browser manually and inspected the result
- Copied the result from the browser manually into the $xml = SimpleXMLelement line in the code and ran the shipping estimator: yes, it returned results okay.
So the problem is how the data is translated in the getAPdata function - the data variable being returned must be somehow being corrupted in the site that is working versus the site that isn't.
Am running some more tests in the getAPdata function on the site that is working and the site that isn't and comparing the results. Will report back when I can. Any ideas or things to look at appreciated as my php coding skills are pretty basic.
p.s. I have been using http but changing to curl doesn't seem to make a difference
Here is what is being returned by the getAPdata function when it is not working....
There's an extra 3d appearing at the start of the text and a '0' at the end. If you run the url that generated this in a browser, you get:Code:3d
<?xml version='1.0' encoding='ISO-8859-1'?>
<quotes>
<quote>
89
<id>PPS3</id><cost>9.9</cost><days>4
</days><description>3Kg Prepaid Satchel</description></quote><quote><id>RPP</id><cost>10.5
</cost>
25e
<days>4
</days><description>Regular Parcel</description></quote><quote><id>PPSE3</id><cost>11.3</cost><days>1
</days><description>3kg Prepaid Satchel Express</description></quote><quote><id>REG</id><cost>13.3</cost><days>5</days><description>Registered Parcel</description></quote><quote><id>EXP</id><cost>14.2
</cost><days>1
</days><description>Express Parcel</description></quote><quote><id>COD</id><cost>20.7</cost><days>5</days><description>Cash On Delivery</description></quote>
<information>
<insurance>
0 </insurance>
<registration>
2.8 </registration>
</information>
</quotes>
0
Any ideas what could be causing this and how to fix? Off to try the site that does work now with a similar product/weight/destination setup...Code:<quotes>
−
<quote>
<id>PPS3</id>
<cost>9.9</cost>
<days>4
</days>
<description>3Kg Prepaid Satchel</description>
</quote>
−
<quote>
<id>RPP</id>
<cost>10.5
</cost>
<days>4
</days>
<description>Regular Parcel</description>
</quote>
−
<quote>
<id>PPSE3</id>
<cost>11.3</cost>
<days>1
</days>
<description>3kg Prepaid Satchel Express</description>
</quote>
−
<quote>
<id>REG</id>
<cost>13.3</cost>
<days>5</days>
<description>Registered Parcel</description>
</quote>
−
<quote>
<id>EXP</id>
<cost>14.2
</cost>
<days>1
</days>
<description>Express Parcel</description>
</quote>
−
<quote>
<id>COD</id>
<cost>20.7</cost>
<days>5</days>
<description>Cash On Delivery</description>
</quote>
−
<information>
<insurance>
0 </insurance>
<registration>
2.8 </registration>
</information>
</quotes>
Could the problem have anything to do with chunked transfer encoding?
http://en.wikipedia.org/wiki/Chunked_transfer_encoding
That could explain the 0 at the end but not sure if it is the actual explanation. I'm just throwing ideas out there....
I had the path to curl wrong - using curl DOES seem to fix the problem!
This suggests to me that the chunking transfer with http method does seem to be the problem with the http method - at least on my installations - as it is corrupting the xml. Not sure how to change the getAPdata to test for chunked transfer method and to correct for it as my php skills are not good enough nor how to check the xml returned to look for and catch the line 345 error before calling simplexmlelement.
one major difference between the site that works and the one that doesn't is that the one that does not is using mod_deflate on the server for compression (hence the chunked transfer mode) whereas the one that doesn't is not.
So it seems to me that the tempoary fix if you're having the problem is to turn curl on. Make sure you're using the latest template file too, because otherwise the destination postcode doesn't always get passed to the shipping estimator.
RodG,
It looks like the server is running, but my Checkout process still just gives me a Blank Page at main_page=checkout_shipping.
The estimator is working, returning the correct costs, but customers cannot check out. I havent changed anything in Zen, apart from setting up Flat rate shipping.
No PHP errors are logged, just a blank page, when ozpost is enabled
Your help appreciated.
I had this problem and solved it by setting the use Curl to true.Quote:
Originally Posted by remoteone
Cheers,
Peter.
Hi Rod,
Heres some noted bugs.
When the weight of the products are small as in .0001Kg the server reports a weight error. I needed to increase the weight to five times this much to be accepted. These are small IC's and thats why they weigh so little.
Also as noted with remoteone above I get a blank screen on checkout; however the estimate shipping page is ok.(mostly).
I have to do a refresh to get something shown, and it looks wrong.
If I go back to my old shopfront which runs on zencart 1.3.7 this problem does not occur. My new shopfront runs on 1.3.8 and the problem occurs. I haven't been able to try disabling curl as suggested because I deleted all the files and will need to try again later.
With my old auspost_improved module no longer working, and apparently will not again I'm stuck on flat rate for the moment. I don't think the current ozpost module was ready for release, or at least not to so many people. Unfortunately with the old module going down every one has been jumping onto the new module and its clearly not ready.
Thanks Peter,
You mean "admin>my store> cURL Proxy status" ?
with cURL Proxy status = true and
cURL Proxy Address = not set
The estimator wont work either. nothing "ozpost" works at all now.
What address do I use foe cURL Proxy Address ?
Cheers.
Quote:
Originally Posted by remoteone
No, not there. It's about 2/3 way down in the options when you edit ozpost under admin>modules>shipping
the option is use "cURL". I had to say yes to get it to work.
Cheers,
Peter.
I just did a test with the weight. I used a product that weights 0.15KgQuote:
Originally Posted by p1drobert
When the order contained from 1 to 3 units (0.15Kg to 0.45Kg) I got the
errorCode:Unexpected error (no valid methods). Using AP Flat Rate.
When I added the 4th unit the total weight is 0.6Kg and I get the correct postage options.
Cheers,
Peter.
Hi,
In addition to my previous post.
Setting use curl to Yes, does not get rid of the blank screen.
What about you remoteone?
I ran the debug option to see if anything unusual comes up and I get this
Attachment 6521
Doesn't appear to be anything unusual.
Hi peter,Quote:
Originally Posted by Peter Homann
Yes, I got the same error, although for a lot less weight. I've got a tare weight on the packaging boxes of about 0.1kg. It might have something to with the error occurring at different weights. I don't know, but there's definitely a weight error happening.
Peter,
Yes, ozpost now working by setting the use "cURL"option .
Thanks.
Hi there,
Have just tried installing the new ozpost module and have received the following error message:
Shipping Modules
Warning: include(/home/homebru/www/www/includes/languages/english/modules/shipping/ozpost.php) [function.include]: failed to open stream: No such file or directory in /home/homebru/www/www/AdMin09/modules.php on line 173
Warning: include() [function.include]: Failed opening '/home/homebru/www/www/includes/languages/english/modules/shipping/ozpost.php' for inclusion (include_path='.:/usr/local/php5/lib/php') in /home/homebru/www/www/AdMin09/modules.php on line 173
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 67 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 69 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 70 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
Warning: Missing argument 4 for template_func::get_template_dir(), called in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 97 and defined in /home/homebru/www/www/includes/classes/template_func.php on line 42
any help would be greatly appreciated. I have taken great care in uploading the files to the correct locations but?
Nicki
In an attempt to fix this myself I uploaded
includes/modules/shipping/ozpost.php
to:
includes/languages/english/moduls/shipping/ozpost.php even though this wasn't in the ozpost download. The error I get now is:
Fatal error: Cannot redeclare class ozpost in /home/homebru/www/www/includes/modules/shipping/ozpost.php on line 647
I have now removed it and am back to my original post.
Sorry if I am missing something totally obvious...
Nicki
I apologise if anyone has started looking into this but I realise that I hadn't used the very latest version of ozpost. I have installed it now with no error messages:)
I do have a question however. When somebody orders 4x a 2kg object (total 8kg) the calculated shipping is the same as for 1x 2kg item that is $12.45 - soes this make sense?
Nicki
...part 4!! I have been assured that that estimate is OK ...
so basically I no longer have any issues:smile:
I found my problem here. Mayber it is relevant to you as well.Quote:
Originally Posted by p1drobert
I set my weights as Kgs, as in 0.4kg 0.15kg etc.
When I installed ozpost, I mistakenly set the weight to gms and NOT Kgs.
When I changed it to Kgs the error went away.
With my error set up, ozpost was failing when the total weight was less than 0.5gm Not a surprise really :)
Maybe you have the same error?
Cheers,
Peter.
Hmm, where are you seeing this?Quote:
Originally Posted by kaety
What you are seeing is our default webpage, which should only happen if you go to our site with a web-browser. (ozpost.vcsweb.com and our client's website sites have a higher priority in regards to our restoration efforts)
If you are somehow seeing this from within zen-cart please supply the URL to your store 'cos I'd need to check this out for myself.
Rgds
Rod
Excellent! I think we are getting somewhere. I rally do appreciate the effort you have put into this, and sorry for not being able to give you more timely responses, the timezone differences are mainly to blame for this. I'm here when you should be sleeping, and you've been debugging whale I've been sleeping.Quote:
Originally Posted by belabela
This is all new to me, so I'm not sure how to test either.Quote:
Originally Posted by belabela
Thanks. I've taken note of this too.Quote:
Originally Posted by belabela
I'm not sure I'd call this a temporary fix, because cURL is actually the *preferred* method these days (it is more secure than http for the ISP). In fact many ISP's have disabled the http method.Quote:
Originally Posted by belabela
This is why the module gives a choice, some ISP's don't allow the http method, and others have been slow to implement cURL.
In short, I would consider cURL to be the permanent fix. At least for those that are able to use it.
Wise advise. Although this template file is actually optional,Quote:
Originally Posted by belabela
upon first quote, unless a user is logged in, the module doesn't have a destination postcode to work with, so one of the tweaks I made to this file was to check if a postcode exists, and if it *doesn't*, it outputs a store disclaimer and an input box to force a postcode entry, else it'll try to quote a parcel to nowhere, which is sure to return an invalid response.
Anyway, once again I thank you for your help.
Cheers
Rod
Anything to do with weights is not really a bug. It is invalid input data.Quote:
Originally Posted by p1drobert
Use cURL (if possible and you haven't already done so).Quote:
Originally Posted by p1drobert
cURL needs enabling, not disabling.Quote:
Originally Posted by p1drobert
The ozpost module was released seven months ago. All problems reported since then have been fixed.Quote:
Originally Posted by p1drobert
If people have tried it during this time, found they had a problem and didn't bother to report it, as I now suspect is the case, then I can only say that it is their own fault for finding themselves in the current situation.
Likewise, it has been made well known (via these forums) that the old AustPost module is no longer supported and has been giving erronious quotes (due to changes in postage costs) since July, so they've had ample time to notice this and upgrade and report any issues with the new module.
I can only do testing and debugging on servers I have access to. I find it almost impossible to believe that not a single person has experienced the current problem before now. Why hasn't it been reported?
The real pisser is that now the problem has been highlighted I simple can't spend the time finding a solution since I have far to many other issues to deal with.
Getting the ozpost server migrated and operational again was a high priority, especially since I'd figured there were no bugs to fix with the client software. It is somewhat annoying to find that this isn't the case, but the timing couldn't be worse.
Cheers
Rod
Hi rod,Quote:
Originally Posted by RodG
thanks for the reply. I realize the pressure you're under. I do custom electronics design myself.
These same weights seem to work fine with the old AUSTPOST module. The old AUSTpost module was great and I miss it. I fail to see how adding one of these items creates an error but adding 5 does not if its not a bug, Any other heavier product does fine too so I'm not sure what you mean "not a bug". Never mind, as I can live with that as long as I can figure out why I'm getting a blank page at checkout.
By this I take it you mean set the USE CURL question to YES.Quote:
Use cURL (if possible and you haven't already done so).
Yes have done this but still get a blank page. Is there another setting on my host server that I need to activate as well?
As I said, I liked your old module so much that I saw no reason to shift to the new one. Until recently when the old one stopped working. I expect a lot of people are doing the same now which might explain why there's more problems reported now than 6 months ago. Also the problem does not occur with zencart version 1.3.7, only for 1.3.8. I have a backup zencart running on 1.3.7 so I was able to check this. Human nature being what it is, any one that tried the new module and found it not to work would probably just go back to the old one and not worry about it. This time we can't go back to the old one.Quote:
The ozpost module was released seven months ago. All problems reported since then have been fixed.
If people have tried it during this time, found they had a problem and didn't bother to report it, as I now suspect is the case, then I can only say that it is their own fault for finding themselves in the current situation.
I've noted this odd occurrence. If icons are enabled the icon next to the ozpost module in the shipping page is missing. The properties show
myurl/catalog/admin/DIR_WS_TEMPLATEStemplate_default/images/icons/ozpost_logo.jpg
This is clearly wrong. The DIR_WS_TEMPLATE seems to be interpreted as part of template_default string. I'm wondering of this might have something to do with the problems I'm noticing.
Hi Peter,Quote:
Originally Posted by Peter Homann
Thanks for your reply. No, I already had my weights and the ozpost module set to kg. Heavier weights have no problem.
I suspect there's some sort of truncation of a few decimal points happening before it gets to the ozpost server.
My guess is that it is sending a weight of 0 that causes the problem. Is it possible to add a line into the php that checks for this and if so sets the weight to a minimum value?Quote:
Originally Posted by p1drobert
Cheers,
Peter.
I've just been doing some testing because I've got the same problem with a store.
I've always had my weights set to kgs and was previously using AustPost - Improved, no TARE.
The tests I did so far with OzPost are as follows:
1 item 0.2kgs = unexpected error (no valid methods). Using AP Flat Rate.
2 items at 0.1kgs each = quote obtained for regular parcel and 500g satchels
2 items at 0.05kgs each = quote obtained for regular parcel and 500g satchels (I'm assuming this is because of my dimensions H2 x L10 x W15)
It looks so far like the problem is with single item purchases. However, I have tried single item purchases at higher weights and they work. Just trying to find out what the threshold weight is for this right now.
Cheers
Andy
Quote:
Originally Posted by Peter Homann
Single item weight limit to get a quote is 0.51kgs. It gives quotes for regular parcels and 3kg satchels.Quote:
Originally Posted by ionebusiness
Peter/Rod
Use of the cURL option in the Ozpost control panel appears to have removed the uncaught exception error on my charcool site as well.
Don't understand why it began playing up and don't understand why cURL option appears to have it normal again but I am extremely grateful for for your help.
For my homework, I'll go back over the posts to try and understand the detail :0
Thanks again
cheers
Gene
If you enable the debug option you'll note that no parcel will ever be quoted with a value of '0'. This *will* cause problems, so any zero weight items get assigned a value of 1gm.Quote:
Originally Posted by Peter Homann
I suspect that the problem many of you are experiencing with the new module is due to a small change of the logic between the old AustPost Module and the current ozpost module.
With the old module/server, any small (letter size & weight) items would *always* return a quote from the server, this would include both letter rates and parcel rates (for the same item). If the letter rates were disabled, then only the parcel rates were shown, else both rates were shown. It did this by forcing a minimum size/weight before seeking a quote for the smallest parcel allowable (after the letter rate quote had been obtained).
With the new module, this isn't the default case, if the item/parcel is letter sized then ONLY the letter rates will be returned, and if letters are disabled there will be no quote to provide (not an error) and therefore no quote given at all.
To emulate the same functionality as the old module you'll need to untick the 'hide parcel rates if letter sized'. This will then allow letters to be quoted as parcels. The main reason for making this change (and setting it this way by default) is to improve response times and minimise server load. It is silly having the server provide parcel rate quotes for anything letter sized, unless the client specifically requires this behaviour.
Besides, if the item/parcel in the cart is small enough to be classed as a letter the why not allow letters as a valid shipping method? Your customers will be much happier for it.
For this to all work correctly though valid weights and dimensions are required for all products being sold. It is no good having a large/heavy physical item and letting the module think that it only weighs 1gm (which will occur if given a weight of zero) and has no dimensions. I suspect this scenario is probably the reason why many have disabled letters as a valid shipping method in the first place.
I'm pretty sure that disabling the 'hide parcel rate' option will solve many of the weight problems that people are having.
If this is needed though it what it really means is that
either you are overcharging your customers for postage (charging parcel rates for letter sized items), OR that the weight/dimensions for your products are inaccurate, in which case any quotes given cannot be trusted for accuracy and you'll almost certainly end up underquoting for many of your parcels.
Cheers
Rod
Hi Rod
That works up to a point. The shipping costs are now being returned.
However, for my client, a single item purchase may require bubble wrap so won't fit in a letter size. A multiple item purchase would probably go with the cubing algorithm that says it has to fit in a parcel anyway. So, dimensions of the product are correct if you're trying to buy multiple items but don't allow for packaging with single items. The bottom line for this client I've got is that they need to force people into at least the regular parcel as experience shows they can't use letter sizes.
Can you point me in the right direction to the code so that I can hard code an if statement so that letters get ignored..?
Thanks for your help and quick response.
Cheers
Andy
Please accept my apologies for letting it show.Quote:
Originally Posted by p1drobert
I'm sure in time you'll come to love the new module too. Although on the surface there may not be any significant advantages or improvements, the new code is a lot more versatile and easier to maintain.... it'll almost certainly work with the yet to be released zen-cart V2 (perhaps minimal changes), and it is far more easily expandable in that new shipping methods can be easily added... eg, quotes from couriers, etc.Quote:
Originally Posted by p1drobert
OK, try this, phone your local post office and ask them to give you a quote to post an item weighing 1gm with the dimensions 1mm x 1mm x 1mm, and insist you want it sent by parcel, without changing the dimensions. They'll tell you it can't be done, and that you'll need to place the item into a larger package before they'll even consider accepting it. They'll also probably suggest you just place the item in an envelope and send it as a letter (after all, why would you want to put such a small item into a large box to force it to be sent as a parcel)?Quote:
Originally Posted by p1drobert
This is essentially what the ozpost module is telling you to do as well.
It isn't a bug, because it is performing according to real world requirements.
Technically speaking, it is the old AustPost module that has the bug because it was forcing a quote where no valid quote could really be given.
This is a maybe. IF you are getting a blank page because your data and shipping methods cannot provide a legitimate/valid quote you'll need to alter your settings to emulate the old behaviour (untick the 'hide letter rates if parcel sized), or, you can enable letters as a valid shipping method, or you can provide accurate weights and dimensions to your products and obtain accurate quotes.Quote:
Originally Posted by p1drobert
However, if you are getting the blank page because the server can't be contacted (possibly because your ISP doesn't have cURL installed (unlikely) , or that they use a proxy server for cURL requests (possible), then you'll need to need to define your proxy settings located under the zencart configuration/myStore settings.
Even though it has been giving invalid quotes for the last few months? (Surprised you hadn't noticed).Quote:
Originally Posted by p1drobert
I accept that most people don't like change, and that many are what I can only consider either lazy or selfish by not reporting the problem(s) when they discovered it, but there is only so much that I can do alone. This wasn't a planned change, I had no more warning than anyone else, so I'm doing my best to not feel personally guilty about the current scenario... the guilt needs to be shared :-)Quote:
Originally Posted by p1drobert
Yes it is, and in fact is one of the more recent bugs that has been taken care of (it only seems to affect some people/servers, most notibibly those stores hosted on Windows based servers). This is a 'cosmetic' issue only and has no effect on functionality.Quote:
Originally Posted by p1drobert
You can resolve this particular issue by downloading
http://www.zen-cart.com/forum/attach...7&d=1252290889
Hope this helps.
Cheers
Rod
To ignore letters, simply don't enable them as a method.Quote:
Originally Posted by ionebusiness
By default this will produce *no* quote at all for letter sized items.
To force a parcel rate quote on these items untick the 'hide parcel rate if letter sized' option, and the items will be quoted at the *minimum* parcel rate/size allowable. Be warned, that in this scenario, your bubble wrapped item could actually be larger than the minimum size required so you'll run the risk of underquoting.
I would suggest a better option would be to enter the size and dimensions of the items as though they were already bubble wrapped. Sure this will give a compounding problem if more than one item is added to the cart (and only a single bubble wrap is needed), but at least the error will be in favour of the merchant (who can offer a rebate if the postage costs blows out too high as a result). This is far easier to do and gives better goodwill than underquoting and then trying to recover (or wearing) the difference.
Cheers
Rod
Thanks Rod. Worked a treat. Unfortunately, I can't see my client going through all their items and changing the dimensions to include bubble wrap as they've been happy with the old AustPost - Improved quotes up until now. Anyway, they're getting the results they want now so all sorted.
Dude, don't apologize. You're doing this for free. I'm amazed at your efforts as it is.Quote:
Please accept my apologies for letting it show.
Quote:
This is a maybe. IF you are getting a blank page because your data and shipping methods cannot provide a legitimate/valid quote you'll need to alter your settings to emulate the old behaviour (untick the 'hide letter rates if parcel sized), or, you can enable letters as a valid shipping method, or you can provide accurate weights and dimensions to your products and obtain accurate quotes.
However, if you are getting the blank page because the server can't be contacted (possibly because your ISP doesn't have cURL installed (unlikely) , or that they use a proxy server for cURL requests (possible), then you'll need to need to define your proxy settings located under the zencart configuration/myStore settings.
Sadly the hide letter rates were already set to NO. My server curl info is shown below.
cURL support enabled
cURL Information libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.8 libssh2/0.18
Still a blank page.
I don't think its a curl issue. Or an issue with sizes and weights as the estimate shipping page works every time. How is the estimate shipping page different from the proceed through to checkout page?
This is what I know so far. That the estimate shipping page works every time. That sometimes when I do a refresh of the blank page the actual shipping information comes through. Or ar least some of the rates comes through as I noticed one time that the ECI costings were missing.
That if I run the same module with the same settings from my zencart 1.3.7 installation (which I no longer use) that it works every time. I'm currently using the 1.3.8 zencart version.
I had trouble first setting up my 1.3.8 installation as my host uses shared sessions. I had do set up a special session path in my configuration.php files to get 1.3.8 to install properly. I'm wondering if thats significant.
Enabling the debug mode returns information indicating that the mail server responded ok, with no errors apparent.
I'm wondering if this has anything to do with my Shared SSL certificate as the url on the blank page seems to access the secure page address. My 1.3.7 version zencart doesn't have SSL enabled.
Well, that's 95% of the possibilties eliminated.Quote:
Originally Posted by p1drobert
The 'sometimes' type problems are always the most difficult to solve.Quote:
Originally Posted by p1drobert
At the moment I'll put this down as an item of curiosity, especially when there is clearly something 'permanently' amiss.
I didn't think much of this observation the forst time you mentioned it, but it has turned out to be an important clue ... in fact it actually validates what I believe the problem is.Quote:
Originally Posted by p1drobert
YES. You've actually managed to isolate the problem... I will lay 100/1 odds on this...Quote:
Originally Posted by p1drobert
There may be a link/connection between this and the session data, and you can possibly prove the point by temporally disabling SSL.Quote:
Originally Posted by p1drobert
The actual cause of the problem though IS the session data, almost 100% guaranteed.
Here's the deal....
The old AustPost module, as well as having to contact 2 different servers to obtain a full set of quotes, it also made *another* contact to the servers during the checkout to obtain just the quote that had been selected.
The ozpost module avoids the need to contact the server during checkout by caching the result of the full set of quotes and then retrieving the single/required quote from the session data.
If your session data isn't being stored/retreived properly there isn't going to be a 'method' (or quote) availalbe to use during the checkout.
This is entirely unexpected of course, so the page is just bombing out.
OK, so that is the cause.... The big issue now is how to fix it?
As suggested above, disabling SSL may effect a cure of sorts in that session data for an http:// page isn't likely to be the same session data as for a https:// page - at least not by default.
You will probably need to set up a special session path as you did in order to get it to install properly.
Cheers
Rod.
Hi Rod,
Thanks for your time.
Quote:
Originally Posted by RodG
Yes, disabling SSL allows the shipping information to be displayed. Unfortunately the payments refuse to process. I'm using direct credit card processing on my web site via Eway. It requires SSL to be enabled or it just doesn't work.
Quote:
Here's the deal....
The old AustPost module, as well as having to contact 2 different servers to obtain a full set of quotes, it also made *another* contact to the servers during the checkout to obtain just the quote that had been selected.
The ozpost module avoids the need to contact the server during checkout by caching the result of the full set of quotes and then retrieving the single/required quote from the session data.
If your session data isn't being stored/retreived properly there isn't going to be a 'method' (or quote) availalbe to use during the checkout.
This is entirely unexpected of course, so the page is just bombing out.
Is it possible to add a bypass in the ozpost module that forces two separate quotes to be made as occurred in the AUSTPOST module. Bypass the save to session info.
I'm not sure where to add this session path. My shopfront is using Database stored sessions. Shouldn't the shipping information be stored in the database? When I first had trouble installing zencart 1.3.8 I added the session path to the specific installation files. I'm not clear as to where to add the required path lines in this case.Quote:
You will probably need to set up a special session path as you did in order to get it to install properly.
It is code, so yes of course it is possible.Quote:
Originally Posted by p1drobert
If you really meant to say is it possible for *me* to do this for you I'd have to say I wouldn't even consider wasting time even looking at it.
When I do get time I'll certainly take a look to see if I can resolve the issue that you are having with your session data, because this will almost certainly take less time that what you are proposing.
That makes two of us, but without doing any research at all, I would imagine that ozpost.php would be the obvious place to start because that is where you are having the problem.Quote:
Originally Posted by p1drobert
In a perfect world I guess it should be, but this isn't a perfect world and I'm an inherently lazy person, so rather than study how zencart itself handles session data I simply chose to use the garden variety session commands that are part of the PHP command syntax.Quote:
Originally Posted by p1drobert
/includes/modules/shipping/ozpost.phpQuote:
Originally Posted by p1drobert
Perhaps a google search for setting session paths with php is and a little experimentation is in order?
it probably just needs something real simple such as
php_session_path = "/path_to_session_directory"
I suggest you NOT copy and paste that.. I'm simply guessing what the command could be.
As I said, I'll be happy to look into this one at a later date, but now is not the time.
Cheers
Rod
Hi Rod,Quote:
Originally Posted by RodG
No, I meant something along the lines of "try adding something in line xx of ospost.php" I'm not an expert on PHP but I tend to teach myself enough to get by, or at least sometimes I do.
LOL. Thats generally my philosophy as well. I just do the bare minimum to get the job done and move onto something else. Lifes too short to be anal about technique.Quote:
In a perfect world I guess it should be, but this isn't a perfect world and I'm an inherently lazy person, so rather than study how zencart itself handles session data I simply chose to use the garden variety session commands that are part of the PHP command syntax.
I've already tried setting a path instruction in ozpost.php but an error comes up as the path has already been defined in zencart. I'll tinker around with it and try to figure something out. I'll post something if I work something out.
Hi Rod,
Our old ozpost shipping module stopped working last week, does the new module work with zen version v1.3.7?
Phil.
Quote:
Originally Posted by Jour
Yes it does. I use it with 1.3.7
Cheers,
Peter.
Thanks!Quote:
Originally Posted by Peter Homann
Thanks Rod!
Works well as auspost module did :D
http://www.jour.com.au
Extracted from http://www.zen-cart.com/forum/showth...810#post790810
Re: Force Shipping Quote on certain categories?
I think I have resolved the problem of forcing a quote.
I am only using the Ozpost and Request for Quote (RFQ) shipping modules, with the solution lying within includes\modules\shipping\ozpost.php.
Within this file, to disable Ozpost and only display RFQ, immediately after (lines 67-68)
// disable only when entire cart is free shipping
if (zen_get_shipping_enabled($this->code)) $this->enabled = ((MODULE_SHIPPING_OZPOST_STATUS == 'True') ? true : false);
insert
// disable for one master_categories_id
if ((IS_ADMIN_FLAG == false && $_SESSION['cart']->in_cart_check('master_categories_id','4') > 0)) {
$this->enabled = false;
}
if ((IS_ADMIN_FLAG == false && $_SESSION['cart']->in_cart_check('master_categories_id','5') > 0)) {
$this->enabled = false;
}
if ((IS_ADMIN_FLAG == false && $_SESSION['cart']->in_cart_check('master_categories_id','6') > 0)) {
$this->enabled = false;
}
For individual products, replace ('master_categories_id','6') with ('products_id','26') etc.
Further insight can be found at http://www.zen-cart.com/forum/showthread.php?t=91394.
To force quote on Ozpost server failures, in Admin > Modules > Shipping > Australia Post (ozpost) set
Cost on Error
from 25,99
to 0,0
Hope this helps.
Is there a way I can have the following shipping options?
flat rate shipping for australian customers
and then a seperate rate for New Zealand customers
then also a flate rate for registered post
and then one for express
so four options all having a set price.
Hi Rob,
Sorry to remind you, I've mentioned previously about a minor problem regarding the international and domestic letter rates coming up erroneously. is there a quick fix to that?
Thank you again for your help!
Below is the original problem:
it seems that the international rates (specifically, letter rates) appear even though "oversea" shipping methods are all disabled. Is there any way around that as I would only require International Express for international.(Ps i'm using ozpost 1.02)
Any help would be appreciated.
There are several shipping modules available that will suit your requirement. ozpost is not one of them.Quote:
Originally Posted by kellan4459
Cheers
Rod
At the moment no. This problem can almost certainly be resolved by code changes at either the client or the server, and for consistancy (and accuracy) this is best done on the server.Quote:
Originally Posted by poohbear
I suspect in either case similar 'effort' would be required, so rather than looking for a 'quick fix' that is where I'll be heading.
Thanks for reminding me though..
I really do have it on my 'todo' list, but another reminder in another couple of weeks may not go astray.
Cheers
Rod
Hi all,
I was having the same "SimpleXMLElement on line 351" problem as some others here. I was wondering why I hadn't had any sales... Luckily a new customer emailed me, because I've been travelling and had no idea about the problem.
Setting CURL=yes in the ozpost module admin section fixed it.
Just posting here to keep track of further developments...
Shen
aum mani padme hum
No problems Rod, thanks for letting me know.Quote:
Originally Posted by RodG
I've just taken a look at this and can't seem to replicate the problem.Quote:
Originally Posted by poohbear
Do you have a URL so that I can see for myself (and monitor the logs at the same time).
It is possible that this problem may have already been fixed in the copy of ozpost.php that you can find from the following link.
http://www.zen-cart.com/forum/attach...7&d=1252290889
Cheers
Rod
Hi Rod, I'm using the latest version of Zen Cart and the latest version of Ozpost. I've just run the Debug Error Logging Utility through my almost-finished shop and it gave me three error logs. Here they are:
[13-Oct-2009 20:03:34] PHP Warning: SimpleXMLElement::__construct() [<a href='function.SimpleXMLElement---construct'>function.SimpleXMLElement---construct</a>]: Entity: line 1: parser error : Start tag expected, '<' not found in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
[13-Oct-2009 20:03:34] PHP Warning: SimpleXMLElement::__construct() [<a href='function.SimpleXMLElement---construct'>function.SimpleXMLElement---construct</a>]: 326 in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
[13-Oct-2009 20:03:34] PHP Warning: SimpleXMLElement::__construct() [<a href='function.SimpleXMLElement---construct'>function.SimpleXMLElement---construct</a>]: ^ in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
[13-Oct-2009 20:03:34] PHP Fatal error: Uncaught exception 'Exception' with message 'String could not be parsed as XML' in /var/www/html/shop/includes/modules/shipping/ozpost.php:345
Stack trace:
#0 /var/www/html/shop/includes/modules/shipping/ozpost.php(345): SimpleXMLElement->__construct('326??<?xml vers...')
#1 /var/www/html/shop/includes/classes/shipping.php(129): ozpost->quote('')
#2 /var/www/html/shop/includes/modules/pages/checkout_shipping/header_php.php(170): shipping->quote()
#3 /var/www/html/shop/index.php(36): require('/var/www/html/s...')
#4 {main}
thrown in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
[13-Oct-2009 20:05:08] PHP Warning: SimpleXMLElement::__construct() [<a href='function.SimpleXMLElement---construct'>function.SimpleXMLElement---construct</a>]: Entity: line 1: parser error : Start tag expected, '<' not found in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
[13-Oct-2009 20:05:08] PHP Warning: SimpleXMLElement::__construct() [<a href='function.SimpleXMLElement---construct'>function.SimpleXMLElement---construct</a>]: 5c in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
[13-Oct-2009 20:05:08] PHP Warning: SimpleXMLElement::__construct() [<a href='function.SimpleXMLElement---construct'>function.SimpleXMLElement---construct</a>]: ^ in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
[13-Oct-2009 20:05:08] PHP Fatal error: Uncaught exception 'Exception' with message 'String could not be parsed as XML' in /var/www/html/shop/includes/modules/shipping/ozpost.php:345
Stack trace:
#0 /var/www/html/shop/includes/modules/shipping/ozpost.php(345): SimpleXMLElement->__construct('5c??<?xml versi...')
#1 /var/www/html/shop/includes/classes/shipping.php(129): ozpost->quote('')
#2 /var/www/html/shop/includes/modules/shipping_estimator.php(134): shipping->quote()
#3 /var/www/html/shop/includes/templates/dreamy/popup_shipping_estimator/tpl_main_page.php(16): require('/var/www/html/s...')
#4 /var/www/html/shop/index.php(97): require('/var/www/html/s...')
#5 {main}
thrown in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
[13-Oct-2009 20:05:14] PHP Warning: SimpleXMLElement::__construct() [<a href='function.SimpleXMLElement---construct'>function.SimpleXMLElement---construct</a>]: Entity: line 1: parser error : Start tag expected, '<' not found in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
[13-Oct-2009 20:05:14] PHP Warning: SimpleXMLElement::__construct() [<a href='function.SimpleXMLElement---construct'>function.SimpleXMLElement---construct</a>]: 49 in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
[13-Oct-2009 20:05:14] PHP Warning: SimpleXMLElement::__construct() [<a href='function.SimpleXMLElement---construct'>function.SimpleXMLElement---construct</a>]: ^ in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
[13-Oct-2009 20:05:14] PHP Fatal error: Uncaught exception 'Exception' with message 'String could not be parsed as XML' in /var/www/html/shop/includes/modules/shipping/ozpost.php:345
Stack trace:
#0 /var/www/html/shop/includes/modules/shipping/ozpost.php(345): SimpleXMLElement->__construct('49??<?xml versi...')
#1 /var/www/html/shop/includes/classes/shipping.php(129): ozpost->quote('')
#2 /var/www/html/shop/includes/modules/shipping_estimator.php(134): shipping->quote()
#3 /var/www/html/shop/includes/templates/dreamy/popup_shipping_estimator/tpl_main_page.php(16): require('/var/www/html/s...')
#4 /var/www/html/shop/index.php(97): require('/var/www/html/s...')
#5 {main}
thrown in /var/www/html/shop/includes/modules/shipping/ozpost.php on line 345
I have no idea how to decode let alone fix these problems and was hoping you could shed some light?
I've not done anything at all to change the Ozpost module. All I've done is install it. BTW 'dreamy' is the name of my custom template.
Ta! Cafman
Good news!
It's fixed.
Before I posted my original question I tried to find a fix on these forums but couldn't figure out what search term to use, since there were so many terms in the DeBug error reports.
After I posted, I simply ploughed through every 'ozpost' message I could find here, until I came across someone who had similar probs. Your advice, Rod, was to enable 'curl' in the admin panel, which I did, and now all is well.
Love OzPost again. :D
Caf
Hmmmm,
I'm also getting the SimpleXMLElement error too, but enabling curl doesn't fix it.
I've been running the ozpost module for my old zencart 1.3.7 installation, in an effort to figure out why the ozpost module doesn't work properly with my newer zencart 1.3.8 installation.
The zencart 1.3.7 version worked fine until I enabled SSL then the SimpleXMLElement error came up. This puzzled me because with 1.3.8 the problem with ozpost is that I get a blank screen at checkout, but only if I enable SSL, otherwise it works fine.
Another piece of the puzzle I guess.
Hi Rod,Quote:
Originally Posted by RodG
Ok i've just tried updating using the new ozpost.php you have posted but it's still the same, Letters are still coming up in international orders despite having them disabled (they are enabled for domestic letters though).
I've pm the link, can you advise which logs i should look at? thanks again for your help!
Attached to this message is an updated ozpost.php file.Quote:
Originally Posted by poohbear
download, unzip, replace /includes/modules/shipping/ozpost.php with this copy.
Log onto admin, click unistall and then reinstall. (This is important).
This should take care of your problem.
Please advise either way.
Cheers
Rod
hmm, interesting quirk with the the SimpleXMLElement error (using v1.0.4).
If my store name is a single word, I get the error, but if I have a two word store name, I don't get the error
i.e. the space eliminates the problem :dontgetit
Ooop. Wrong file was arrached. Use this one instead <sigh>Quote:
Originally Posted by RodG
Tired and late/