Jump to content


  • Content count

  • Joined

  • Last visited

Profile Information

  • Real Name
  • Gender

Recent Profile Visitors

11,692 profile views
  1. trier

    Braintree Payment

    In case it’s of interest - I recently had a lot of trouble implementing Braintree payments (v2.27.2?), it constantly returned a fairly meaningless message: There has been an error processing your credit card Please try again and if problems persist, please try another payment method. Eventually, replacing the contents of includes/apps/braintree_cc/ssl/api_braintreegateway_com.ca.crt with the contents in https://github.com/braintree/braintree_ruby/blob/master/lib/ssl/api_braintreegateway_com.ca.crt seemed to solve the problem and payments now go through. Another small item of note (PHP 7.3.20) - includes/apps/braintree_cc/Braintree/Util.php - line 179 Function create_function() is deprecated. Presumably this should be either corrected or removed.
  2. trier

    PayPal Standard Issue?

    Phoenix (also in Couple of PayPal Standard issues? Don’t know they are of interest or have already been noted (assuming correct installation?): require(includes/languages/english/checkout_process.php): failed to open stream: no such file or directory in /ext/modules/payment/paypal/standard_ipn.php on line 25 Making payment with PayPal Standard: In checkout_confirmation.php after hitting payment button the following screen appears - Hitting ‘Try Again’ takes you to PayPal signin as expected.
  3. @spooks: it’s been a while, welcome back. You, your help, your contributions, have all been missed.
  4. trier

    Tabbed Product Admin

    Hi, Sorry, ignore my previous message, I've addressed the wrong add-on, I think I meant the tabbed product add-on.
  5. trier

    Tabbed Product Admin

    Hi, Thank you for this excellent add-on. I believe I've installed it correctly(?), it seems to work as expected. Assuming that to be the case, there appears to be one very minor trivial PHP error - Undefined index: admin includes/classes/hooks.php line 56 Many Thanks
  6. Hi, Thank you for this very useful addon. A very trivial minor comment (doesn’t seem to affect anything) - does: $base_url used: in includes/modules/hooks/admin/orders_customer_tab.php line 64 $tab_link = substr(tep_href_link('orders.php', tep_get_all_get_params()), strlen($base_url)) . '#section_customer_orders'; need to be included as a global in the function? Many thanks
  7. @@Jack_mcs Hi, Thank you for the reply, I appreciate it. Are you able to replicate the problem? (If it exists) it may be a session problem and not an SEO URL problem (i.e. there may be other instances where a first/second page submit redirects to index.php). The full piece of code in tep_session_start() is - if ( isset($HTTP_GET_VARS[tep_session_name()]) ) { if ( (SESSION_FORCE_COOKIE_USE == 'True') || (preg_match('/^[a-zA-Z0-9,-]+$/', $HTTP_GET_VARS[tep_session_name()]) == false) ) { unset($HTTP_GET_VARS[tep_session_name()]); $sane_session_id = false; } } The “(SESSION_FORCE_COOKIE_USE == 'True') || “ seems to cause the problem, I don’t believe it existed in previous incarnations of session.php, removing it cures the problem. Should I raise the query again within the v2.4 support topic? Many thanks
  8. Hi, Further to my earlier query (#7144), in case it’s relevant - changing includes/functions/sessions.php in function tep_session_start() remove (SESSION_FORCE_COOKIE_USE == 'True') || from lines 65 & 73 (maybe just 65 may be sufficient?) seems to cure the problem I don’t know if it is OK to make this change or if there are any other issues, obviously the code is there for a reason? Is the issue to do with SEO URLs or v234bs sessions.php? Many thanks
  9. Hi, I seem to have a minor problem with SEO URLs/session.php compatibility in v234bs? I’ll try to explain what I believe the problem is - v234bs SEO URLs with ‘Force Cookie Use’ = true: Clear all cookies/browsing data Go to site Enter a Search Key and Search Enter a Search Key (same or different to first) and Search Result: instead on being in advanced_search_result.php, index.php is loaded. Additionally an error is thrown from includes/classes/seo.class.php “undefined constant CHARSET - assumed 'CHARSET' On line 1824”. Log entries (note the inclusion of osCsid?): “GET /advanced_search_result.php?keywords=creed&osCsid=b5lpc34dn9fchcgp043q188qr3 HTTP/1.1" 302 421 "http --/advanced_search_result.php?keywords=creed “GET /index.php HTTP/1.1" 200 5956 “http --/advanced_search_result.php?keywords=creed" The problem also seems to occur with: Clear all cookies/browsing data Go to site Go to Product Listing (i.e. category list) Select Manufacturer from Product Listing filter The problem only seems to happen once, everything appears OK subsequently. Problem doesn’t seem to happen: with ‘Force Cookie Use’ = false using a v233 “sessions.php” on a clean v234bs with no SEO URLs Many Thanks
  10. trier

    PayPal App Issues?

    In case it is of interest – not surprisingly @@burt was quite right, PDT has be on, the PDT Identity Token and API credentials all have to reflect the appropriate sandbox/live seller account. It took a little while to get these right (bufoon?), when I did get them right it was a bit confusing because within the same session (even after clearing cookie/cache) the fault was still present. It was only when the changes were still in place when ‘playing about’ started the following day that it worked. Testing the new app in the sandbox, it seems - With PDT (within PP account) off, making payments from a PC/laptop will always work, payments from an iPad/phone will probably fail. With PDT on, payments from a PC/laptop will usually work (see PP fault below), payments from an iPad/phone will always work. PP Fault: PayPal Standard PDT in the sandbox from a PC/Laptop (doesn't seem to happen to iPad/phone payment). I think this is nothing to do with the new app, it seems there is a known PayPal fault when making PDT payments (I don’t know if it happens to other than standard or in PP live) - The bug only happens when the user clicks the "click here to return to..." link at the end of the transaction. (If they wait for the auto redirect back to your site, params are the correct case.) It gives ($response) of "FAIL" with an error code of 4002. PayPal returns the transaction code ($HTTP_GET_VARS['tx']) in lower case, apparently it should always be upper case. The simple answer seems to be (this is the new PP app includes/modules/payment/paypal_standard.php)- in function pre_before_check() add $HTTP_GET_VARS['tx']=strtoupper($HTTP_GET_VARS['tx']); before line 565 (ish) $parameters = 'cmd=_notify-synch&tx=' . urlencode($HTTP_GET_VARS['tx']) . '&at=' . urlencode(OSCOM_APP_PAYPAL_PS_PDT_IDENTITY_TOKEN); or change line 565(ish) to $parameters = 'cmd=_notify-synch&tx=' . urlencode(strtoupper($HTTP_GET_VARS['tx'])) . '&at=' . urlencode(OSCOM_APP_PAYPAL_PS_PDT_IDENTITY_TOKEN);
  11. trier

    PayPal App Issues?

    @@Gergely Hi, Didn't use app. on iPad, through website via safari browser. Phone was through website via chrome browser. Safari, chrome, IE all work fine on laptop. Probably not relevant, but the only other thing of note - on the admin>PayPal>Credentials page, I have never managed to display the button to extract the credentials from PayPal. Thanks
  12. trier

    PayPal App Issues?

    osc 2.3.4bs, PayPal App v4.039 When making a PayPal Standard payment from a PC/laptop, checkout_process and IPN both behave as expected (regardless of which happens first). Returning from PayPal to checkout_process, $_POST is populated as expected. The logs show the return with a POST method - PC/Laptop payment example - - [31/May/2015:12:43:04 +0100] "POST /checkout_confirmation.php HTTP/1.1" 200 1114 …........... - - [31/May/2015:12:43:33 +0100] "POST /checkout_process.php HTTP/1.1" 302 614 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) …............. - - [31/May/2015:12:43:36 +0100] "GET /checkout_success.php HTTP/1.1" 200 4766 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) ….............. - - [31/May/2015:12:43:30 +0100] "POST /ext/modules/payment/paypal/standard_ipn.php HTTP/1.0" 200 513 "-" "PayPal IPN ( https: //www.paypal.com/ipn )" When making a PayPal Standard payment from an iPad/phone, IPN behaves as expected, checkout_process always returns the “Could not verify...”message (regardless of which happens first). Returning from PayPal to checkout_process, the neither $_POST nor $_GET is populated. The logs show the return with a GET method??? - iPad/phone payment example - - [31/May/2015:12:30:50 +0100] "POST /checkout_confirmation.php HTTP/1.1" 200 2320 ............... - - [31/May/2015:12:31:16 +0100] "GET /checkout_process.php HTTP/1.1" 302 528 "-" "Mozilla/5.0 (iPad; CPU OS 8_3 like Mac OS X) ….............. - - [31/May/2015:12:31:16 +0100] "GET /shopping_cart.php HTTP/1.1" 200 21849 "-" "Mozilla/5.0 (iPad; CPU OS 8_3 like Mac OS X) …............... - - [31/May/2015:12:31:25 +0100] "POST /ext/modules/payment/paypal/standard_ipn.php HTTP/1.0" 200 475 "-" "PayPal IPN ( https: //www.paypal.com/ipn )" Any clues?
  13. trier

    PayPal App Issues?

    @@burt Thank you, 1) PayPal account>Profile>Website Payment Preferences>Auto Return for Website Payments - on/checkout_success.php (live) 2) PayPal account>Profile>Website Payment Preferences>Payment Data Transfer - on 3) admin>PayPal>Configure>PDT Identity Token - populated from PayPal account (above) Presumably setting PDT ‘on’ will not have any impact on current live (non PayPal App) processing? PayPal account settings seem to apply to both live & sandbox so presumably the auto-return (1 above) has to be the ‘live’ site? If the auto-return is checkout_success does this not bypass checkout-process? With the above in place – tablet/phone still returns to shopping cart with “Could not verify” message ($_POST & $_GET still unpopulated).
  14. trier

    PayPal App Issues?

    @@burt Hi, Thank you for the reply. The comments all relate to test site & sandbox. Everything works as expected apart from the issues noted. I believe the API is correctly set – the PayPal balance can be seen in admin. The PayPal log in admin shows a failed entry (empty) for the user IPA, and a successful (populated) entry for the IPN. I’m sure PDT is ‘off’. Return page (in paypal_standard.php ‘return=>’) is checkout_process. The issue appears to be only with tablet/phone transactions. There is no issue processing transactions by PC/laptop, both checkout_process.php and standard_ipn.php are OK regardless of which is called first. Probably not too relevant to this, osc version is 234bs.