Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by CBGitty

  1. That sounds like a good plan. I will hold off on upgrading/testing until then.
  2. I will give support tickets a try for this and also for the PayPal issues.
  3. I guess I'll try upgrading to 5.2.8 in a last-ditch burst of optimism that one of the various issues crippling my store has been ironed out. If not then it is time to bite the bullet and make the switch to Magento.
  4. A month or so ago I enabled Amazon checkout on my store after upgrade to v5.2.7. it seemed to be working fine, but I have recently discovered via angry e-mails from customers that when the Amazon payment method is used, any selected product options are lost... but the customer still gets charged for the options. The options do not appear in the admin console nor on the printed invoice. I have looked at the database and the product_options field in CubeCart_order_inventory is definitely null for these orders, so I have no way of going back and seeing what they did in fact order. For products with only one option we can figure it out, but for multi-option products we often can't. So now I have had to disable the Amazon checkout. Combine this with the ongoing PayPal/checkout issues as outlined in the other threads, and I am just about at the end of my rope.
  5. I can say that in my testing, that when I am taken to PayPal the session remains good - if I open another window and browse to my store, I am still logged in. It is only when returned that the session ends. Also, if debugging is turned on doesn't it show the cookie contents? Would the data that shows be sufficient to determine anything?
  6. To follow up on this, Amazon payments is now working. It began working after making some tweaks trying to fix another issue as discussed in this thread, related to & in passback URLs: '?do=embed' frameborder='0' data-embedContent>> Specifically, Bsmither's changes to functions.inc.php and also an addition to sanitize.class.php around line 86: $key = str_replace("amp;","",$key); This removes the text "amp;" from any URL keyname and prevents the sanitizer from deleting that key/value pair. As BSmither says in the other thread, it would be preferable to figure out why it is showing up in the first place and fix that, but this is working in the short term.
  7. I'm having the same issue Nik. It's good to know I'm not alone!
  8. I sent you login info in a PM if you are interested in seeing the phpinfo and other settings. I backed out my kludges on the development install so the paypal plugin checkout process can be fully tested. Last week I did move the site to a new dedicated server, BUT it was up and running (V5.1.5) for 3-4 days before I upgraded on Sunday, and the Paypal payments were working (to the extent that they had been previously) so I would be surprised if server settings alone were the culprit.
  9. I feel like a bad guy to report that on my site it does the same thing in Chrome and Firefox.
  10. Sorry Al I know how hard these things can be to track down. In a past life I was a software developer and also worked on the support side so I know how two-sided the "it's working on my end" argument can be. This install of cubecart has been up and running for 4 or so years, since version 3-point-something, and in that time it has handled over $1.5 million in sales, so considering what I paid for it I can't complain too much. I just get frustrated when it seems like every time I attempt to upgrade to the latest and greatest, significant new problems crop up. But I realize that it almost certainly is something specific to my environment and I would gladly work with you to get it sorted out, and I will pay for support credits/time to cover it if need be. The paypal checkout process via the paypal plugin has been causing my customers grief for some time and getting that nailed down and rock solid would really be great. I can certainly send you the phpinfo() output, or give you admin access to the development testbed site, ftp access, phpadmin access, whatever is needed. In other news, I did try switching to one of the default themes (kurouto red) on the off chance that the cintoxblue theme I've been running had an issue, but it didn't seem to have any effect. Also: bsmither, I didn't disable any parts of the sanitize class, I just added a line to remove "amp;" from incoming $key via str_replace() around line 86 in the _clean function, before the other sanitizing checks.
  11. Well, the kludge is in and seems to be working. Though it pained me to have to implement something so kludgey, it should take some of the pressure off in terms of moving towards a solution with the PayPal payments. On a positive note, between bsmither's 2 line addition to functions.inc.php and my addition to the sanitize class, the Amazon payments plugin is now working. So overall an optimist would call this upgrade a net gain, if he were able to ignore the 8+ hours he's spent on this so far.
  12. bsmither - adding those lines to functions.inc.php did seem to clear up the & issue in the return URL. So at this point I am sometimes able to complete an order normally. Other times seemingly random results occur, from blank screens to PayPal saying it's an invalid transaction, to having to step back through portions of the checkout process. At persent the results are far too random and confusing to put in front of customers. I am working on trying to trace the causes of the different results. In the meantime the paypal gateway is working and the biggest immediate pain is the old card_capture gateway, because I have to manually process every CC order. Ain't nobody got time for that. I am leaning towards trying to coddle together a combination of the old PayPal gateway and the paypal plugin, wherein the plugin would only display the credit card option and the express checkout/paypal pro button/selector would be hidden. The goal would be to have the old paypal gateway used for PayPal payments and the plugin automatically handle credit card payments.
  13. That & in the URL is definitely part of the problem. I added some code temporarily to the sanitize class that fixes it so that the token value gets properly passed, and with that set I was able to complete the order. The user is still not logged in when returned from PayPal (which still seems like a problem), but their info was filled in correctly and mashing the complete button a couple of more times did cause the payment to be processed and the order to go to Processing. So the questions at this point are: 1) Why is the user session ended when returned from PayPal? 2) What could be causing the return URL to be malformed? Here is what the full return URL looks like. AS you can see the ampersand after token is OK: https://www.cbgitty.com/cubecartdev/index.php?_a=confirm&token=EC-2EW66691MJ2197540&PayerID=F88FKST7G3V7J
  14. It may be a red herring, but I noticed that in the return URL, after _a=confirm it has "&" before token= instead of just an ampersand. IN my error_log, I see this: [27-Jan-2014 12:45:35 UTC] PHP Warning: Security Warning: Illegal array key "amp;token" was detected and was removed. in /home/cbgitty/public_html/cubecartdev/classes/sanitize.class.php on line 88 So if it is unsetting that key maybe it is losing the key info being returned from PayPal, which is causing it to wipe out the user's login? Just a guess.
  15. I changed the mail method, no result. When the customer is returned from PayPal, they are no longer logged in. Should I file an actual helpdesk ticket for this? I need it sorted out as quickly as possible and if I have to pay for that so be it.
  16. My Return URL in PayPal is current set to: https://www.cbgitty.com/cubecart/index.php?_g=co&_a=confirmed&s=3 My IPN URL in paypal is: https://www.cbgitty.com/cubecartdev/index.php?_g=rm&type=gateway&cmd=call&module=PayPal
  17. Today I upgraded my CC install from 5.1.5 to 5.2.7. I had thought I had fully tested the new version in a development install, and verified that PayPal checkout was working. I only have the PayPal plugin enabled, not the gateway. However I have discovered that payments via the paypal account are not working (Credit card payments are). The issue seems to be that when PayPal passes back to my site, the user is presented with a checkout screen where they are asked to log in or enter their billing information - even though they were logged in before being transferred to Paypal. I have not changed any of the IPN settings in the CC store setup, or in PayPal. Here is what the URL on return from PayPal looks like: https://www.cbgitty.com/cubecart/index.php?_a=confirm&token=EC-6H5522029F332650H&PayerID=F88FKST7G3V7J This is a very serious issue since a large number of my customers use their paypal accounts. As a short-term bandaid I have disabled the paypal plugin and re-enabled the old paypal gateway and card capture gateways, just to keep orders coming in. I need some help with what the proper settings are for the PayPal plugin in CC, as well as how PayPal itself should be configured. Also has anyone else run into this?
  18. I moved it and tested with both a digital-only order and a mixed order, and it seems to work fine, sending the mails when the order changes to Processing. Adding it as an admin setting might be a nice feature, to let store admins specify when digital download mails should be sent. Also, in the original post I had mentioned that nothing was showing up on the user's downloads page in account settings. Turns out this was due to a typo'd variable name in the cintoxblue theme template. So all of the issues in this thread are now resolved.
  19. I will use your version of the line, thanks. One more question on the topic of downloads... it has always (as far as I know) been the case that if a customer buys a digital download along with other tangible products in a single order, then the download link doesn't get sent until the order is marked complete (ie, when it is shipped) which may not occur for several days if over a weekend. Customers expect that "instant download" links will be sent as soon as the order is paid. It seems like this could be achieved by moving the "$this->_digitalDelivery($order_id, $this->_order_summary['email']);" line from the ORDER_COMPLETE case to the ORDER_PROCESS case in the orderStatus function. Do you see any reason why this wouldn't work?
  20. Looks like line 632 of order.class.php might have the clauses reversed: I changed it from: $storeURL = (CC_SSL) ? $GLOBALS['config']->get('config', 'standard_url') : $GLOBALS['storeURL']; to: $storeURL = (CC_SSL) ? $GLOBALS['storeURL'] : $GLOBALS['config']->get('config', 'standard_url'); and now it is adding the https:// Al, I am testing this on the dev install I freshly updated to version 5.2.7... not sure how old bugs fixed long ago would still be lingering there?
  21. After a little more experimenting, here is what I have found. 1) I have SSL enabled and forced for all pages. 2) The download link as supplied in the customer email is: http://www.cbgitty.com/cubecartdev/index.php?_a=download&accesskey=eed096047a110aaea2e18ed7330d4f61 3) When clicked, the site strips off the http:// and redirects to just www.cbgitty.com/cubecartdev/index.php?_a=download&accesskey=eed096047a110aaea2e18ed7330d4f61 3) If I add https://, the download works. So it seems like this could be resolved by changing the link generation code to check for SSL being enabled, or changing how SSL redirection is handled so that it redirects to https instead of just stripping the http.
  22. Al: I will poke around at it a bit and then maybe give a support ticket a try. Last time I tried it the tech that took it up seemed to know less about CubeCart than I did, and I ended up digging into the code and fixing the issue myself. BSmither: I do have SEO URLs turned on with the Apache rewrite rule enabled. .htaccess contents as follows, as shown via the admin console/store settings: ## File Security <FilesMatch ".(htaccess)$"> Order Allow,Deny Deny from all </FilesMatch> #### Apache directory listing rules #### DirectoryIndex index.php index.htm index.html IndexIgnore * #### Rewrite rules for SEO functionality #### <IfModule mod_rewrite.c> RewriteEngine On ######## START v4 SEO URL BACKWARD COMPATIBILITY ######## RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule cat_([0-9]+)(.[a-z]{3,4})?(.*)$ index.php?_a=category&cat_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule prod_([0-9]+)(.[a-z]{3,4})?$ index.php?_a=product&product_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule info_([0-9]+)(.[a-z]{3,4})?$ index.php?_a=document&doc_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule tell_([0-9]+)(.[a-z]{3,4})?$ index.php?_a=product&product_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule _saleItems(.[a-z]+)?(?.*)?$ index.php?_a=saleitems&%1 [NC,L] ######## END v4 SEO URL BACKWARD COMPATIBILITY ######## RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !=/favicon.ico RewriteRule ^(.*).html?$ index.php?seo_path=$1 [L,QSA] </IfModule>
  23. Currently running v5.1.5, have also tested it on 5.2.7. At this point I have a single digital download product, and I cannot get the automatic download link to work. I have uploaded the PDF file via the Downloads interface in admin. I have verified that the product is set as digital (Had to go into the database to do this). In the product definition, the PDF file is selected on the Digital tab. No custom file path is set. When a customer purchases the product by itself, once paid the order goes to COmplete status and the customer gets an e-mail with the download link. When that link is clicked, they end up at a browser error indicating a redirect loop. The same thing happens if I try to set a custom file path. Also, nothing shows up in the customer's digital downloads area under their account details. Is there some undocumented cubecartian errata that I have to set, or is this another non-functional feature we just have to work around.
  • Create New...