[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?
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
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
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.
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.