Jump to content

robweidman

Members
  • Content count

    14
  • Joined

  • Last visited

1 Follower

Profile Information

  • Real Name
    RobW
  1. robweidman

    FedEx - Web Services v9

    Just an update that EIG is no closer to resolving this than they were back in the summer of 2011. Here's a quote from someone I've been working with from an EIG-related ISP: "Hi Rob, I want to give you a quick update as to where we stand with this: I was able to determine that while we have the PEAR SOAP module installed on our system, we do not have PHP SOAP installed. As a result, we will have to recompile PHP with SOAP support to rectify this situation for you. As I'm sure you can imagine, recompiling PHP for our entire customer base is not something that can be taken lightly. While I am confident we will find the best way to go about this, I can't really say for sure when we will execute that plan. My hope is that it will be completed before May of this year, when FedEx plans to make their changes, but I really can't say for sure right now. If I hear anything else about this project, I will be sure to update you. Until then, please let me know if there is anything else we can assist you with. Thank you, Dan Gorman Technical Support Manager FatCow Web Hosting" It's hard to imagine that other OSC-based sites aren't screaming about this. Is everyone waiting until the last minute? One or two of us can't make this happen, as EIG doesn't seem to appreciate the potential impact. For my own interests, I'll have to leave my present provider and am not waiting until May 2012. I'm curious what others are experiencing. Am I completely missing something?
  2. robweidman

    Automatically send data feed to Froogle

    Jack, I really appreciate this contribution and all of the work that goes into it. It seems that no matter which contribution my site needs, most of the favorites have your hand in them, which speaks volumes of your talent and gives me added confidence. One little suggestion I'd like to make for this (and other) ReadMe files is when referencing version numbers, if the Add-on version number has crossed the 2.2 - 2.3 threshold, the description should specify whether the author is referring to the Add-on or OSC version. Otherwise, it gets confusing to the person implementing the modification. If there's a better place to post this suggestion, let me know.
  3. I just installed 2.2.3 today and ran into similar errors that others were having. The code below from ship_estimator.php starts around line 42: case 'process': if (!tep_session_is_registered ('customer_id') && (!tep_session_is_registered ('shippostcode') || !tep_session_is_registered ('shipcountry') || (!tep_session_is_registered ('shipzone') && SHIP_ESTIMATOR_USE_ZONES == 'true') ) ) { $error_code = ''; if (!tep_not_null ($_POST['shippostcode']) ) $error_code .= '&error_shippostcode=1'; if (!tep_not_null ($_POST['shipzone']) && SHIP_ESTIMATOR_USE_ZONES == 'true') $error_code .= '&error_shipzone=1'; if (!tep_not_null ($_POST['shipcountry']) ) $error_code .= '&error_shipcountry=1'; tep_redirect (tep_href_link (FILENAME_SHIP_ESTIMATOR, 'action=ship_error' . $error_code, 'NONSSL')); exit; // Don't do anything else } //if (!tep_session_is_registered I'm not a PHP developer by any means. So take this with a grain of salt. It seems to me in this section of code, that if customer_id isn't valid, along with some combination of shippostcode, shipcountry and shipzone (but only if ship_estimator_use_zones is true), then it attempts to set the values for shippostcode, shipzone and shipcountry with the $_POST. That $_POST may well have been successful, but no matter because the next line of code redirects with an error. Therefore, in order to get mine working (your mileage may vary), I added a check before redirecting. So, if the $error_code doesn't get set to something, there is actually no error and processing can proceed. case 'process': if (!tep_session_is_registered ('customer_id') && (!tep_session_is_registered ('shippostcode') || !tep_session_is_registered ('shipcountry') || (!tep_session_is_registered ('shipzone') && SHIP_ESTIMATOR_USE_ZONES == 'true') ) ) { $error_code = ''; if (!tep_not_null ($_POST['shippostcode']) ) $error_code .= '&error_shippostcode=1'; if (!tep_not_null ($_POST['shipzone']) && SHIP_ESTIMATOR_USE_ZONES == 'true') $error_code .= '&error_shipzone=1'; if (!tep_not_null ($_POST['shipcountry']) ) $error_code .= '&error_shipcountry=1'; if ($error_code != '') { tep_redirect (tep_href_link (FILENAME_SHIP_ESTIMATOR, 'action=ship_error' . $error_code, 'NONSSL')); exit; // Don't do anything else } } //if (!tep_session_is_registered Again, I'm not a PHP developer. Maybe there's a deeper issue and my solution just masked it. FWIW, the original solution, as well as this one works fine with USPS XML.
  4. robweidman

    [Contribution] - USPS Methods

    5.2.1 seems to be a good working version of this contribution. Thanks to everyone who contributed to the effort! After installing and doing a little testing, I seem to be getting good rates back. However, after uncommenting the e-mail related lines in usps.php, one of the numerous e-mails that arrived states the following: <HEAD><TITLE>HTTP Error 400</TITLE></HEAD><BODY><H1>BAD REQUEST</H1><P>Your client sent a request that this server didn't understand.<br>Request: </body></html> Is this something to be worried about?
  5. robweidman

    FedEx Direct 2.06 Support thread

    I'm no expert, but I believe the answers to your questions are "No" and "Yes". There is a new Fedex WSDL available that to my knowledge has not yet been properly wrapped for OSC use. There is an OSC Fedex rate WSDL contribution, but it is only half baked. It has hard-coded values and isn't integrated with the checkout process. I don't know to what degree the 3.0 OSC version utilizes the new Fedex WSDL. Even if it did, the task to migrate to 3.0 for most store owners would be large. Therefore, I think there is a real need to get a functioning Fedex WSDL addon available soon. Moreover, the WSDL is likely more accurate and has features that would benefit store owners and their customers, since Fedex has likely long ago abandoned this old Direct module. It would be nice to see Fedex step up and deliver something, since they're the ones who stand to lose the most on 5/31/2012. Just my 2 cents...
  6. robweidman

    [add-on] Discount Code (support)

    I too like the concept of the module. However, my site utilizes the one-page checkout, as do many others. Can anyone offer advice as to where to place the appropriate code on the checkout_shipping and/or checkout_confirmation pages? Thanks.
  7. robweidman

    free shipping by categories support thread

    I found this problem and thought it may help some others. I have a variety of addons installed and this free shipping addon seemed to work fine until I went to edit a customer's order via the admin. That's when I got a blank page. The problem was ultimately traced to the fact that an entry needed to be added to admin\includes\functions\general.php similar to what was required on the other side in the same funtion name "function tep_get_categories_name".
  8. I'm having the exact same problem as lyonsperf (Matt). There are no PHP errors per se. Things seem to go downhill from this point in products_ship_estimator.php: Line 30: $products_id = (int) $_GET['pid']; The result is the empty string. If I can be of further assistance, let me know.
  9. robweidman

    One Page Checkout Support

    Steve, I haven't reported them yet as these are just a subset of the ones I've found. It was surprising to encounter so many bugs with this addon, especially since it's almost a year old by now. At this point I have a lot of misgivings and am considering not spending any more time on it. The folks at itwebexperts haven't even seen fit to make simple changes such as using the long PHP tags instead of the short ones. Granted, that's not a bug per se, though it is inconsistent with the rest of oscommerce code. But for people who can't manage their server's php.ini settings, it's means cracking the code open and modifying it. My 2 cents. . . Rob
  10. robweidman

    One Page Checkout Support

    Not to be critical here, but after working with this add-on for several days in a development environment, I'm coming to the conclusion that it's not ready for prime time. Granted, the complexity of this is greater than most, but it's chock full of bugs. For a while I thought it might have been my implementation, but the same behavior exists on the demo website. For starters, has anyone noticed that the "Different from billing address" checkbox has no effect when calculating shipping rates? That's right, it only calcuates based on the billing address, no matter if the checkbox is checked ot not. There's another bug whereby you can have both addresses completely filled out, yet no shipping address data is being sent to the shipping modules. It's fairly simple to get it into this state, but it's difficult to say what gets it back out. At some point it does start functioning again. There's a bug in the logic for setting the icon on the State field in the Shipping Address section. It's always a green check. I'm curious if folks are really using this in a production environment, and if so have you already worked these types of issues out for yourselves, or just never noticed them? Thanks.
  11. robweidman

    Supertracker Development

    Not sure if this is the cause of your problem, but I just implemented munchies Add-on fix and it worked for many of my site's pages, but not for any dealing with checking out. I received no error messages, but the pages didn't show anything. Fortunately I was able to trace the problem to 2 extra lines left at the end of the supertracker.php file that you mention. If you overwrote that file with his copy, you might want to delete those 2 lines. I'm only a novice php developer, but seem to recall reading somewhere that blanks lines at the end of a PHP file can be problematic.
  12. I installed this addon a month or more ago (along with oscThumb) and it was working fine - great in fact. Recently I got a new camera and took some additional photos. The images were prepped in Adobe Photoshop as JPG and ultimately saved as GIF and uploaded through the OSC Admin Catalog tool. The problem is that besides the lead-in thumb images, upon clicking on one of them, all I see is a never-ending spinning. I strongly suspect that it has something to do with the new images, their format, etc. I have saved them "for Web and devices". By no means am I a Photshop expert - far from it. I have tried existing images and they work fine. I've also renamed an existing image and it works as well. For example, One that works: http://sampleurl.com/oscthumb.php?src=/images/pop_top_canvas.gif&w=508&h=325&fltr[]=wmt|abcd |25|*|000000|babelsans.ttf|2|0|0&f=gif&bg=FFFFFF&q=95&hash=9d8e5f3c232208f48df3540019d62507 One that doesn't work: http://sampleurl.com/oscthumb.php?src=/images/SVP-C8178-52.gif&w=3499&h=2235&fltr[]=wmt|abcd |25|*|000000|babelsans.ttf|2|0|0&f=gif&bg=FFFFFF&q=95&hash=9088822821e3d8714838b2b4314c033c Any ideas/guesses? Thanks.
  13. robweidman

    [Contribution] - USPS Methods

    Here's how I fixed that issue: //if (($maxins == 0) || (MODULE_SHIPPING_USPS_INSURE == 'False')) { if (($maxins == 0) || (MODULE_SHIPPING_DMSTC_INSURANCE_OPTION == 'None' && MODULE_SHIPPING_INTL_INSURANCE_OPTION == 'None')) { In addition, there is another error that's manifested just below this one, near line 162 [$shipping_ounces = tep_round_up((16 * ($shipping_weight - floor($shipping_weight))), 2);]. To fix this, the tep_round_up function needs to be added to admin\includes\functions\general.php. MountainMods' post on July 1, 2009, first identified this ommission. Unfortunately, two full releases of the addon were made since his discovery - neither one having accounted for it.
  14. robweidman

    [Contribution] - USPS Methods

    Not sure if I have the answer or a different problem. I was having trouble testing Order Edit, which I had recently installed and have traced the root of the problem to the USPS.php file that was included with 4.3.1. Around line 113, inside the Quote function is this statement "if (($maxins == 0) || (MODULE_SHIPPING_USPS_INSURE == 'False')) {". The problem is that MODULE_SHIPPING_USPS_INSURE has not been assigned a value. Notice near line 280 in the function Keys that it has been commented out. Therefore, once line 113 is executed, everything thereafter in the process flow essentially becomes null. I don't know how I'm going to fix mine just yet, but thought I'd document the issue here - perhaps to help you and in case someone else has a good idea.
×