This warning is being logged after every PXPay payment, and is sometime shown to the user.
uc_payment_load_payments a few lines above is returning false?

Workaround:
Updated code at line 78 to allow for $payments == FALSE

      /* Prevent error: Invalid argument supplied for foreach() */
      if ($payments !== FALSE) { 
        foreach ($payments as $payment) {
          if ($payment->comment == $comment) {
            $duplicate_flag = TRUE;
          }
        }
      }

Comments

moxwai’s picture

I'm also getting this error. Its the first time that i have tried to connect a site to the dps test account, normally i go straight to live and just put thru .50 cent transactions. I'm wondering if the code that get returned from the dps gateway, doesnt match up with whats on line 77/78 which is a variable below:

// Check for duplicate transaction
      $duplicate_flag = FALSE;
      foreach ($payments as $payment) {
        if ($payment->comment == $comment) {
          $duplicate_flag = TRUE;
        }
      }

Any developer types got an idea on this one? Hopefully when i go change to live dps this will be fixed. Otherwise i was going to use string replace module to replace the error message with nothing on the screen so the user sees no error.

xurizaemon’s picture

Status: Active » Needs work

Can you please add some debug to see what $payments is, if it isn't an array or FALSE?

You could enable devel module and use dpm(array($payments), 'payments') above the if stmt - the extra array wrapper will ensure values like 0, NULL and FALSE show.

snlnz’s picture

Hey Chris, Hope all is well?

I've seen this before, but failed to document the fix. :(

Got this error showing up on one of our sites so I've pulled a copy down to analyse.
Issue is occurring with 1.1 and 1.x-dev.

On the live site, the transaction is being paid, then Drupal says DPS payment was declined.
On local dev, payment is going through and spitting out the warning which is acceptable as we could turn off php warnings anyways but that doesn't fix the above message. The only noticeable difference is live > nginx, local dev > apache.

Could you elaborate on what you mean by use:
dpm(array($payments), 'payments')
above the if statement?

I'm not seeing anything obvious and definitely nothing useful in the syslog/dblog.
Perhaps if you could clarify how to get more debug info out of the issue, then I could provide it? :D

Hope I got everything...
Thanks in advance!

xurizaemon’s picture

Status: Needs work » Postponed (maintainer needs more info)

Hey Karu, yeah all's good down here :)

If $payments isn't getting set to an array, it must be FALSE. From a look at uc_payment_load_payments() the only lookup criteria is the order ID.

Either the order ID we use here is incorrect, or no payment has been stored against the order. If $order_id is correct then the issue is most likely that no payment was inserted (and you prob need to debug why the call to uc_payment_enter() is not firing or firing with incorrect data). If $order_id is incorrect here then you'll need to see why that happened (the request should be at uc_dps_pxpay/complete/ORDER_ID, and the value should be passed into the function).

Maybe add a few dpm() or error_log() like this - dpm() shows debug in the browser while error_log goes to the configured PHP or apache (by default) error log. Those would show the order_id you're looking up with and result (presumably result is FALSE), and then you can compare the SQL which would be generated.

Code below untested ;)

  // Check for duplicate transaction
  if ($txn_id != $order->data['payment_details']['pxpay_DpsTxnRef']) {
    $comment = t('PxPay transaction ref: @txn_id', array('@txn_id' => $txn_id));

    dpm(array('order_id' => $order_id));
    error_log(print_r(array('order_id' => $order_id),1));

    $payments = uc_payment_load_payments($order_id);

    dpm(array('payments' => $payments));
    error_log(print_r(array('payments' => $payments),1));

    $order->data['payment_details']['pxpay_DpsTxnRef'] = $txn_id;

    // Check for duplicate transaction
    $duplicate_flag = FALSE;
    foreach ($payments as $payment) {
     if ($payment->comment == $comment) {
       $duplicate_flag = TRUE;
     }
    }
snlnz’s picture

Hey Chris,

Thanks for the detailed reply :)

So the output I got with devel enabled and your code inserted is:

... (Array, 1 element)
            order_id (String, 2 characters ) 44
        Krumo version 0.2a
        | http://krumo.sourceforge.net
        Called from /home/USER/websites/SITE/sites/all/modules/contrib/uc_paymentexpress/uc_dps_pxpay.pages.inc, line 87  
        ... (Array, 1 element)
            payments (Boolean) FALSE
        Krumo version 0.2a
        | http://krumo.sourceforge.net
        Called from /home/USER/websites/SITE/sites/all/modules/contrib/uc_paymentexpress/uc_dps_pxpay.pages.inc, line 92  
    Your DPS payment was successful.

Hope that gives you a better idea? I'm struggling to see what's wrong here :(

xurizaemon’s picture

Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new621 bytes

Try this?

snlnz’s picture

Hey Chris,

Crazy times, I tested it on local dev, apache all works perfectly no issue.

When I run it on the nginx server I'm getting redirected back to the site after DPS accepted payment with Drupal message:
Your DPS payment was declined. Please feel free to continue shopping or contact us for assistance.

The beers == owed to you are starting to rack up!

xurizaemon’s picture

So you're saying that this issue is resolved with the patch on local apache, but not on nginx?

* Please repeat the debug steps above to identify whether the same issue is what's happening on your nginx server.

* If you're running test transactions, remember that the cents priced will determine the response code. Eg $xx.76 is the secret trick to decline the transaction.

snlnz’s picture

Sorry I should've clarified.

Correct, local apache is fine, nginx gets the declined transaction on redirect back, yet dps is accepting it.

I repeated the debug steps but nothing is showing up in the error log or on screen with devel enabled, code inserted and error logging set to write to screen and log. Nothing is being generated at all strangely. I've checked the php logs, and syslog using tail whilst running the transaction.

The amount is the same every test, $1.00.

Just out of curiosity, I setup a brand new ubercart/d6 codebase on the nginx server, downloaded uc_paymentgateway, created a test product with amount $1.
Tested the transaction and exactly the same error was reproduced.

I'm going to run up a brand new server and test this further.

xurizaemon’s picture

Any chance the nginx server config is preventing large variables being dropped, like we saw with #1262340: $_GET value "result" empty on return from DPS due to suhosin configuration?

What do your watchdog & nginx logs say?

snlnz’s picture

The nginx servers get and post values are currently set to 8000.
Nothing shows up in the watchdog or nginx logs unfortunately really tricky to get any info out of this one.

New servers just about ready to test on so will report back asap.

snlnz’s picture

Status: Needs review » Fixed

Problem solved for nginx.

I found I had to manually add the line in the php.ini under the [suhosin] section which isn't there by default :(
I just made it a stab in the dark 8000 and all worked fine without patching.
suhosin.get.max_value_length = 8000

The reason I missed the config is because of the values have changed slightly and I recall this entry being there by default last time this issue came up.
Thanks heaps Chris for pointing me in the right direction. My shout next time I see you :)

xurizaemon’s picture

Bugger, should have got you to test the last patch from the suhosin thread above to check that it reports correctly. Thought that was already committed. If you want to bump your suhosin config back and see if that patch leaves a helpful watchdog message on nginx I'd greatly appreciate it.

snlnz’s picture

I did test with patch prior to changing the config. An on screen message appeared saying:
Server configuration prevented DPS transaction completion. Please advise site administrator to check Drupal logs for details.

It wasn't a successful transaction so I didn't mention it :)

xurizaemon’s picture

Committed patch from #6. Thanks Karu.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.