Latest News: (loading..)

trier

Members
  • Content count

    82
  • Joined

  • Last visited

About trier

Profile Information

  • Real Name
    Jimbo
  • Gender
    Male

Recent Profile Visitors

9,165 profile views
  1. 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
  2. @burt @BrockleyJohn Hi, Thank you for your comments. Because of the significant number of changes to my website, keeping it up-to-date is always a headache (particularly given my total lack of organising/documentation skills). Although there is obviously a bit of a processing overhead, I figured changes would be easier to identify/understand if kept outside core scripts. Regarding search engine view of pages where elements have been moved/replaced/deleted by jQuery, the product_listing & product_info page titles/headings are quite heavily changed, I may need to check that it doesn’t have a negative impact. Thank you for your help
  3. Hi, This is a slight divergence to the “Emails in 2.4” question raised by @frankl - I am currently trying to make changes to 2.3.4bs without tampering with core code - using jQuery (until pages are fully modularised) in new footer content scripts it is possible to make significant changes to page content/layout (is this OK or unwise?). Is it also possible using a header_tag script to add code that would otherwise be in application_top (is there a better way?). However, I have not yet found a suitable way to externally change functions. I would like to make minor changes to tep_href_link, tep_address_format, and tep_mail without meddling with core. Apparently there is no PHP facility to delete/replace (system/user) functions. Is there a suitable solution?
  4. Hi, Before I download the latest version of v234bs, are there any plans to promote https://github.com/gburton/Responsive-osCommerce/tree/TablePrefix to edge in the near future? Thanks
  5. Hi, I believe there is a version of 2.3.4 bs edge with table names removed? Is this as current as edge? Is there any intention to ‘promote’ it to edge? Many thanks
  6. @@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.
  7. typos in my last post - s/b: "paypal_standard.php is wrongly showing checkout_process instead of checkout_success".
  8. @@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??
  9. @@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?
  10. 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).
  11. 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.
  12. 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.
  13. 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
  14. 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
  15. 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