Latest News: (loading..)


  • Content count

  • Joined

  • Last visited

About Escaping

Profile Information

  1. I had a problem with this contrib not posting to the order total. Rates returned fine, but on the confirmation page and the final order, no shipping was included. For anyone else experiencing a similar issue, the problem turned out to be the '<' and '>' characters in the USPS return and the formatted display name. (Basically the <sup>, </sup> and <br>). It may be that it was running afoul of one of our security scrubbers. Not sure there. As a solution, any place I found: 'title' => $title, (there are 4 in all) I switched it to: 'title' => str_replace(array('<sup>', '</sup>', '®', '™', '<br>'), '', htmlspecialchars_decode($title)), That solution actually removes the reg mark which some may object to. To leave it, I suspect you'd use: 'title' => str_replace(array('<sup>', '</sup>', '<br>'), '', htmlspecialchars_decode($title)), I haven't actually tried that. Removing the <br>, when you're using some of the optional displays such as signature conf or insurance, could prove to be very odd looking when displayed. Again, I din't want all that so it wasn't an issue. Hope that helps someone else out. Art
  2. Hey Kurt, Without any version info, not sure. I do recall seeing another poster describing the strange characters in their responses. I don't recall who the poster was, but if you search the forum for just USPS Methods, you'll find him among the first 2 pages. As a side note, if you're using an older API, USPS is about to stop supporting you in the first quarter of next year anyway. Might be an opportune moment to go ahead and upgrade. USPS has announced they will end support for RATE and RATEV2 APIs March 31st.
  3. Hi All, My installation of this contrib that had been working for over a year suddenly stopped working 2 days ago. Symptoms of this issue might vary between web hosts, but in my case, when pressing the button for Express Checkout the customer is directed to an error on PayPal (no code) that basically just states the operation failed. This is previous to any login attempt. PayPal techs informed me that variable names were being passed to PayPal rather than the data that was supposed to be contained. For example, the customer name would be something along the line of PAYPAL_NAME. Naturally, if the customer hasn't logged in yet, there is no data for these fields so the variable passed to PayPal should simply be null. The contrib has worked despite this issue for quite a while. I assume a recent change at PayPal might be the problem, but it may have been an update at my web host. I found a little omission in the logic in includes/modules/payment//paypal_wpp.php. Search for line if (MODULE_PAYMENT_PAYPAL_EC_ADDRESS_OVERRIDE == 'Store' && . Subsequent codes check for the data we're talking about, and if it is missing, sets the address override to "0". The omission was that variables are only set if override is "1", if override is "0", variables aren't set at all. I've just added a small bit to set the vars to null in that instance. For my install, that took care of the issue and actually fixed another problem I had just lived with for the last year or so. The address override in admin should be set to PayPal, not store. If you like store, well you're on your own. Otherwise, usual disclaimers apply as I'm not a programmer. Find: /* Don't override if the state is missing (Avoid 10729 errors) */ if ($order_info['PAYPAL_ADDRESS_OVERRIDE'] == '1' && $order_info['PAYPAL_STATE'] == '') { $order_info['PAYPAL_ADDRESS_OVERRIDE'] = '0'; $order_info['PAYPAL_NAME'] = ''; $order_info['PAYPAL_ADDRESS1'] = ''; $order_info['PAYPAL_ADDRESS2'] = ''; $order_info['PAYPAL_CITY'] = ''; $order_info['PAYPAL_STATE'] = ''; $order_info['PAYPAL_ZIP'] = ''; $order_info['PAYPAL_COUNTRY'] = ''; } Insert immediately after: /* If Address Override == "0", send null vars to Paypal (was sending Var Names instead) */ if ($order_info['PAYPAL_ADDRESS_OVERRIDE'] == '0') { $order_info['PAYPAL_NAME'] = ''; $order_info['PAYPAL_ADDRESS1'] = ''; $order_info['PAYPAL_ADDRESS2'] = ''; $order_info['PAYPAL_CITY'] = ''; $order_info['PAYPAL_STATE'] = ''; $order_info['PAYPAL_ZIP'] = ''; $order_info['PAYPAL_COUNTRY'] = ''; } That's it. Hope it saves someone some time.
  4. Just a few thoughts and tips for users of this contrib. Although I've read the length of this thread, some of these ideas may have been mentioned before. My apologies if there are repeats. :rolleyes: Testing the Contrib For folks who lack multiple devices for testing, you can download a User Agent emulator for FireFox at . Among the possibilities are several mobile devices / OSs / Browsers. Since your mobile site is based on a different screen resolution, the header will appear wrong, but I've found it invaluable in testing redirects and other functions. Redirect Problems For folks with redirect problems, the author of this contrib has done us all a great service. I applaud their ingenuity. Unfortunately, like many others I just couldn't get the redirect to work. With all the new devices emerging daily too, I suspected that if the redirect worked for me now, it would be missing some devices in the near future. I have opted for a different redirect script. It is open source, so it is constantly being updated and totally free. It can be downloaded at . Click download scripts and then php. You can set yourself a reminder to download every month or so and you're always up to date. (Again, no joy taken away from the original author. Honestly great work.) Now for the implementation. I was getting errors with the redirect being called from application_top.php when the mobile_index.php calls it's own application_top that then calls the original application_top again. I was getting a loop and the address wouldn't resolve. Perhaps I did something else wrong, but I did find a solution. I call the redirect from the main site header.php. (Actually, I use a template system, so I call it from the main template, but I believe most users would use their header.php.) Here's how it would work. a. Create a php file in the mobile/includes/classes dir called mobile_user_detect.php. Put the script you downloaded above in it. The last part of the script contains the redirect looking something like "header('Location:');". Change to read "header('Location:' . $mobile_device_url);". (I'll get to the $mobile_device_url in a moment.) If your mobile dir and mobile_* files reside in a different directory, naturally, you'll have to change this url some. b. In your header.php, put the following line "require_once('mobile/includes/classes/mobile_user_detect.php');". Again, if this doesn't resolve to the right location, you'll have to adjust for your structure. c. Last thing is the $mobile_device_url. If you are like me, most visitors don't enter your site on your homepage anyway. They click a search ad or organic result and enter on a product page. Redirecting to mobile_index.php doesn't make sense. You want them to go to the correct product page, just on the mobile version. Here's what you do. In your header.php immediately before the "require_once('mobile/includes/classes/mobile_user_detect.php');" line you just added, insert this code "$mobile_device_url = basename($PHP_SELF) . '?' . tep_get_all_get_params();". This grabs the product id and correct file name from the referring URL so the redirect can append it to the new URL. So, "" becomes "". Added Benefits For folks who are struggling with links always referring back to your main site, I think this would just send them to your mobile site again. I wasn't having this issue thanks to some previous posts, but I suspect it would function in this fashion. Guess someone else will have to try it. For folks who normally use SEO URLS, this even allows my install to correctly redirect to these product pages. Basically then, "" becomes "". If you're using a different SEO URLs and it doesn't work for you, sorry. For many though, this will save you having to rewrite all your links with your PPC providers to the non-SEO URL format. It works either way. I know this was a little long. Hopefully, it contains some useful info for someone. I have added several changes from some previous posts on this thread, so I don't really have a way to see if these changes will work with the contrib "out of the box". Good luck to all and thanks to the original author and many previous posters.
  5. Thanks for checking on that and for clearing the issue up. I'll know to go ahead with our current install. I'll watch for future releases. Thanks again for your awesome work!
  6. Hey Glen, Thanks for such a quick reply around a holiday! Taking your suggestion, if I select PayPal on the override, I get the new address that PayPal sends, but it includes the customers name even if the buyer attached a different name to the address while in PayPal (that's if the customer has an account on our site, I'm not 100% sure I checked that particular issue with a new customer). I guess that's only an issue if the customer wants to send the item to someone else, say as a gift. Is that the correct behavior, or is there a way to change the mod to use the name returned from PayPal with the address? Thanks again, it's so awesome to post a support request and get real help! BTW, with the exception of wondering how the override is supposed to work, the contrib is cranking along flawlessly. Thanks to you and Brian for great work. Art
  7. Hey Glen and Brian, Thanks so much for supporting this contrib. I know this quote is from a while back, but it looks like problems with the shipping address override have been around a long time. I'm wondering if this old post is saying it's supposed to work in such a way that the shipping address can't be changed once the customer returns from PayPal. Or, has the issue actually been fixed and I've just got a problem with my install? Basically, if I set the override to store, PayPal gets new shipping name but old address. If I set the override to PayPal, I get a new address but the customers name. Thanks again for your continued support! Art
  8. Hello all, I'm having a problem with my installation of ver1.0.4. Basically, when you click the PayPal Express Checkout button, it just refreshes the page. Info in the forum and the install file state that this is secondary to a bad certificate or path. I've double checked the path and even downloaded the cert again. I've copied all files in the install instructions again and run through the integration steps again. The diagnostic indicates everything is fine including communication with PayPal. I'm suspecting a compatibility problem with another mod, but I can't find anything here about it. I'm hoping someone else has encountered the same issue and can guide me to the incompatibility (if that is really the problem). I'm using a heavily modded OSCMax installation with PHP 5, SQL 5 and register_globals off. If it helps in the way of diagnosis, I actually have an older version, 0.9.2 I think, running successfully. Thanks in advance for any help! Art
  9. This will be a late reply for marvs5, but may help someone else who is experiencing the same issue. For the Register Globals Fix from this contrib to work, you have to be using the Register Globals Contribution by Richard Bentley found at,2097. (Or at least a portion of his contrib.) The link_post_variable referenced in the fix from this contribution is part of his Register Globals fix, not a stock OSC function (or RC2.2a function). I don't actually use Richards Register Globals fix, I'm using a 2.2a adaptation, but I copied his useful function to my includes/functions/general.php file to troubleshoot other contributions. You can find the exact code and instructions by downloading his contrib. and then searching for the link_post_variable and link_get_variable insert for general.php. I'm not a programmer, so naturally I assume no liability...blah blah. But I also assume no credit which should all go to the authors of the respective contribs themselves, especially Richard for taking the trouble to give the rest of us some hints on keeping our old code going. Way to go!
  10. Hi All, First, let me say THANKS Brian! I've had the 0.9.2 ver installed for a while successfully. I switched hosts and now have the option to run without register globals enabled. By the way, it's PHP 5.2.6 and SQL 5.0.51a on Apache 2.2.9. Here's the problem. CC transactions work great, but when attempting Express Checkout, the customer logs in at PP, hits confirm and then is redirected back to the PP Login page. It appears the return URL or customer session is being nixed?? I tried upgrading to the most recent version, but that didn't change anything. The two mods I tried to run without register globals are 1.,2097 and 2. Both mods have the same symptom. I found one solution in the associated forums, but it just broke more stuff. I've seen some other references in this forum to running this contrib without register globals. Can anyone say which no globals patch worked for them or offer a solution to the redirect problem above. Thanks in advance! Art
  11. Hi Mike, I had a similar problem at one point. Although the error indicates there's no payment method selected, I think the problem actually is no shipping method selected. I believe the problem occurs when some strange circumstance in the logic of the mod returns the customer from PayPal to the payment page without them ever having been on the shipping page. For this reason, I just always return my customers to the shipping page. It may not be the best solution, but since I don't display the PayPal button on the Payment page, it works fairly smoothly for me. If you display the PayPal button on the Payment page, it may function a little differently. I changed the code in catalog/includes/modules/payment/paypal_wpp.php of "$redirect_path = FILENAME_CHECKOUT_PAYMENT;" to "$redirect_path = FILENAME_CHECKOUT_SHIPPING";' . I'm not a programmer, but this solution worked for me on this particular error. If anyone else knows a better solution, be sure to tell me (and Mike). ;)
  12. Hi Brian, Thanks for what has obviously been a huge amount of work. I can't believe I can't get this mod to work for me. I've had ver 0.8.2 installed a while. I hoped to update because my install would only allow existing customers to send to their verified address regardless of settings chosen in admin. After installing 1.0.2, when you press the PayPal button, it simply refreshes the current page. No PayPal. I read in the troubleshooting that this was probably due to the cert_key_pem.txt. Checked the address repeatedly, moved the file to different dirs, downloaded a new one, no change. I finally installed the 0.9.2 and it works fine like the 0.8.2 (except existing customers still can't send to secondary addresses). I've run the install procedures a couple of times to be sure I didn't miss anything. Can't really use the diagnostic on my dev server here because I'm using a free SSL but I did upload the whole install to my production site briefly without any change in the symptoms. Any idea what I'm missing here? (Since moving my dev server to a Win Vista machine, my mail server won't mail me the dump file though I'm not sure one is even being created since I'm not actually going to Paypal anyway.) Thanks in advance for your help.
  13. I haven't been able to find this issue in the forum, so perhaps it is related to other contribs I have installed. Basically, I installed the 1.7 version and it appears to work great. A really helpful contribution by the way, and I think one that my customers will apppreciate. The problem is that when the customer logs in and proceeds to the checkout_shipping, there is no default shipping method already selected. (Before, UPS ground was always selected initially.) The reason this is important for my store is that Paypal Express Checkout will either a:) allow the customer to checkout without a shipping charge, or b:) Trap them on the checkout payment page since there isn't a shipping charge, and not allow them to proceed. (Which error presents itself seems to depend on the web server / PHP versions) I've had to uninstall for the time being, but I would really like to make this work. Does anyone have an idea where that default shipping method is called and why it would be affected. By the way, I don't have the pure UPS contrib supplied with OSC. It gave poor results, so I have the UPS with insurance contrib,UPS+insured installed. Thanks again to anyone who can help, and thanks Howard for such a needed contribution. Art
  14. That did the trick. I had errors earlier when I ran the database_setup.php so I went in and started running the queries manually. The first several showed that they had already been run, so I stopped without checking them all assuming that they had all run. Went back now and ran them all and found several that had not completed. Thanks for the help.
  15. Did my best to follow the instructions to the letter, but I've got an error when I attempt to access my site. 1054 - Unknown column 'categories_htc_title_tag' in 'field list' select categories_name as name, categories_htc_title_tag as htc_title_tag, categories_htc_desc_tag as htc_desc_tag, categories_htc_keywords_tag as htc_keywords_tag from categories_description where categories_id = '0' and language_id = '1' [TEP STOP] As best as I can tell, the Admin section is operating fine. Can you identify the source file of the error or make a suggestion for a fix? Thanks for the help!