New 
trier
-
Posts
105 -
Joined
-
Last visited
Posts posted by trier
-
-
-
Hi, Sorry, ignore my previous message, I've addressed the wrong add-on, I think I meant the tabbed product add-on.
-
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 56Many Thanks
-
Hi, Thank you for this very useful addon. A very trivial minor comment (doesn’t seem to affect anything) -does: $base_urlused: 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
-
-
@@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 -
Hi, Further to my earlier query (#7144), in case it’s relevant -changing includes/functions/sessions.phpin function tep_session_start()remove (SESSION_FORCE_COOKIE_USE == 'True') ||from lines 65 & 73 (maybe just 65 may be sufficient?)seems to cure the problemI 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
-
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 dataGo to siteEnter a Search Key and SearchEnter a Search Key (same or different to first) and SearchResult: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 dataGo to siteGo to Product Listing (i.e. category list)Select Manufacturer from Product Listing filterThe problem only seems to happen once, everything appears OK subsequently.Problem doesn’t seem to happen:with ‘Force Cookie Use’ = falseusing a v233 “sessions.php”on a clean v234bs with no SEO URLsMany Thanks
-
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);
-
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
-
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
86.139.224.32 - - [31/May/2015:12:43:04 +0100] "POST /checkout_confirmation.php HTTP/1.1" 200 1114 …...........
86.139.224.32 - - [31/May/2015:12:43:33 +0100] "POST /checkout_process.php HTTP/1.1" 302 614 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) ….............
86.139.224.32 - - [31/May/2015:12:43:36 +0100] "GET /checkout_success.php HTTP/1.1" 200 4766 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) …..............
173.0.82.126 - - [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
86.139.224.32 - - [31/May/2015:12:30:50 +0100] "POST /checkout_confirmation.php HTTP/1.1" 200 2320 ...............
86.139.224.32 - - [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) …..............
86.139.224.32 - - [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) …...............
173.0.82.126 - - [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?
-
@@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 - on3) 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).
-
@@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.
-
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? -
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();}Equallyif (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).
-
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! -
Jack,
Hi, Thank you for your continued support and maintenance of this feature, for your other developed add-ons and for your general support. Like many others, I'm grateful for the considerable time and help you give.
To help my understanding, could you please comment/help on the following (apologies if it's a bit long & tedious) -
1) After implementing the latest version I noticed that when selecting a manufacturer the generated URL was something like -m-1.html instead of matrox-m-1.html. I think it may be due a minor fault in the latest (and possibly previous) version of seo.class.php -
Line 1257 reads
WHERE manufacturers_id='".(int)$mID."'
should be?
WHERE m.manufacturers_id='".(int)$mID."'
(i.e. 'manufacturers_id' is not a unique, it is in both tables?).
Using a cache may mask this so it's possibly not immediately obvious?
(I only ever have 1 language so I may remove the join to TABLE_MANUFACTURERS_INFO anyway).
2) When displaying the first page of a product listing, 'page=1' may be displayed in the URL depending on circumstances. Is it possible to easily suppress the 'page=1'? (Is it better to attempt it in tep_href_link function or not do it at all).
3) seo_class.php uses mysql functions as opposed to the mysqli functions used in osC 2.3.3.4, is it worth replacing the mysql with mysqli, or maybe better (?), replace the '$this->DB->' statements with the corresponding tep functions?
4) I am using Ultimate SEO URLs in my latest (v2.3.3.4) version of osC, previously I used SEO URL 5. SEO URL 5 had an option to “Force a redirect to www.mysite.com/ when www.mysite.com/index.php”, is it possible to do this with Ultimate SEO URLs ?
5) What is the purpose of the statement in application_top -
if ( !isset($seo_urls) || !is_object($seo_urls) ){
6) What is the pupose of the statements in the tep_href_link function -
if ( !is_object($seo_urls) ){
if ( !class_exists('SEO_URL') ){
Many thanks.
-
Hi,
I have a working version (in testing) of the PayPal WPP – 3D Secure module (addons.oscommerce.com/info/7280), but I’m a bit wary of implementing because the ongoing cost of PCI compliance seems a tad heavyweight.
Does anyone know if this solution works with 3D Secure (using Cardinal Centinel)? There doesn’t seem to be a way of interrupting the flow to pass the captured payment details through the 3DS process.
As an aside, there doesn’t seem to be great coverage of 3DS, have many installations adopted it?
Many Thanks
-
Bob,
Hi, Thank you for your comments, much appreciated. I was initially advised to use the 'live' Cardinal url, I have since switched to the 'test' url which returns an authorisation screen suitable to allow processing to continue. I guess the live url will have to be used to test invalid credit card conditions.
I will try x.com to see if there is any more info that may be of use.
Many thanks
-
Hi, I am trying to install PayPal WPP with 3D Secure. It seems OK up to a point but there are a some questionable areas (the change is based http://addons.oscommerce.com/info/7280 but I think the questions are fairly general)-
1) the initial call to Cardinal Sentinel (the bridge for PayPal 3D Secure) returns a 'live' bank url to obtain the 3D Secure authorisation. Is a test version available? Without a test version how can end-to-end testing be performed.
2) Running PayPal WPP in the sandbox with 3D Secure disabled appears to work - stock updated, emails sent, transaction recorded in the PayPal merchant sandbox account. The only thing missing is the transaction is not recorded in the PayPal sandbox buyer account?
3) Running PayPal WPP in the sandbox seems to function without the need to first sign in to the sand box. Normally when testing in the sandbox it is necessary to sign in first. Is something missing?
Is there a PayPal WPP 3D Secure version for osC 2.3?
Many Thanks
-
Hi, Thank you for yet another very helpful contribution - non zipped backups seem to be less than half the size of those from the standard osc backup and the option to backup/restore selected tables is very useful.
Sorry fot the trivia, but is line 190 of backup.php correct? if (!fp) { die ("No file handle open."); }
Should it be if (!$fp)?
The script ID reads v 1.5.1 though I believe it is the lastest 1.5.2
It's probably no too important, unfortunately I don't know/understand enough to be leave/change it.
Many thanks
-
Hi,
Ultimate Seo Urls 5 PRO ( r205 ) osC 2.3 -
Though it is probably quite trivial, can anyone please help answer a question I have on this feature (I’m hoping to be luckier than my previous question on this thread which brought no response).
I may be going nuts, I may have done something wrong, it may be working as expected (perhaps you can check yours and let me know) -
When listing products for a Manufacturer (product_listing.php), hovering over a product item shows the expected URL for the product info page but the URL doesn’t include the ‘&manufacturers_id=’. Clicking on the product item loads the correct page with the expected URL (without the ‘&manufacturers_id=’). However, the breadcrumb trail shows Home>>Category>>Product instead of Home>>Manufacturer>>Product (as it did in the osC 2.2 version).
Swapping the products_id and the manufacturers_id around in the call to tep_href_link causes the ?manufacturers_id to show in the URL when hovering over the product name in the product listing but it is ‘mislaid’ when going to the product_info page.
-
Hi,
Thank you for this and your other excellent contributions which many of us appreciate.
I have installed USU5 in it’s current and earlier incarnations without issue previously. Trying to implement it in an osC 2.3 site is causing a problem - ‘Internet Explorer cannot display the webpage’. I’m fairly sure it has nothing to do with USU5 and it is because I am using 'http://ServerName/AccountName', the site won’t have a domain name allocated until testing is complete. It would be good to have the cause confirmed rather finding after implementation that the assumption is incorrect.
Failure occurs regardless of the URL format chosen. The generated URL is constructed exactly as expected for each option. However, in application_top.php with SEO URLs 5 enabled it doesn’t get any further than -
Usu_Main::i()->setVar( 'languages_id', $languages_id ) ->setVar( 'request_type', $request_type ) ->setVar( 'session_started', $session_started ) ->setVar( 'sid', $SID ) ->setVar( 'language', $language ) ->setVar( 'filename', $PHP_SELF ) ->initiate( ( isset( $lng ) && ( $lng instanceof language ) ) ? $lng : array(), $languages_id, $language );Content of (relevant?) data items when URL Format = Standard (the actual account name has been altered to 'AccountName') -
$_SERVER[php_SELF]: /~AccountName/product_info.php/issey-miyake-leau-dissey-ladies-edt-100ml-p-302 basename($_SERVER[php_SELF]): issey-miyake-leau-dissey-ladies-edt-100ml-p-302 $_SERVER[sCRIPT_NAME]: /~AccountName/product_info.php basename($_SERVER[sCRIPT_NAME]): product_info.php $PHP_SELF: product_info.php basename($PHP_SELF): product_info.php $languages_id: 1 $request_type: NONSSL $session_started: 1 $SID: $language: english $lng: 1 FWR MEDIA KissER Error Handling: E_NOTICE Error Count: 1 Error: Undefined variable: lng File: /~AccountName/product_info.php/issey-miyake-leau-dissey-ladies-edt-100ml-p-302: includes/application_top.php Line: 353
Many Thanks
-
Hi,
Thank you for replying to my 'off thread' question - I'd given up on it.
I assumed the _SESSION keys you listed would just get re-registered/populated with the next page load.
I'll stick to the conventional method.
Thanks again, appreciate it.
Braintree Payment
in Braintree
Posted
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.