btyner

Hey all, I think Daniel Duerr's addition of the "P.O. Box checker" is a great idea. You'd be surprised at how many of our customers try to ship Fedex to P.O. Boxes. Just one comment: on line 87, where it says (At least for the way our host's version of php interprets regular expressions) I think it ought to read in order to allow for the customers who write "PO" instead of "P.O." etc. Keep up the good work! Ben

Hello, This module was working OK but now all of a sudden it returns "Home Delivery" as the only FedEx shipping option. Any clue as to why this would be? Ben

Hi all, We're experiencing a strange phenomenon. The gatewaybeta.fedex.com/GatewayDC server is giving incorrect quotes! For example: 2.45 lbs. gateway returns $5.61, actual cost $5.70 3.50 lbs. gateway returns $5.65, actual cost $5.74 The weights were correct and this is not a dimension weight issue. I know it's only a $0.09 difference but it irks me for the gateway to return one value and then get to Fedex and have to cough up nine cents for each shipment. Any ideas? I know I could always set the surcharge to $0.09, but the difference is sometimes less than that. Thanks

Nevermind . . . I'd forgotten that we were using a mix of jpg and jpeg extensions, and so when moPics defined the extension as jpg, none of the jpegs were working. And then you can't just rename them, you have to tell the database that you've renamed them too. So now it's working like a charm; great contrib - I especially like the fact that it's not necessary to completely replace admin/categories.php unlike some of the other thumbnail contribs. Ben

Hi, I'm using this contrib just for the smaller thumbnails; not the moPics. Neither one is working though. I've read all the posts and the Install.txt and I think I'm doing it right: define('IN_IMAGE_BIGIMAGES','images_big/'); define('IN_IMAGE_THUMBS', 'thumbs/'); define('MAIN_THUMB_IN_SUBDIR', false); define('THUMBS_PER_ROW', '4'); define('MORE_PICS_EXT', '_screen'); define('BIG_PIC_EXT', ''); define('THUMB_IMAGE_TYPE', 'jpg'); define('BIG_IMAGE_TYPE', 'jpg'); with the thumbnails in catalog/images and the big images in catalog/images/imgaes_big When I click to enlarge, all I get is a blank box: for example, see http://www.playgroundforthemind.com/catalo...&products_id=41 All the permissions look fine. Any ideas appreciated. Thanks

Well, I can't say for certain what fixed it, but all of a sudden three things just started working today when I gave them a try: Fedex API module USPS API module currency updates My suspicion is that our hosting provider is allowing http connections to emanate from within again. The reason I suspect this is that in addition, lynx is working for sites other than our own (whereas before it did not). Or maybe it has something to do with cURL. This when we were just about to start shopping for a different provider! Anyway, I'd like to thank all who took their time to troubleshoot this -- Fritz Clapp, C. Osborne, Shuan "smartwork", and especially Steve Fatula. This also means that the site is now fully functional: http://www.playgroundforthemind.com Thanks again; hopefully someday I'll be able to return the favor! Ben

smartwork -- yeah; no matter what I do, the NONE never goes away. This, combined with the fact that $reply comes back blank, makes me suspect that I'm not getting into the server in the first place. I talked to someone at FEDEX and they said that the test server URL is gatewaybeta.fedex.com and that I have to send a subscription transaction/request before I get my meter number. He also said that there is not supposed to be any GatewayDC at the end of gateway.fedex.com. I've tried all three combinations and it doesn't seem to make any difference.

COsbourne, the NONE never got replaced no matter what I did. sfatula, thanks for confirming the gateway.fedex.com/GatewayDC, though you say this is the production server . . . I have NOT been added to the production server as far as I can tell, so maybe that's the problem? Anyway, see for yourself: Here's the first $data (XXXX are my attempt to protect my client - but I can assure you what was there is all correct) 0,"211"10,"XXXXXXX"4003,"XXXXXXX"4007,"XXXXXXXX"4008,"XXXXXXXXX"4011,"XXXXXXXX"4012,"XX"4013,"XXXXXX"4014,"XX"4015,"XXXXX"99,"" And the second: 0,"25"10,"XXXXXXX"498,"NONE"8,"XX"9,"XXXXX"117,"XX"17,"XXXXX"50,"XX"75,"LBS"1116,"I"1401,"1.9"440,"Y"1333,"5"99,"" both of the $reply come back empty.[/img]

I'm still getting nothing back in $reply. I was told yesterday by Fedex on the phone that we have been added to the test server, but it doesn't seem to be working. I've tried gatewaybeta.fedex.com and gateway.fedex.com/GatewayDC but I don't get a reply back. I'm not even sure that these are the correct addresses; I've been unable to find the URL for either the test or production server in any of the documentation. The folks at webAPI go home at 4:30CST. Any assistence would be greatly appreciated. Yes, PHP was compiled with cURL enabled. Yes, I put all the required info in fedex1.php as well in the admin. Yes, I made the $meterStart modification to function _getMeter()

You've done great work on all the button sets. Is there any way we can get a create_account.gif for Spanish? (to be used with the Purchase Without Account mod) The one I made isn't very good as you can see . . . . Alternatively, maybe I could get some advice on how to clean mine up to look more like the english one? versus Thanks

I noticed that in Order_Info_Process.php v.0.56fix (straight from the .zip), the file catalog/Order_Info_Process.php uses Macintosh (!) style linefeeds (i.e., ctrl M) whereas catalog/includes/modules/Order_Info_Process.php uses UNIX style linefeeds (i.e., ctrl J) This has not given me a problem as my hosting provider's Linux seems to recognize both when executing the scripts, but I wonder if some of the problems others have been having can be attributed to their particular OS not being as forgiving?

Yes I know, but that file occurs in two separate locations. hence my query.

Both files or one in particular?

I should add that techically I'm using Mozilla 1.3 (Gecko/20030312) though if it works in Mozilla it should work in the more recent versions of Netscape. Another thing, you suggest changing $password to something other than '' in Order_Info_Process.php. Tell me, is it any of these lines or a different one entirely? $password = tep_db_prepare_input(''); $pass_ok = tep_validate_password('', $check_customer['customers_password']); setcookie('password', ''); Also, should I make the changes in /catalog/Order_Info_Process.php or in /catalog/includes/modules/Order_Info_Process.php (or both?). Thanks, Ben

Well, both the main page and subsequent checkout have the following message in the upper right: Parse error: parse error, unexpected T_STRING in /usr/local/psa/home/vhosts/mainframes.co.uk/httpdocs/test/includes/boxes/best_sellers.php on line 23 But the functionality is all there. Though the lower portion of the righthand box is filled in with blue. This also happens on my site if someone's window is too small or if they are at 800x600 or less. This may be endemic to the default OSC checkout as well.[/img]