PHP Warning: addslashes() expects parameter 1 to be string, array given

[schoolboy]

We're getting quite a few of these on some of our sites:

PHP Warning: addslashes() expects parameter 1 to be string, array given in /home/XXXXXXX/public_html/includes/functions/functions_general.php on line 888

[schoolboy]

Interestingly... all are appearing in Cache Logs of sites we have INHERITED - not developed ourselves from scratch.

Likely therefore to be caused by some cranky add-on, so we will look for commonality across sites (which are using the same modules, and getting this warning) and we will also look at server log activity for time stamps.

But if anyone is experiencing the same warning, please let me know if you've nailed down the (probable) cause...

[picandnix]

Any luck with this error yet? I have it too. I think I've tied it down to account creation stage but before payment is made. Are your guilty sites using FEC?

[picandnix]

Actually it could be when removing item from cart?

[DrByte]

... in /home/XXXXXXX/public_html/includes/functions/functions_general.php on line 888

In v1.3.9, that would be part of the zen_db_input() function call.
And there are more than 100 places in core code (catalog side) that call that function, plus almost certainly dozens more in each addon the site is using.
You'll need to trace down every one of them to determine whether an array is being passed in any of those cases, and why.

[openvista]

This is in reference to Zen Cart 1.5.1 running on PHP 5.3.

I thought I'd pass along a possible solution.

For me, this problem traced back to the add-on Supertracker 1.1 (latest version). The reason I wasn't able to reproduce it initially is that this add-on allows you to exempt select IPs and since mine was exempted it wasn't performing the database insert at checkout success as it was for other visitors. During the final checkout process it passes an array to the zen_db_input() function, which of course just calls addslashes() which will no longer accept arrays under PHP 5.3. So my ad-hoc solution was the following on about line 860 of /includes/functions/functions_general.php:

  function zen_db_input($string) {  
     if (is_string($string)){ // ADDED to eliminate PHP warnings in myDEBUG logs related to input not being strings
       return addslashes($string);
     } else {
       return $string;
     }
  }

If anyone can think of a better solution or knows of a reason why I should not return an unprocessed string please let me know. As far as I can tell, the only thing that will happen to array content is that it will be written to the db as "Array" which may be more helpful than nothing. This assumes, of course, that the is_string() native PHP function can accurately determine string content and not let through something it shouldn't.

[DivaVocals]

Any luck with this error yet? I have it too. I think I've tied it down to account creation stage but before payment is made. Are your guilty sites using FEC?

This is what I was going to say as well.. I'm just now leaving work and will have to look when I get home, but this sounds an awful lot like a persistent error I was getting on a site I inheirited that was using FEAC..

[DrByte]

It would be much safer to fix the data being passed, since what you've suggested bypasses the sanitizing that was intended, and if the data isn't actually already reliably clean you could be introducing a SQL Injection risk by your change.

[picandnix]

This is in reference to Zen Cart 1.5.1 running on PHP 5.3.

I thought I'd pass along a possible solution.

For me, this problem traced back to the add-on Supertracker 1.1 (latest version). The reason I wasn't able to reproduce it initially is that this add-on allows you to exempt select IPs and since mine was exempted it wasn't performing the database insert at checkout success as it was for other visitors. During the final checkout process it passes an array to the zen_db_input() function, which of course just calls addslashes() which will no longer accept arrays under PHP 5.3. So my ad-hoc solution was the following on about line 860 of /includes/functions/functions_general.php:

  function zen_db_input($string) {  
     if (is_string($string)){ // ADDED to eliminate PHP warnings in myDEBUG logs related to input not being strings
       return addslashes($string);
     } else {
       return $string;
     }
  }

If anyone can think of a better solution or knows of a reason why I should not return an unprocessed string please let me know. As far as I can tell, the only thing that will happen to array content is that it will be written to the db as "Array" which may be more helpful than nothing. This assumes, of course, that the is_string() native PHP function can accurately determine string content and not let through something it shouldn't.

I wonder if you might be on to something...
I have just pm'd Andrew to ask him to take a look at this thread.

[openvista]

It would be much safer to fix the data being passed, since what you've suggested bypasses the sanitizing that was intended, and if the data isn't actually already reliably clean you could be introducing a SQL Injection risk by your change.

After some testing I've found that continuing to pass the data along when it's actually an array doesn't work since other dependent functions assume a string value when they execute zen_db_input(). So the warning remains in the log regardless. I've also tried just the first half of the conditional which implicitly blocks all but strings from being returned. This results in the login form no longer working (I'm sure that's just the beginning of problems it creates).

So I've taken Dr Byte's advice (as I was nervous in the first place with my duct-taped solution leading to SQL injection), rolled back the functions_general.php code and gone searching for a solution at the source of the problem. I'll move over to the Supertracker support thread (http://www.zen-cart.com/showthread.p...tracker/page31) to discuss this particular issue.

Thanks for the help!