Al Brookbanks Posted February 4, 2011 Share Posted February 4, 2011 @bsmither - this advice is good although 'file_exists' should be sufficient. It will be interesting to see what output comes. @kinderyum - we could ask your your PayPal account login but this is something we would never do. Please do not voluntarily send it to us. :) Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 7, 2011 Share Posted February 7, 2011 Apparently making a sandbox account with "Rest of the world" as your location allows us to checkout with the new pages to replicate this. I will try this a little later today and post a fix ASAP. I have just had confirmation of this from my friend at PayPal... Hopefully have some good news soon. Many thanks for your patience. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 7, 2011 Share Posted February 7, 2011 I'm trying to resolve this now but Sandbox isn't responding. I'll have to try again in an hour. Everything seem to be set against us fixing this one... We'll get there eventually. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 7, 2011 Share Posted February 7, 2011 Can anyone tell me the country the customer is from that has experienced this issue? I tried a spanish PayPal account which worked as expected. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 7, 2011 Share Posted February 7, 2011 I've tried a number of Sandbox configurations and I am simply not able to replicate a checkout process that visually matches the ones in these screenshots. Quote Link to comment Share on other sites More sharing options...
Antonw.com Posted February 7, 2011 Author Share Posted February 7, 2011 For me it dosen't matter where the customer is from, can be any country. I have Cubecart installed on another host of mine and it works fine there, so I asked my current host if he had any input on this problem and I got following reply: "Our systems block all requests from clients with blank user agents. Paypal's IPN bot uses a blank user agent - therefore it is being blocked." Do you think it can be due to the host that I get this error and the cart dosen't change status from "Pending"? Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 7, 2011 Share Posted February 7, 2011 No I don't think that is related. The error message is shown regardless whether IPN is working or not. IPN works behind the scenes, from server to server. It is not part of the checkout page loads. I'm desperate to get this resolved.. Quote Link to comment Share on other sites More sharing options...
Guest Fodmonkey74 Posted February 7, 2011 Share Posted February 7, 2011 All my test purchases used a PayPal account originating in California, United States. Quote Link to comment Share on other sites More sharing options...
kinderyum Posted February 8, 2011 Share Posted February 8, 2011 I've used 2 mock accounts - delivery addresses set as Canada and USA, but I've used my Australian credit card to pay for the (mock) purchases. My order status DOES change to 'processing' provided my store is turned ON, otherwise they will also be stuck at 'pending'. However I still get the 'Module path doesn't exit' page, turned on or off. Quote Link to comment Share on other sites More sharing options...
bsmither Posted February 8, 2011 Share Posted February 8, 2011 Have you tried the edits at post#25 above so that we can get a preliminary clue as to what this store code is objecting to? Quote Link to comment Share on other sites More sharing options...
kinderyum Posted February 8, 2011 Share Posted February 8, 2011 For now I think I'm going to have to make do with another option as I'm really keen to get my store open and backorders happening! For anyone else interested this is what I've set up until PayPal is working properly again. Since I only want to use PayPal for my payments, I've edited the Print Order Form and taken out the bank transfer details and just left a note saying 'Please make a PayPal payment to [email address]'. In the Cubecart Dashboard I've also changed a few settings in the Print Order Form section. Only problem is my customers can only pay with their PayPal account (not directly with a credit card) but hopefully that won't be a problem as people have their PayPal accounts and bank accounts linked. Just thought I'd share incase anyone else finds it useful. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 8, 2011 Share Posted February 8, 2011 I've used 2 mock accounts - delivery addresses set as Canada and USA, but I've used my Australian credit card to pay for the (mock) purchases. My order status DOES change to 'processing' provided my store is turned ON, otherwise they will also be stuck at 'pending'. However I still get the 'Module path doesn't exit' page, turned on or off. That means IPN is working which is great. I'm still not able to reproduce this... Quote Link to comment Share on other sites More sharing options...
bsmither Posted February 9, 2011 Share Posted February 9, 2011 I would be interested in knowing 1) the version of the operating system, including service packs, and 2) the exact version of PHP your store is running on. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 9, 2011 Share Posted February 9, 2011 It's very hard to know if this is a server or client side issue. Right now I am trying to get help from PayPal so I can replicate it. Waiting on a response from their tech support. Quote Link to comment Share on other sites More sharing options...
bsmither Posted February 9, 2011 Share Posted February 9, 2011 I've been looking very closely at the code in remote.inc.php again, and (if this is the only file that has the "Module path doesn't exist!" message) my conclusion is that a few tests must result as true before we get to this message. 1. The $_REQUEST['type'] must exist and be either 'gateway' or 'altCheckout'. TRUE means type=gateway is correct. 2. The $_REQUEST['module'] must be set, but could be anything. TRUE is inconclusive. 3. The $gatewayStatus must hold the valid results of a query. That is, there must be a record in CubeCart_Modules where there is 'gateway' in the module column, 'PayPal' in the folder column, and 1 in the status column. From the above, I am satisfied that $_REQUEST['type'] and $_REQUEST['module'] contain valid values. What's left is $_REQUEST['cmd']. I will assume for the moment that this key/value is also valid. Also, for the moment, I am going to assume that the constant CC_DS has been correctly defined by the time this code is included in the parent code. (Which it appears to have been.) That leaves the last test, the result of file_exists(). Research shows that there have been problems with this function of unexpectedly returning false for certain versions of php coupled with paths that contain symlinks. Also, there have been issues with not understanding that the "scope" of file_exists($relative_path) is relative to the Current Working Directory, where use of an absolute path from root would otherwise succeed. Quote Link to comment Share on other sites More sharing options...
kinderyum Posted February 10, 2011 Share Posted February 10, 2011 I have Windows Vista Home Premium and Service Pack 1. How do I find out the exact version of PHP my store is running on? In phpmyadmin (in Cpanel) I found this: phpMyAdmin 3.3.8.1 Documentation And in phppgadmin I found this: phppgadmin 4.2.2 Hope that's helpful! Quote Link to comment Share on other sites More sharing options...
bsmither Posted February 10, 2011 Share Posted February 10, 2011 In the admin screen that first greets you when you login, there should be a summary of your store, including the version of PHP and (maybe) the operating system of the server hosting your space. (Sorry, the operating system of the computer you use at home is not what I was asking for.) The Cpanel account screen may show this as well. Like, if you have Linux Economy hosting, or Deluxe hosting, etc. There should be a page that lists all the particulars of your hosted space. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 10, 2011 Share Posted February 10, 2011 @bsmither - Thanks for your feedback. I have the same conclusions as you but I have never experienced issues with "file_exists" before. Maybe some one experiencing can change the function to "is_file"? I'm yet to get a response from PayPal concerning checkout replication. Quote Link to comment Share on other sites More sharing options...
kinderyum Posted February 10, 2011 Share Posted February 10, 2011 Ah ok, thanks, here we go: Store Overview: CubeCart Version: Visit the CubeCart Downloads Server4.4.3 PHP Version: 5.2.10 MySQL Version: 5.0.91-community Image upload folder size: 547 Bytes Server Software: Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4 mod_perl/2.0.4 Perl/v5.8.8 Client Browser: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 (.NET CLR 3.5.30729) Quote Link to comment Share on other sites More sharing options...
Guest Posted February 11, 2011 Share Posted February 11, 2011 I've been experiencing the same problem after downloading the 4.4.3 trial today. Here's my info if it matters: CubeCart Version: 4.4.3 PHP Version: 5.1.6 MySQL Version: 5.0.77 Image upload folder size: 547 Bytes Server Software: Apache/2.2.17 (Unix) Client Browser: Mozilla/5.0 Operating System: CentOS 5.5 The store is at http://www.freethehops.org/store/ I did the two tests mentioned in #25. The variable $moduleFilePath was empty on return. There's an extra space in the source, so the variable was null. I'm not familiar with the codebase of Cubecart or the Paypal IPN, but my next idea was that it was either a scope issue with $moduleFullPath, or that the "cmd" key was either not set or not set to either "call" or "process". My next test: $moduleFullPath = 'Never went into the swtich'; switch(sanitizeVar($_REQUEST['cmd'])) { ## Payment Gateway Callbacks case 'call': $moduleFullPath = CC_ROOT_DIR.CC_DS.$modulePath.'call.inc.php'; break; ## Process Payment case 'process': $moduleFullPath = CC_ROOT_DIR.CC_DS.$modulePath.'process.inc.php';; break; default: if(!isset($_REQUEST['cmd'])) $moduleFullPath = 'Not even set'; else $moduleFullPath = $_REQUEST['cmd']; break; } if (is_file($moduleFullPath)) { require_once 'classes'.CC_DS.'cart'.CC_DS.'order.php'; $order = new order(); include_once $moduleFullPath; } else { die('Module '.$moduleFullPath.' path doesn\'t exist!'); } And the winner is... the $_REQUEST['cmd'] variable is "_flow". The exact (source-read) result was "Module _flow path doesn't exist!" ??? Hopefully that makes sense to someone. Is "_flow" the new "call"? Quote Link to comment Share on other sites More sharing options...
Guest Posted February 11, 2011 Share Posted February 11, 2011 Well I just looked back at the address bar in my url and realized $_REQUEST['cmd'] should have been set to "process" with the GET variable. Sounded like a conflict with a POST variable so I did some variable dumping prior to the die statement. Sure enough. The $_POST['cmd'] = '_flow' while the GET obviously was from the url. The REQUEST picked up the POST variable. Pretty simple fix. Just change in includes/remote/remote.inc.php : At around line 25: switch(sanitizeVar($_REQUEST['cmd'])) { to switch(sanitizeVar($_GET['cmd'])) { At around line 55: if ($_REQUEST['cmd'] == 'process') { to if ($_GET['cmd'] == 'process') { AND... Success. For now. It might be worth doing an audit of all the POST, GET, and REQUEST variables. My "successful" order is still showing up as Pending, although I really don't know if that's normal. I can give you a list of all the keys I saw when dumping them to the screen if anyone needs it. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 11, 2011 Share Posted February 11, 2011 And there we have it!! I think the new PayPal system must send back a GET variable for 'call' which takes president over the POST variable!!! (Or ViceVersa). VERY well done to you. I was just about to post an update that one of my friends at PayPal was getting us special SandBox access this afternoon but we may not need that now. I think the solution to this may be to have an alternative key value for the call variable. I'll post some new code here ASAP and I don't know if you of you fine people can test it for me? Well I just looked back at the address bar in my url and realized $_REQUEST['cmd'] should have been set to "process" with the GET variable. Sounded like a conflict with a POST variable so I did some variable dumping prior to the die statement. Sure enough. The $_POST['cmd'] = '_flow' while the GET obviously was from the url. The REQUEST picked up the POST variable. Pretty simple fix. Just change in includes/remote/remote.inc.php : At around line 25: switch(sanitizeVar($_REQUEST['cmd'])) { to switch(sanitizeVar($_GET['cmd'])) { At around line 55: if ($_REQUEST['cmd'] == 'process') { to if ($_GET['cmd'] == 'process') { AND... Success. For now. It might be worth doing an audit of all the POST, GET, and REQUEST variables. My "successful" order is still showing up as Pending, although I really don't know if that's normal. I can give you a list of all the keys I saw when dumping them to the screen if anyone needs it. Wonderful well done you. That indeed is a good solution BUT.... CubeCart needs to determine those variables from POST or GET depending on the payment processor used. Your solution is great to fix this for PayPal but it may break other payment integrations. I think I may have to add other allowed key values for 'cmd'. I'm incredibly grateful for your help with this. All of our staff have been in the frustrating situation of not being able to replicate this as the UX of the checkout flow has been different for us. Thanks to you we can now post a fix and get a new release of V4 out. I've just realised our Zend Guard license has expired... new release *may* have to wait until Monday... their sales doesn't seem to be getting my emails. Quote Link to comment Share on other sites More sharing options...
Guest Posted February 11, 2011 Share Posted February 11, 2011 That indeed is a good solution BUT.... CubeCart needs to determine those variables from POST or GET depending on the payment processor used. Your solution is great to fix this for PayPal but it may break other payment integrations. I think I may have to add other allowed key values for 'cmd'. Well, it was more of a hack to get past a frustrating problem and to debug. I'm sure there's a more elegant solution possible from someone with a high level view of the system. I'm eagerly waiting for any new release and will be happy to test it out. Cubecart is great, by the way - by far the most customizable store front with a great backend UI. Unfortunately we can't use it if the Paypal isn't working fully. Quote Link to comment Share on other sites More sharing options...
bsmither Posted February 11, 2011 Share Posted February 11, 2011 1. The $_REQUEST['type'] must exist and be either 'gateway' or 'altCheckout'. TRUE means type=gateway is correct. 2. The $_REQUEST['module'] must be set, but could be anything. TRUE is inconclusive. 3. The $gatewayStatus must hold the valid results of a query. That is, there must be a record in CubeCart_Modules where there is 'gateway' in the module column, 'PayPal' in the folder column, and 1 in the status column. From the above, I am satisfied that $_REQUEST['type'] and $_REQUEST['module'] contain valid values. What's left is $_REQUEST['cmd']. I will assume for the moment that this key/value is also valid. Well, an assumption that caught me out, finally. Quote Link to comment Share on other sites More sharing options...
kinderyum Posted February 14, 2011 Share Posted February 14, 2011 So, what should those waiting for an offical Cubecart update/release do, exactly? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.