Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by trier

  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. If this is incorrect and a waste of your time, please do not waste even more of your time by replying:- Phoenix Call to undefined function tep_ltrim_once() templates/default/includes/template.php on line 41
  4. trier

    Phoenix Trivia

    Are many (any?) of the entries in admin>includes>languages>english>images still used? I think the folder may now be redundant (?), possible a few older add-ons may use it. If the folder is redundant tep_image_submit in html_output.php may now be surplus to requirements?
  5. In case it's of interest - is there a minor error in admin>includes>boxes>customers.php? It throws up: Notice: Undefined index: title in /var/www/vhosts/aperfume.co.uk/ph1040.aperfume.co.uk/a19b0414zx/includes/column_left.php on line 47 Notice: Undefined index: link in /var/www/vhosts/aperfume.co.uk/ph1040.aperfume.co.uk/a19b0414zx/includes/column_left.php on line 64 Notice: Undefined index: title in /var/www/vhosts/aperfume.co.uk/ph1040.aperfume.co.uk/a19b0414zx/includes/column_left.php on line 64 Comparing customers.php to orders.php (which should be very similar?), customers.php has 2 extra lines (16 & 17) - “array (“ & “)”, removing these 2 clears the notices.
  6. When playing about with Phoenix version I created an admin hook (hook_admin_siteWide) to achieve the following on the Categories / Products page (after first checking for $PHP_SELF = ‘categories.php’): 1) listen_injectSiteStart a) Save $_GET & $_POST data to update new non-core product related table/items later 2) listen_injectSiteEnd a) action: ‘new_product’ output new product related table/items and generate jQuery code to display them where relevant on page b) action: 'copy_to' change the default copy_as - “link” to copy_as - “duplicate” c) action: 'new_product_preview' change to action 'new_product' (i.e. edit instead of preview) d) action = ‘delete_category_confirm’ action = ‘delete_product_confirm’ delete a new non-core product related table e) action = ‘copy_to_confirm’ copy new non-core product related table & product items f) action = ‘insert_product’ action = ‘update_product’ create/update new non-core table/product items using the $_POST data saved in injectSiteStart g) Category products list page (isset($_GET['cPath']) && strlen($_GET['cPath']) > 0) create hidden table of ids/models, generate jQuery to show id & model on each displayed product line copy the Back & New Category/Product buttons displayed at the bottom of the page to also display at the top Although I’ve got absolutely no idea what I’m doing, this seemed to achieve everything I wanted. However, by v1.0.3.0 injectSiteStart has been moved from application_top to template_top, as a result changes 1a/2f no longer work because there is no opportunity to capture the $_POST data (‘update_product’ redirects to the top before the first hook is executed). Using the hooks that are now available in v1.0.3.0 categories.php, I restructured the code for the new calls. The restructure is more elegant and solves the problem above, unfortunately a new problem is introduced – 2b 'copy_to' and 2g ‘Category products list page’ no longer work because output for the page is after the last available hook. Using a mix of the ‘siteWide’ & ‘categories’ hooks would be simple enough to achieve everything but splitting the changes over two different hook groups seems messy and a recipe for future problems/disaster. Questions: a) Is it possible to have a hook re-introduced into application-top (in order to use the original solution). The Shop side has a hook call in application_top, does the justification for it apply to Admin too? b) Is it possible to have a hook call at the end of categories.php? Perhaps every page that has hooks should have a call at top/bottom? For ‘non-hook’ pages, the hooks in template_top and template_bottom are available (for shop & admin), check against $PHP_SELF to apply to the correct page/script. I could obviously make these changes myself but it goes against “no core changes”. It would be simpler (short term) to insert all the changes into categories.php but it goes against “no core changes” and, to a degree, it defeats the object of hooks. P.S. A remarkable amount (almost anything?) can be achieved using hooks & javascript/jQuery instead of changing core code. Use the suck it & see approach – base the change on an existing hook and search the net for a javascript/jQuery solution to achieve the changes needed to the page after it is output. Keep playing about until you get what you want. On the Shop side, if you want the ability to turn on/off, use content/header-tag/etc. modules instead of a hook
  7. Apologies if this is obvious (but it can easily be overlooked and may be a posibility) - Do you ftp from your local m/c to the server before your install? If so (and you normally make changes locally): The install will update the config. files, the file you listed looks more like a pre-install config.? Don’t forget, after install you need to download the config. files from the server, they will be different to the local ones. If you change the admin folder name during the install, change the local folder name before doing anything else.
  8. @spooks: it’s been a while, welcome back. You, your help, your contributions, have all been missed.
  9. 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.
  10. 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
  11. 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
  12. @@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
  13. 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
  14. 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
  15. trier

    PayPal App Issues?

    Hi, There appears to be 2 faults in the new PayPal App (PayPal Standard) which seem to attract no interest - If the customer does not return to site, any comments added to an order (delivery instructions?) will be lost, never to be seen. I don’t know if this happens ‘live’ but in the sandbox (when ‘auto return to site’ is set), just after payment, you are invited to click ‘Return to site’ if not returned within 10 seconds. If the ‘click’ is made after a couple of seconds there seems to be 3 possible outcomes depending on the timing – normal (everything as expected), almost normal (all OK but returned to empty shopping cart), not normal (return to checkout success but updating/emails actioned twice). Either I have something badly wrong or there is another problem when using the app to make a PayPal Standard payment from a tablet/phone (doesn’t seem to happen with PC/laptop) – the customer is returned to a populated shopping cart with the message “Could not verify the PayPal transaction ......”. As far as I can tell the problem seems to be in paypal_standard.php ‘function pre_before_check’ when called from checkout process. The function uses the POST/GET vars to verify the transaction. With tablet/phone transactions the POST/GET vars don’t appear to be populated? Provided the PayPal IPN is successfully processed in standard_ipn.php the order will be correctly processed (the POST/GET vars are populated). Can anyone shed any light on this?
  16. 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);
  17. 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
  18. 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?
  19. 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).
  20. 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.
  21. trier

    PayPal App for osCommerce Online Merchant

    @@sanctuarybookshop Don't know if this will help - Confirmation emails for paypal standard payments are sent from /includes/modules/payment/paypal_standard.php and also from ext/modules/payment/paypal/standard_ipn.php. Both modules can complete the order process and send confirmation emails. paypal_standard.php completes the order from checkout_process.php when the customer returns to site. standard_ipn.php reacts to a PayPal communication 'behind the scenes'. In theory(???) completion will be by one or the other never both(???), there is processing in place which tries to prevent duplication. The sequence of these cannot be controlled/dictated. Sometimes a customer may not return to site. The IPN callback can occasionally go walkabout. Either can happen first. The email changes you made in paypal_standard.php need to be replicated in standard_ipn.php. You may have already found that some of the confirmation emails do reflect the changes you've made.
  22. trier

    PayPal App - PayPal Standard IPN

    Hi, Minor issue - if ‘Force Cookies Use’ is set to true in admin>configuration>sessions it causes a PHP error in the new PayPal App module ext/modules/payment/paypal/standard_ipn.php. A statement near the end of the module - tep_session_destroy(); returns an error “Trying to destroy uninitialized session“. A possible reason for this may be because when ‘Force Cookies Use’ is true, a session isn’t actually started until the second pass through application_top.php (a cookie is set in the first pass, when its presence confirmed in subsequent passes a session is started (I think????)). The error is probably of no great consequence, however, the statement is presumably there for a reason so should be actioned. There is no reason/excuse for any error to be acceptable, errors can mask other failings. For the moment, after the include application_top in standard_ipn I have added - if(!isset($_SESSION)) {tep_session_start();} Equally if (SESSION_FORCE_COOKIE_USE == 'True') {tep_session_start();} could be used? the tep_session_destroy(); could be removed (but I think it also (correctly?) destroys the cookie)? Each of these options seem quite reasonable, but I don’t really know if there may be any hidden side affect? Are there any opinions/preferences/alternatives (please don’t suggest the obvious “remove Force Cookies Use’” – opinion seems to be equally divided on the “must have/must not have”, I prefer the former).
  23. trier

    PayPal App v4.039 - double stock decrement

    @@Supertex Hi, I believe, in theory, with PayPal Standard in the new PayPal App it is possible for order processing to happen twice. In practice it is probably extremely unlikely (there has to be immaculate timing?). I will try to explain what I believe happens, hopefully it will throw some light on your problem. Final order processing can occur when PayPal sends the IPN back and/or when the customer returns to site. When the IPN notification is returned from PayPal it should be directed to ext/modules/payment/paypal/standard_ipn.php (defined in line 359ish of paypal_atandard.php). Here, the status of the order in the orders table is checked (line 69ish), final order processing only continues if the status is equal to OSCOM_APP_PAYPAL_PS_PREPARE_ORDER_STATUS_ID (probably ‘1’ (Pending) in a standard setup). When the customer returns to site (to checkout_process.php, defined in line 361ish of paypal_atandard.php), a new payment class is created, this executes ‘function pre_before_check()’. At the end of the function the status of the order in the order table is again checked (line 647ish) for OSCOM_APP_PAYPAL_PS_PREPARE_ORDER_STATUS_ID, if it is not equal (i.e. it has been updated) the final order processing in ‘function before_process()’ is bypassed. To check this out, use the PayPal sandbox - note the values of OSCOM_APP_PAYPAL_PS_PREPARE_ORDER_STATUS_ID and OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID in the configuration table. create an order, before logging in to PayPal to make payment, check the status of the order – it should be OSCOM_APP_PAYPAL_PS_PREPARE_ORDER_STATUS_ID. after completing payment, before returning from PayPal but after the IPN has been sent (should be immediate), check the order status – it should be equal OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID (probably ‘2’ (Processing) in a standard setup) – there should also be a status history for the order visible in admin. if you want to check returning to site before the IPN is executed, rename ext/modules/payment/paypal/standard_ipn.php so that it is not found. Rename it back after you return from PayPal (the IPN will normally be sent again). Your screen prints show that the status has been updated by the IPN (last line of comments is Source: IPN) and probably by checkout_process (last line of comments does not show Source: IPN). Also beware: if a customer adds comments to an order, if they do not return to site from PayPal, the comments will be lost. The comments are not available to the IPN!
  24. trier

    PayPal App for osCommerce Online Merchant

    Sorry for the waffle following. Hopefully I’m not talking total pooh, hopefully I will explain myself. This relates to the PayPal Standard option in the new PayPal App:- Even with auto-return set in the PayPal account a customer may not return to site. The IPN call-back can occasionally be delayed by as much as 24 hours, occasionally it may go walkabout and not happen at all. Presumably because neither of the above can be relied on, post payment processing (i.e. tables updating and email) is present in both the main paypal standard and the IPN script. Both scripts check the order status (for OSCOM_APP_PAYPAL_PS_PREPARE_ORDER_STATUS_ID) and continue or not. Both scripts communicate with PayPal and both always update the status history (with OSCOM_APP_PAYPAL_TRANSACTIONS_ORDER_STATUS_ID). Is this necessary/recommended or can the second communication/update be prevented? If the IPN call-back is first, it updates the status history to show payment complete (OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID). If comments have been added to an order, paypal standard also updates the status history table with the comments and the same status. Both of these entries can be seen by the customer in the account order history, can one of them be prevented? Currently the comments are not available to the IPN. Comments can be available to the IPN if either they are stored in the order table, or they are passed through PayPal using the ‘custom’ data item which is currently used to hold customer_id. On return from PayPal ‘custom’ (i.e. customer_id) is used with order_id when accessing the order tables. Is order_id on it’s own sufficient thus releasing ‘custom’ to carry the comments? A bit extreme, but in theory, with perfect timing, I guess it is possible for both paypal standard and IPN to go through the post payment motions? Maybe a bit OTT, not worth the effort, or not possible, but is it possible to ‘lock’ the order table record when it is first checked until it is updated? Paypal standard and the IPN have the post payment coding included. Is it possible to ‘commonise’ this so that any changes (e.g. I like to update the item status and email myself if an item goes out of stock) are only necessary in one place? It would be good if eventually all payment routines used the same piece of code, it should be quite easy to cater for any minor differences? (Common order create script would be good too). Am I right in thinking that although a Refund option now available from admin, updating the order status and sending emails has to be done manually? Currently, when checking the returned value a ‘Total Mismatch’ error is recorded in the status history because of comparing –ve against +ve. If you are still reading, thank you for your patience.