Latest News: (loading..)

trier

Members
  • Content count

    77
  • Joined

  • Last visited

About trier

Profile Information

  • Real Name
    Jimbo
  • Gender
    Male
  1. @@AngusD Hi, You were headed in the right direction, the reason for my confusion woke me at 4a.m. - I installed a fresh 2.3.4BS & and updated the PayPal App. Confusion arose because although the site admin showed the app version v5.018, running a file compare of the site pre & post update showed no differences. Unfortunately, (you may be ahead of me already) the site compare was run on my PC scripts but I hadn’t downloaded after the update! At some point after the update I'd uploaded paypal_standard.php again (can't remember why). Thank you for your time & help with this.
  2. typos in my last post - s/b: "paypal_standard.php is wrongly showing checkout_process instead of checkout_success".
  3. @@Mikepo Hi, The auto-return address in my PayPal account and the return address in the process_button() parameter are both checkout_process.php. Unless I have made a major mistake somewhere, I can only assume that the return in the after_process() function in 2.3.4BS Edge paypal_standard.php is wrongly showing paypal_process, it should be paypal_success, also, paypal_standard.php is not updated by the PayPal App Auto Update??
  4. @@AngusD Hi, Thank you for your reply. I felt that the last line of function after_process in paypal_standard.php should redirect to checkout_success. I am confused because: A fresh download of 2.3.4BS Edge has the redirect to checkout_process.php After installing 2.3.4BS Edge and hitting the PayPal App Update button in admin, no changes were made to paypal_standard.php. The admin>paypal>configure page shows “PayPal App v5.018” The PayPal App add-on, 9184, is v5.010. In this, paypal_standard.php redirects to checkout_success.php but it has some code which is not in the 2.3.4 script and it doesn’t have the hard-coded file/table names. Last November I asked - “The last line in function after_process() is tep_redirect(tep_href_link('checkout_process.php', '', 'SSL')); should it be tep_redirect(tep_href_link('checkout_success.php', '', 'SSL')); ?” and got the reply - “tep_redirect(tep_href_link('checkout_process.php', '', 'SSL')); is correct” I don’t know if I’ve gone wrong somewhere because I’m surprised that no-one else appears to have had the problem?
  5. Can someone please put me out of my misery and explain how payments via PayPal Standard reach checkout_success. I am setting up a new 2.3.4BS Edge with the latest PayPal app. The first couple of runs returned to checkout_success. PayPal Standard payments, though successful, are now returning to an empty shopping_cart. Every time I check the scripts I (obviously wrongly) come to the conclusion that an empty shopping_cart is correct: PayPal returns to checkout_process - checkout_process @ line 46: $payment_modules = new payment($payment); function paypal_standard @ line 75: $this->pre_before_check(); function pre_before_check @ line 659: (may call $this->after_process(); if IPN already actioned) checkout_process (continues) @ line 81: $payment_modules->before_process(); function before_process @ line 801: $this->after_process(); function after_process clears cart, unregister variables, tep_redirect(tep_href_link('checkout_process.php', '', 'SSL')); checkout_process (restarts) @ line 22: if ($cart->count_contents() < 1) { tep_redirect(tep_href_link('shopping_cart.php')); } As far as I can see the only route to checkout_success is at the end of checkout_process which (intentionally?) is never reached, to get there another order would be created and email sent? Also, to confirm, the order_status_history table is updated with a status OSCOM_APP_PAYPAL_PS_PREPARE_ORDER_STATUS_ID by the return processing and by the IPN process (i.e. 2 entries intentionally). The table is only updated with the OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID by the return processing (i.e. never by the IPN).
  6. There are probably various reasons for this one of them being (I think) if you don’t have the correct TLS/OpenSSL level. Try creating & running the following script (the echo’s can probably be removed leaving just 3 lines): <?phpecho '<br>A: '; $ch = curl_init(); curl_setopt($ch,CURLOPT_URL, "https://tlstest.paypal.com/");curl_setopt($ch, CURLOPT_SSLVERSION, 6); var_dump(curl_exec($ch)); echo '<br><br>B: '; var_dump(curl_error($ch)); echo '<br><br>C: '; var_dump(curl_version()); echo '<br><br>D: '; echo '<br><br>---- '; If correct it should output something like: A: PayPal_Connection_OKbool(true) B: string(0) "" C: array(9) { ["version_number"]=> int(467968) ["age"]=> int(3) ["features"]=> int(34493) ["ssl_version_number"]=> int(0) ["version"]=> string(6) "7.36.0" ["host"]=> string(23) "x86_64-redhat-linux-gnu" ["ssl_version"]=> string(14) "OpenSSL/1.0.1e" ["libz_version"]=> string(5) "1.2.3" ["protocols"]=> array(20) { [0]=> string(4) "dict" [1]=> string(4) "file" [2]=> string(3) "ftp" [3]=> string(4) "ftps" [4]=> string(6) "gopher" [5]=> string(4) "http" [6]=> string(5) "https" [7]=> string(4) "imap" [8]=> string(5) "imaps" [9]=> string(4) "ldap" [10]=> string(5) "ldaps" [11]=> string(4) "pop3" [12]=> string(5) "pop3s" [13]=> string(4) "rtsp" [14]=> string(3) "scp" [15]=> string(4) "sftp" [16]=> string(4) "smtp" [17]=> string(5) "smtps" [18]=> string(6) "telnet" [19]=> string(4) "tftp" } } D: ---- If it shows an error you probably need to speak to your host provider.
  7. I have experienced this problem a few times, but, though spending many weeks trying, have never managed to replicate it. A consideration was that use of the browser back/forward buttons could be a possible cause. I believe checkout_payment deletes order details if they already exist, checkout_confirmation creates the initial order details. Paging between the two causes creation/deletion. However, on the browsers I’ve checked it is not the reason. The only way I have found to force the fault is to have two pages open at the same time, paging back within the checkout process on one page whilst going forward with the process on another page. Probably a very unlikely event, probably not the reason. To see if it helps, for the moment I have removed the order tables deletes from function selection() in paypal_standard.php. Obviously if the problem happens again I will know that the attempt didn’t work. Unfortunately, if it is a solution, I will never know for sure. A downside to this is that incomplete orders are left on the database, they can be easily deleted from within admin. You may be surprised at how often orders are recreated.
  8. Hi, Thank you for this, excellent. Thank you too for the other helpful contributions you make to this forum. I’ve checked the implementation of this several times but “MODULE_HEADER_TAGS_MCAFEE_TRUSTMARK_ID” (line 34 includes>modules>header_tags>ht_mcafee_trustmark.php) throws up an “undefined constant” message, I can’t find where it is/should be defined? Many thanks
  9. Hi, I think I’m going round in circles & missing something: Is the a minor fault in the latest version (2.3.4 Edge) of includes>modules>payment>paypal_standard.php - The last line in function after_process() is tep_redirect(tep_href_link('checkout_process.php', '', 'SSL')); should it be tep_redirect(tep_href_link('checkout_success.php', '', 'SSL')); ? v2.4 :heart: :heart: :heart: :D :D :D
  10. I have found the following seems to work (should cover all emails sent from within admin?) :- admin/includes/functions/general.php function tep_mail (line 1179ish) at the start (after if (SEND_EMAILS != 'true') return false;) add $self = $_SERVER['PHP_SELF']; $_SERVER['PHP_SELF'] = "/mail.php"; at the end (before closing }) add $_SERVER['PHP_SELF'] = $self; Maybe someone more knowledgeable can comment on the placement/viability of this – often things appear to work but they hide/mask/create other faults.
  11. Hi, I raised this query in two other places but it attracted little or no interest hence trying here. Is there a minor problem with sessions in v234bs/edge (v234?)? Problem v234bs/edge 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 (may happen on 1st Search, generally 2nd): instead on being in advanced_search_result.php, index.php is loaded. 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" Similar outcome when (‘Force Cookie Use’ = true): Clear all cookies/browsing data Go to site Select Manufacturer from list Select Manufacturer from list (or enter a Search) Problem only ever seems to happen on the 1st or 2nd click on site when the clicks have input, it doesn't subsequently re-occur. Possible Cause? In v234bs there is a piece of code in includes/functions/sessions.php in the tep_session_start() function line 64ish - 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; } } it is repeated for $HTTP_POST_VARS[tep_session_name()] and slightly different for $HTTP_COOKIE_VARS[tep_session_name()]. The "(SESSION_FORCE_COOKIE_USE == 'True') ||" in the code was not present in previous versions of the script, by removing it the problem no longer occurs (it is not present in the $HTTP_COOKIE_VARS[tep_session_name()] test). Thank you
  12. Hi, I raised this query in the SEO URL thread because I thought it may be related to the add-on. On reflection (if it exists) I think it may be related to 'Sessions' (apologies for the length, I'll give the my perceived answer before the question) . In v234bs (v234?) there is a piece of code in includes/functions/sessions.php in the tep_session_start() function line 64ish - 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; } } it is repeated for $HTTP_POST_VARS[tep_session_name()] and slightly different for $HTTP_COOKIE_VARS[tep_session_name()]. The "(SESSION_FORCE_COOKIE_USE == 'True') ||" in the code was not present in previous versions of the script, by removing it my problem no longer occurs (it is not present in the $HTTP_COOKIE_VARS[tep_session_name()] test). The problem as raised in the SEO URL thread (verbatum) - 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
  13. @@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
  14. 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