Hello,
Another question for you.
When adding an IPN action, I am sending get information to an http source as follows:

...validate.php?userid=[*item_number*]&transtype=[*txn_type*]

When testing, the entry in my log is this:

...validate.php?userid%3D%5B%Aitem_number%2A%5D%26 transtype%3D%5B%2Atxn_type%2A%5

and as such, it is not working. What I obviously want is the values of these variables to be passed but that doesn't seem to be happening. Any suggestions? :(
Thanks

The string is being encoded so it follows RFC's, you need to urlunencode it on the other end, or use POST instead.

Jaffo,
Thanks for your response.
Perhaps I should clarify my earlier post.

My exact entry into the paypal assistant in the box for the get request is:

...validate.php?userid=[*item_number*]&transtype=[*txn_type*]

As such I expect it to send the variable "item_number" and "txn_type" to my validate.php function. right?

When testing, the resulting entry in my access log is this:

..."GET /_palpay/validate.php?userid%3D%5B%2Aitem_number%2A%5D%26 transtype%3D%5B%2Atxn_type%2A%5D HTTP/1.1" 200 449 "-" "-"

If I were to URLunencode this get request from my access log I would have
"GET /_palpay/validate.php?userid=[*item_number*]&transtype=[*txn_type*] HTTP/1.1" ...

In other words, it is sending the string I entered in the paypal assistant as is. ie - it is sending the variable names, not the variable values that I need it to send.

I have set up a test form to access my function and it sends variables as expected and runs the function correctly.
Additionally, I have tried to use the POST method from paypal assistant but had no success with that either.

Please tell me, what is going wrong.

thanks again. :confused:

Hmm, which version are you using?

Hi,
Its the latest version ( I expect ) , I purchased it three or four weeks ago.
Thx

(php)

I will have to run some tests here to see if I can recreate it.

thanks

Any Luck?
I would like to get this back up running soon.
Thanks

Hmm, I have been looking over the code and I cannot seem to find why this would happen on your server. I am wondering if it may be an issue with globals being off.

Let me know if this fixes it. Open index.php and right at the beginning you will see these lines:

require_once('./config.php');
require_once('./functions.php');

ADD these lines right after it and let me know if it changes anything:

if (!isset($_GET)) { $_GET = &$HTTP_GET_VARS;}
if (!isset($_POST)) { $_POST = &$HTTP_POST_VARS;}
if (!isset($_SESSION)) { $_SESSION = &$HTTP_SESSION_VARS;}
if (!isset($_SERVER)) { $_SERVER = &$HTTP_SERVER_VARS; }
if (!isset($_ENV)) { $_ENV = &$HTTP_ENV_VARS;}
if (!isset($_COOKIE)) { $_COOKIE = &$HTTP_COOKIE_VARS;}
if (!isset($_FILES)) { $_FILES = &$HTTP_POST_FILES;}
if (!isset($_REQUEST)) { $_REQUEST = &$_GET&$_POST&$_COOKIE&$_FILES;}

Hi,
thanks for the response :)
I have added this as suggested but the result has been the same:
still the variable names, not the variable values are being sent.

Actually, I think I found the issue. PHP datatyping is so different than Perl, it broke down during translation.

Anyway, open functions.php and find the function called Paypal_Sale and find these two lines:

$enc_rip = preg_split('/\?/', $get_url, 2);
$enc_rip[1] = rawurlencode($enc_rip[1]);

REPLACE these lines with this code:

$enc_rip = preg_split('/\?/', $get_url, 2);
$newrip = preg_split('/\&/', $enc_rip[1]);
foreach ($newrip as $itemt) {
$itemt = rawurlencode($itemt);
$finalg .= "$itemt&";
}
$enc_rip[1] = $finalg;

REPLACE the entire function called parse_form_data with this one:

### Search and replace
function parse_form_data($arr) {
if (is_array($arr)) {
foreach ($arr as $key => $value) {
#$replacement = "$2";
$value = preg_replace('/(\[\*)(.*?)(\*\])/e', '$_POST[$2]', $value);
$arr[$key] = $value;
}
return $arr;
}
else {
$arr = preg_replace('/(\[\*)(.*?)(\*\])/e', '$_POST[$2]', $arr);
return $arr;
}
}

That should fix the issue for you.

Brilliant!

90% there...

It correctly sends the variable values now and strips out the [* and *] properly with the exception of two things: the [* before each variable value remains and the closing & joining variables in the GET string appears.
so the result in the access log is

...?userid%3Dtestuser&transtype%3Dsubscr_payment& HTTPD/1.1"...

I'm not sure if the & at the end makes a difference but the %3D's certainly do.

:)

Can you post me an example of your GET string ( leave out the URL ).

yes, here we go:

"GET ...validate.php?userid%3Dgreengreen&transtype%3Dsubscr_payment& HTTP/1.1" 200 449 "-" "-"

There is a space after ..._payment&

Actually, I meant the GET string as you enter it into the Assistant, not after it is parsed by your other script.

Hi,
sorry, away for a couple days,
here is the string from the assistant and I apologise, it seems that its only the = sign thats being read as the %3D - the [* and *] seem fine.


..._palpay/validate.php?userid=[*item_number*]&transtype=[*txn_type*]

thanks :o

Hmm, yeah I see how that could cause a problem. I am going to have to consider how to bypass this effectively. Basically, the script will URL encode the GET line so as not to send an invalid request, so I am going to have to edit it to ignore equal signs for you. Let me test this for a day or two and make sure it doesn't affect the rest of the script.

Any Luck?

Sorry to stress, but I've got a site right now set on manual which is driving my client nuts. Although I'd rather not go through the exercise of switching to the CGI versionn, I can, however, if the php version will be working correctly soon I would rather stick with it. Any idea on time for the fix?
Thanks in advance

Yeah... I think I'll switch to the .cgi version.
I hope others aren't having the same problems.

Hi,
Now that we have the longest thread almost....

So I had fully intended on switching to the cgi version and went ahead with the install to find -of course- that I need to install one of the perl modules to get it to work. Now considering that I hadn't really intended on using the cgi version in the first place and no one wants to install perl modules back in serverland I am in a bit of a fix.

Do you intend on solving the problems with the php version?

If so, when? If not, when? ;)
c-mon, I know you can do it!!
Please?

still waiting...

Jafo
Wondering if you've had another look at this. This issue has come into play again and I was hoping it could be fixed on the php version of the script.
Thanks