DigiWallet payment module: Warning: Illegal offset type in isset or empty in includes/classes/order.php on line 241

[LuckyPiedro]

Hi, I have a problem with a DigiWallet payment module in Phoenix version 1.0.4.0. If I make a payment in DigiWallet's test mode with an abnormal outcome i.e. payment canceled or interrupted then I get a warning i.e.

Warning: Illegal offset type in isset or empty in /home/mytest/domains/mytestsite.com/public_html/includes/classes/order.php on line 241

Line 241 is in the cart () function in /includes/classes/order.php

A payment with a normal expiry, payment successful, which is handled well without any error messages.

The parameter $ payment, used in the class order.php, function cart (), with a var_dump gives the following result:

      function cart () {
      global $ customer_id, $ sendto, $ billto, $ cart, $ languages_id, $ currency, $ currencies, $ shipping, $ payment, $ comments, $ reference, $ customer_default_address_id;

       var_dump ($ payment); // i have added this statement result see below

      $ this-> content_type = $ cart-> get_content_type ();

      if (($ this-> content_type! = 'virtual') && ($ sendto == false)) {
      etcetera.....

     Result of var_dump:

     object (__ PHP_Incomplete_Class) # 19 (3)
          {["__PHP_Incomplete_Class_Name"] => string (7) "payment"
            ["modules"] => array (6) {
                                                      [0] => string (17) "targetpay_ide.php"
                                                      [1] => string (17) "targetpay_mrc.php"
                                                      [2] => string (17) "targetpay_deb.php"
                                                      [3] => string (16) "targetpay_cc.php"
                                                      [4] => string (14) "moneyorder.php"
                                                      [5] => string (7) "cod.php"
                                          }
            ["selected_module"] => NULL
          }

I got the software for this module (addon) from Digiwallet and would be suitable for Phoenix. I also reported this Warning to DigiWallet and they could not reproduce this error.

Is there anyone who has experience with this payment module or can say something about the result of var_dump? I would really appreciate it if you could give me any direction or solution to this problem.

general data:
website software: Phoenix version 1.0.4.0.
Server: System Linux
Server API: LiteSpeed V7.6
PHP: Version 7.1.33

[♥ecartz]

__ PHP_Incomplete_Class is what happens when the session is loaded before the class. 

This should not happen if you use a version of Phoenix with the autoloader and the payment module is in includes/modules/payment.  So one solution would be to update from 1.0.4.0 to 1.0.5.0 or 1.0.6.0.  That should get rid of the __ PHP_Incomplete_Class. 

Another issue though is that $payment should be a string, not an object.  $$payment should be the object.  So it is likely that there is a bug in the module where it sets $payment equal to something where it should have set $$payment (or $GLOBALS[$_SESSION['payment']]) to something. 

[LuckyPiedro]

Hi Matt, thank you for answering my question.

Your first answer is an option that I don't want to make at the moment because of a lot of changes such as layout, order_id with extension, etc. and the limited time.
I don't quite understand your second answer, "Another issue though is that $payment should be a string, not an object".

part of the cart () function where the warning is generated.

line
137      function cart () {
138       global $ customer_id, $ sendto, $ billto, $ cart, $ languages_id, $ currency, $ currencies, $ shipping, $ payment, $ comments, $ reference, $ customer_default_address_id;
                ....
                ....
                ....
                ....
241      if (isset($GLOBALS[$payment]) && is_object($GLOBALS[$payment])) {
242        if (isset($GLOBALS[$payment]->public_title)) {
243          $this->info['payment_method'] = $GLOBALS[$payment]->public_title;
244        } else {
245          $this->info['payment_method'] = $GLOBALS[$payment]->title;
246        }
247
248        if ( isset($GLOBALS[$payment]->order_status) && is_numeric($GLOBALS[$payment]->order_status) && ($GLOBALS[$payment]->order_status > 0) ) {
249          $this->info['order_status'] = $GLOBALS[$payment]->order_status;
250        }
251      }
            ....
            ....
            ....
            ....
352} // end function cart

The warning is generated in line 241, where it is checked whether it is an object. Maybe you want to tell me what I am missing / misinterpreting here.

I will certainly contact Digiwallet again and ask them to double-check the code of the plugin.

Sincerely,
Piet

[♥ecartz]

is_object($GLOBALS[$payment])

That checks to see if there is a global object named $$payment.  If it was checking for a global object named $payment, it would say

is_object($GLOBALS['payment'])

The warning is saying that $payment, which should be a string, is instead an object.  Because an object is not a valid array index key (in PHP), it complains when it attempts to dereference $GLOBALS (an array) with it.  Where dereference is just a fancy word for doing $GLOBALS[$payment].  Meaning to find the entry in $GLOBALS for the key $payment. 

It's also possible that the code is going down a weird path when there is an error.  It seems like something is doing

$payment = new payment();

while $payment is bound to the session value.  If this is a bug in 1.0.4.0, it won't get fixed now, as we've moved on to 1.0.6.0.  So any fixes would occur in 1.0.6.1 or later. 

[LuckyPiedro]

Thank you for your quick response and clear explanation.

I will see if I can find the point where it goes wrong and as soon as I know anything about where in the Phoenix code or a solution in the code of the plugin I will let you know.

Sincerely,
Piet

[LuckyPiedro]

Hi,

Well it looks like I took the wrong way to switch from osCommerce version 2.3.4 to, at that time, the most current Phoenix version 1.0.4.0.

There is a Dutch payment module from DigiWallet available in the apps market. However, it does not work in Phoenix version 1.0.4.0. and therefore I received, on request, a payment module from DigiWallet for Phoenix. However, this payment module also does not work with Phoenix and also gives the same error as described below. Although the provider indicates that it works if they test it themselves on Phoenix version 1.0.4.0.

The road to Phoenix 1.0.6.0. seems to me to be a dead end at the moment because the structure has changed so much that it undoubtedly requires a rigorous update in the payment module.

I hope there is someone in this forum with DigWallet payment module experience for Phoenix and maybe help me further.

The error message:
Warning: Illegal offset type in isset or empty in /home/mytest/domains/mytestsite.com/public_html/includes/classes/order.php on line 241

part of the cart () function ( in order.php) where the warning is generated.

line
137      function cart () {
138       global $ customer_id, $ sendto, $ billto, $ cart, $ languages_id, $ currency, $ currencies, $ shipping, $ payment, $ comments, $ reference, $ customer_default_address_id;
                ....
                ....
                ....
                ....
241      if (isset($GLOBALS[$payment]) && is_object($GLOBALS[$payment])) {   
242        if (isset($GLOBALS[$payment]->public_title)) {
243          $this->info['payment_method'] = $GLOBALS[$payment]->public_title;
244        } else {
245          $this->info['payment_method'] = $GLOBALS[$payment]->title;
246        }
247
248        if ( isset($GLOBALS[$payment]->order_status) && is_numeric($GLOBALS[$payment]->order_status) && ($GLOBALS[$payment]->order_status > 0) ) {
249          $this->info['order_status'] = $GLOBALS[$payment]->order_status;
250        }
251      }
            ....
            ....
            ....
            ....
352} // end function cart

Thank you in advance.

[♥ecartz]

If you just want to get rid of the error, try changing line 241 to

if (is_string($payment) && isset($GLOBALS[$payment]) && is_object($GLOBALS[$payment])) { 

As I said previously, the real problem is almost certainly in code that is setting payment somewhere. 

[LuckyPiedro]

Thanks for your comment.

After making the change, there are no PHP messages anymore.

The 3 activated payment methods give better results in the test mode but do not always function properly in the case of simulated actions such as 'cancel' or 'error' in the bank transfer. I imagine this has to do with the work-around. The actual error is still in the code.

What I don't understand is that because of this change, an extra check on "is_string ($ payment)", there is no PHP message anymore.

[♥ecartz]

29 minutes ago, LuckyPiedro said:

What I don't understand is that because of this change, an extra check on "is_string ($ payment)", there is no PHP message anymore.

The message says, "invalid offset".  A string is (by definition) a valid offset.  So what the message is telling you is that $payment is not a string (nor a  number).  With the check, it no longer gets to the point where it tries to use $payment as an array offset.  Because if it's not a string, PHP doesn't bother checking the rest of the expression.  This is called short circuit evaluation.