Error Log: Warning array expected parameter 2

 [Tue Nov 06 21:24:20.621004 2018] [php7:warn] [pid 17779] [client 10.0.1.232:54254] PHP Warning:  in_array() expects parameter 2 to be array, integer given in /var/www/html/library/options.inc.php on line 4009, referer: http://10.0.1.227/interface/patient_file/encounter/encounter_top.php?set_encounter=248891

I am trying to clean up my error log.
We are using Ubuntu 18.x and PHP 7.2.

The error message above has popped up. I was looking into it and what not sure what I am looking at and I was hoping to get a second opinion on what I think I am reading in the code.

Whoever wrote the notes, I would like to say thank you for a hint at what is supposed to be happening in this function.

It seems that the JSON is reduced to a string (is that right).
The test variable holds the string that is what is being looked for (needle in the haystack).

However, because the $options is a string and not an array. PHP is throwing this error.

Would it be better to use strpos here instead of in_array since $options is not a real array?

@robert.down @brady.miller @sunsetsystems

   $options = json_encode($t); // make it array.

This line is not really making it an array.

Can you post more of the code so we can see it in context? It might work to pass the method with array($t) as an argument

hmm,
this seems like a odd function:

Couple things:

  1. Shouldn’t line 4018 be $options = json_decode($options);
  2. And then shouldn’t line 4024 be behind a else statement?

@sjpadgett , thoughts on this?

-brady

Hi Guys, missed this thread. Sorry for delay.
When isOption() is called the routine assumes options to be json and if not the goal is to convert the legacy option modifier string to a json array for trueful testing. Otherwise if options is an array it just falls through.

The cleanest way to test if options is a json or string w/o doing a regex or chancing a null return from json_decode is to get the last error of function call thus, that is what line 4018 does, test if option is json(new modifiers) or string (legacy modifier).

Sure it is. A json array from a PHP array returned by str_split()…

I’m unable to recreate the warning which leads me to believe that maybe the LBF being called in encounter has a modifier syntax i’m not expecting. @juggernautsei is this warning prevalent or occasional? Can you look at the LBF called in warning message and maybe re-save or see if there is a modifier out of place.
Just trying to track down what I missed. Thanks

Here are my error log files. Yes, it is repeated constantly.

error.log (3).zip
error.log.zip (124.2 KB)
error.log.zip (124.2 KB)

Is there a LBF in common with the encounters that are throwing the warning? None of my forms are throwing the warning!!! i.e can’t recreate. Help me out here, anyone else recreate this.

Ok, I have a bunch of LBF that have been created. How do I figure out which one is the offending form or do you want the LBF tables? Or could you tell me what is passing through this function so I will know what to look for?

@juggernautsei
Okay, I found the issue Sherwin. Turns out we have three data type modifiers defined as numeric strings:
{id: ‘0’,text:’" . xla(‘Read Only’) . “’},
{id: ‘1’,text:’” . xla(‘Write Once’) . “’},
{id: ‘2’,text:’” . xla(‘Billing Code Descriptions’) . "’}];
Seems to have missed this when I wrote the routine so, it just goes to show, how important it is to pay attention to these warnings as this is definitely a bug.
I will fix and put up a P.R and also see if I can fix a few of the other warnings while here.
Thanks for bringing this up.
@brady.miller Once fixed will need to go in next patch. See ya on the other side :slight_smile:

Hey, were’d you get a video of my little brother?

:rofl:

I have to post more than 20 letters.

Appreciate you all!

Here is fix. @juggernautsei can you let me know how tests before I move on? Thanks.

hi @sjpadgett ,
Thanks for the code explanation (I didn’t have enough coffee in me and was confusing json_encode and json_decode :slight_smile: )
-brady

If anything it made me re-look and I realized json_decode was testing as an object rather than an array which is why the numeric string was returning as proper json syntax. Real fix was just adding the true param to json_decode.
Thanks all.

1 Like

I added this fix to the portal back port to 5.0.1 PR so can be in next 5.0.1 patch. If needed before patch(7) then one may get from my git or copy/paste from this commit: Portal fixes back port by sjpadgett ¡ Pull Request #1895 ¡ openemr/openemr ¡ GitHub
This bug fix is definitely a fix you will want in your 5.0.1 production.

Yes, @sjpadgett. I can update you. I will pull the code and deploy it.
Thanks for such quick work.

I have tested the code for the options.inc.php file and I have seen no new entries as for right now. I will update this entry at the end of business Monday.