Jump to content
Latest News: (loading..)


  • Content count

  • Joined

  • Last visited

  • Days Won


TomB01 last won the day on December 26 2014

TomB01 had the most liked content!

About TomB01

  • Birthday 12/24/1954

Profile Information

Recent Profile Visitors

6,891 profile views
  1. Yeah, I forgot the new URL was imbedded in the middle of that description up there. That's what probably broke it in the first place, but I had installed the new version of UPSXML in the interim and then developed the security issue.
  2. That error happened spontaneously. I only discovered it recently when using a test account to my store. (My store has operated for many years.) I had just experienced a recent change with USPS that broke my 1st Class Shipping (1st Class Parcel to 1st Class Package - Retail). In fixing that, I noticed that the UPS Shipping was broken, too - with that error message. My first reaction was to upgrade to the latest UPS XML as mentioned in the first post up there. That didn't fix it and resulted in the numerous posts above, until Valeriy's post up there fixed it - changing the "0" to "1" in the code of upsxml.php. That line that Valeriy references is somewhere in the middle of that file, but fairly easy to locate: $this->use_exec = '0'; The latest UPSXML contrib has the "0" as default. Anyway, changing that "0" to "1" fixed it for me. Numerous trouble chats with both UPS and my HostGator services accomplished nothing.
  3. I'll be danged - that worked! Many thanks, Valeriy! It's unbelievable how much difference it made changing a '0' to '1' on that line.
  4. There is something else going on. HostGator has proven to me that TLS 1.2 is working on my server. Yet, UPS still gives that as the reason for the cURL error 35. Ideas, anyone?
  5. HostGator says there's nothing wrong with their web services (cURL version) or my site and that the issue is with UPS. I've sent another e-mail to UPS.
  6. Still doesn't work. I even tried removing and re-installing the module. I also tried both "onlinetools.ups.com" and "www.onlinetools.com." However, the logging file error message has changed with "onlinetools.ups.com" - it now says, The e-mail from UPS had a reference to TLS V1.2. I found a reference here from Harald Ponce de Leon that said cURL implemented TLS V1.2 with cURL V7.34. My server info from the OSCommerce Admin says the cURL is V7.24. I've contacted my hosting service.
  7. OK - thanks. I will give it a shot and report back.
  8. OK, so does that mean if I go in and change all references for "www.ups.com" to "onlinetools.ups.com" it will work? The e-mail from UPS stated, "www.onlinetools.com"
  9. I've been getting the infamous "This module supports only xpci version 1.0001 of the UPS Rates Interface." error message lately. I'm running 2.3.4 and had UPSXML 1.4.0 installed, so updated to 1.6.1. That didn't fix it. After some searching on the Internet, all I found were some very dated references stating that the UPS servers had gone offline. Their problems seemed to get fixed on their own, apparently when the UPS servers went back up. Mine seemed to be lasting longer than any sort of server issue, so I created the logging file as specified in UPSXML. This is what I get as a response from UPS in the log file: So, I filed a trouble request at UPS. This is their response: Is UPSXML dead? Is there another module I can use? Luckily, I have USPS and FedEx working just fine, but I had the option for UPS if a customer chose to use it - but not anymore. Help?
  10. Outstanding! Both the UK test address and my customer's address from the Netherlands now works with no errors! Many thanks, Jim!
  11. Upgraded to V2_r3.6 Same error, with a slight change in line numbers (line number 123 changed to line number 124): The error message above is at the top of a blank screen after clicking "Continue" from the checkout page. It also generates this on the checkout at the top of the page, but displays the rest of the page with all shipping options and pricing correctly: Here's the usps.php file with lines of code before and after as requested: Again, this is an intermittent issue, depending on the country address. I have test addresses for Taiwan, Canada, and Australia - no problem. Then the one from the Netherlands fails and so does one from the UK.
  12. Thanks for all of your effort in keeping this up-to-date, Jim. I will upload the new version as soon as I can and report back.
  13. Got another one: This is failing for a customer address in the Netherlands: Warning: Invalid argument supplied for foreach() in /home1/xxxx/public_html/catalog/includes/modules/shipping/usps.php on line 123 Warning: Cannot modify header information - headers already sent by (output started at /home1/xxxx/public_html/catalog/includes/modules/shipping/usps.php:123) in /home1/xxxx/public_html/catalog/includes/functions/general.php on line 49 Attempts on usps.com seem to work with the customer's address. Also, test addresses from Australia, Taiwan, etc., have no issue.
  14. I seem to be getting a specific error with any address from Denmark: Everything seems fine otherwise. I have tried addresses for Australia, Taiwan, UK, Canada, etc. and everything works just fine. However, I get the message above on the shipping page in checkout with whatever I put in for Denmark, apparently. Proceeding further in checkout bombs out completely with the following: Is there some error with the database in using Denmark? P.S. I have UPS and FedEx shipping options running at the same time, too - with no errors. P.P.S. This seems to be locking up on the usps.com website as well. It will "Calculate a Price" OK, but then if you select, "Print Postage" it locks up completely and comes back with a "Session Timeout" message.