Jump to content

Module path doesn't exist! Orders stucked at Pending


Antonw.com
 Share

Recommended Posts

  • Replies 58
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to comment
Share on other sites

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"?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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"?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share




×
×
  • Create New...