I have the following code:
var_dump($cumulitive);
$y_axis_max = max($cumulitive)*1.3;
var_dump($y_axis_max);
It outputs the following:
array(16) {
[0]=>
int(0)
[1]=>
int(0)
[2]=>
int(0)
[3]=>
int(0)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(0)
[7]=>
int(0)
[8]=>
int(0)
[9]=>
int(0)
[10]=>
int(0)
[11]=>
int(4)
[12]=>
int(4)
[13]=>
int(4)
[14]=>
int(9)
[15]=>
int(9)
}
float(NAN)
As you can see, $y_axis_max is giving NAN. So I try this: I restart WampServer. It works now. I refresh the browser. Works again. refresh the browser again. Now it doesn't work, and I can't get it to work again without restarting Apache. From the 3rd request on it stops working.
It USED to work just fine. Then I changed some things. Specifically, I modified my app to use the DateTime class in a few places. But that shouldn't make this strange error occur. Any ideas on how to debug this?
If I call the $y_axis_max = .. line of code twice in a row, then I get this for $y_axis_max:
float(#.7)
What the heck is that?
EDIT: Seems that calling DateTime::diff earlier causes the error. Any workaround ideas?
max() will work on arrays. Looks like you have some form of corruption in your code. If one of the elements in the array is a NAN you will get this result. Try testing a smaller script on your server in order to isolate the problem.
Seems that calling DateTime::diff earlier causes the error. I just used a work-around so not to use it.
Related
<?php var_dump($argv); ?>
ok - run it directly - get what's expected.
$ php /tmp/check-arg.php -s test yellow bus
array(5) {
[0]=>
string(18) "/tmp/check-arg.php"
[1]=>
string(2) "-s"
[2]=>
string(4) "test"
[3]=>
string(6) "yellow"
[4]=>
string(3) "bus"
}
ok - so I want to run this script as if it were a command (it's a php script that replaces an existing command), so I created this script
$ vi /tmp/testingcommand
php /tmp/check-arg.php $1 $2 $3 $4 $5 $6 $7 $8 $9 $10
(edit - change the $10 to {10} is solution - or use "$#" instead of $1 $2...)
so I should be able to just
$ /tmp/testingcommand -s test yellow bus
array(6) {
[0]=>
string(18) "/tmp/check-arg.php"
[1]=>
string(2) "-s"
[2]=>
string(4) "test"
[3]=>
string(6) "yellow"
[4]=>
string(3) "bus"
[5]=>
string(3) "-s0"
}
OK - so where did that "-s0" come from? I've done some fiddling and it's what is in $argv[1] (-s) and a "0" (so in this case -s0)
Any ideas? happened on our RHEL7 as well as a Fedora 30 setup
since the script can be run either directly (php program.php) or via a script I can't just ignore the last index of argv[]
I guess I could check argv[0] for '...php' and keep all indexs and if no ...php then ignore last index
-s0 came from $10. That's $1 followed by 0.
Use ${10} to access parameter 10. You need curly braces whenever the parameter number is more than one digit.
Note that your code won't work properly if any of the arguments have spaces, because you're not quoting the variables. The variable value will undergo word splitting and wildcard expansion.
But if you quote all the variables, you'll get explicit '' values for the arguments that weren't supplied, which is probably not desired, either.
The correct way to reference all the arguments is with "$#".
php /tmp/check-arg.php "$#"
I am parsing an XML file in PHP as a DOMDocument. This is part of relatively stable code that I wrote awhile ago to parse our XML and has been working fine until recently. In the middle of a bunch of similar statements, I have the following line of code:
$appDomain = $domDoc->getElementsByTagName("appDomain")->item(0)->textContent;
This method throws an error "Trying to get property of non-object", but the code still goes through and works fine.
What's driving me nuts is the following. Using copy/paste I added the following line.
echo "". $domDoc->getElementsByTagName("appDomain")->item(0)->textContent;
$appDomain = $domDoc->getElementsByTagName("appDomain")->item(0)->textContent;
So now I'm running exactly the same code twice, one time echoing it and one time storing it. The echo correctly prints the value of the tag (which is Extract) from my XML, but I still get the error, and the error line is the assignment to $appDomain line, not the echo line.
Furthermore, if I add
echo $appDomain;
immediately after this call, it prints the correct value "Extract" as if no error has occurred. If I comment out the assignment to $appDomain, I appropriately get an "Undefined variable" error on the echo $appDomain line (I just did this to check that $appDomain isn't set somewhere else). If I then add a hardcoded $appDomain, like so:
echo "". $domDoc->getElementsByTagName("appDomain")->item(0)->textContent;
//$appDomain = $domDoc->getElementsByTagName("appDomain")->item(0)->textContent;
$appDomain = "Extract";
echo $appDomain;
Now the code prints "ExtractExtract" appropriately but I get the trying to get a property error on the FIRST echo line.
WHAT THE HECK IS GOING ON? The tag is in the XML (has been for awhile now, and this code has been working fine). The code correctly gets the element and gets it's text content and places it correctly in the variable $appDomain. But it still throws an error.
Also, the following var_dumps seem to behave exactly as they should:
var_dump($domDoc->getElementsByTagName("appDomain"));
echo "<br><br>";
var_dump($domDoc->getElementsByTagName("appDomain")->item(0));
echo "<br><br>";
var_dump($domDoc->getElementsByTagName("appDomain")->item(0)->textContent);
I get the following:
object(DOMNodeList)#3 (1) { ["length"]=> int(1) }
object(DOMElement)#2 (18) { ["tagName"]=> string(9) "appDomain" ["schemaTypeInfo"]=> NULL ["nodeName"]=> string(9) "appDomain" ["nodeValue"]=> string(7) "Extract" ["nodeType"]=> int(1) ["parentNode"]=> string(22) "(object value omitted)" ["childNodes"]=> string(22) "(object value omitted)" ["firstChild"]=> string(22) "(object value omitted)" ["lastChild"]=> string(22) "(object value omitted)" ["previousSibling"]=> string(22) "(object value omitted)" ["nextSibling"]=> string(22) "(object value omitted)" ["attributes"]=> string(22) "(object value omitted)" ["ownerDocument"]=> string(22) "(object value omitted)" ["namespaceURI"]=> NULL ["prefix"]=> string(0) "" ["localName"]=> string(9) "appDomain" ["baseURI"]=> string(62) "/Applications/MAMP/htdocs/Tmp/bowersjc/Experiment33/config.xml" ["textContent"]=> string(7) "Extract" }
string(7) "Extract" Extract
But I get the error on the last var_dump (and if I comment it out, I get no errors).
Again, WHAT THE HECK IS GOING ON?
I ran into the same error in a recursive class method, where the object was definitely an object, but the error (warning) kept happening.
First you can double check that it's really an object with is_object($el)
Sometimes recursion (xml parsers are recursive) and passing arguments into object methods can cause problems. It may have to do with the argument ->item(0). Try ->item()[0] for element 0, instead of argument 0.
I've encountered a very odd issue in regards to session variables and local variables in php.
I'm trying to figure out if I am not understanding something about sessions in php or if this is an issue with the php version my host is using.
Here is a very simple code to demonstrate the weird issue:
session_start();
var_dump($kenny);
var_dump($_SESSION['kenny']);
$_SESSION['kenny']='def';
var_dump($kenny);
var_dump($_SESSION['kenny']);
$kenny = 'abc';
var_dump($kenny);
var_dump($_SESSION['kenny']);
The first time I run the code, I get the following results (as one would expect):
NULL NULL NULL string(3) "def" string(3) "abc" string(3) "def"
I run it a second time (without closing my browser, of course), I get this now!
string(3) "def" string(3) "def" string(3) "def" string(3) "def" string(3) "abc" string(3) "abc"
I run it a 3rd, 4th, 5th time and so on, I get this!!!
string(3) "abc" string(3) "abc" string(3) "def" string(3) "def" string(3) "abc" string(3) "abc"
It looks to me like the session variable 'kenny' and local variable $kenny become aliases to one and the other after running the script more than once. hmm... I really don't think this is how session variables and local variables work in php. Please correct me if I'm missing something here.
My web host is running php 5.2.2. When I try this exact same code on other hosts running php 5.2.1, 5.2.14 and 5.3.1, they always give me what I expect:
1st time:
NULL NULL NULL string(3) "def" string(3) "abc" string(3) "def"
thereafter:
NULL string(3) "def" NULL string(3) "def" string(3) "abc" string(3) "def"
I checked the change log on php.net and didn't find anything that I can relate to that may address this issue. But like I mentioned, an earlier build (5.2.1) works ok, so that's very puzzling to me.
If anyone runs any other version of php 5.2.x, please give it a try and let me know if you see the same issue. Or if anyone has any insight into the issue, I'd really appreciate any feedback.
Thanks a million!
This is probably because the register_globals directive is on. It doesn't say it on that page that $_SESSION variables are included, but it says here:
If register_globals is enabled, then
the global variables and the
$_SESSION entries will automatically
reference the same values which were
registered in the prior session
instance. However, if the variable is
registered by $_SESSION then the
global variable is available since the
next request.
I am getting a new php warning when a POST data from a form on my page to my server. The warning is as follows:
PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0, referer: https://mywebsite.com/index.php
The thing is that my form does not have near 1000 input variables, so I am baffled as to why this is appearing. As a side note, I have not had this problem until recently and I suspect that when I ran yum update something changed/was installed that is causing this. Any advice or answers are appreciated.
EDIT 1:
So I did var_dump($_REQUEST) and got ~1000 single character strings. The first couple items in the array are what they should be, but then a bunch of stuff that I don't need submitted is broken down into single character strings. Thoughts welcome.
array(1001) {
["action"]=> string(10) "step1_show"
["submit"]=> string(6) "Step 1"
[0]=> string(1) "a"
[1]=> string(1) "c"
[2]=> string(1) "t"
[3]=> string(1) "i"
[4]=> string(1) "o"
[5]=> string(1) "n"
[6]=> string(1) "="
[7]=> string(1) "l"
[8]=> string(1) "o"
[9]=> string(1) "g"
[10]=> string(1) "o"
[11]=> string(1) "u"
[12]=> string(1) "t"
[13]=> string(1) "&"
[14]=> string(1) "p"
[15]=> string(1) "r"
[16]=> string(1) "o"
[17]=> string(1) "p"
[18]=> string(1) "e"
[19]=> string(1) "r"
[20]=> string(1) "t"
[21]=> string(1) "y"
[22]=> string(1) "="
[23]=> string(1) "3"
[24]=> string(1) "7"
[25]=> .....
ANSWER: It ended up being a problem with my submit handler. Thanks all for your input.
That's a new setting / value in PHP (related to a security update to prevent attacks to PHP scripts), so you get this after the update (before PHP 5.3.9 not set/available, suhosin users have a similar thing since ages).
Input values are of different kinds and array members count as well. So it's not enough to count form fields but also to take a look into the URL and other places related to input ($_GET, $_POST, $_SERVER, $_ENV, $_FILES, $_COOKIE ...).
See max_input_vars:
How many input variables may be accepted. Use of this directive mitigates the possibility of denial of service attacks which use hash collisions. If there are more input variables than specified by this directive, an E_WARNING is issued, and further input variables are truncated from the request. This limit applies only to each nesting level of a multi-dimensional input array.
There is two way to solve this problem.
.htaccess
php_value max_input_vars 10000
php
ini_set('max_input_vars','10000' );
I was on my mac machine using Laravel valet... did followings to fix the error.
On terminal php --ini to find out loaded PHP configuration file.
sudo nano that file, in my case it was sudo nano /usr/local/etc/php/7.3/php.ini
ctrl + w to search max_input_vars
In my case it was ;max_input_vars = 1000
Updated to max_input_vars = 2000
Save file.
valet restart to update new configuration.
That worked :-)
I fixed the max_input_vars issue via my web host admin panel (Littleoak)
I changed the max_input_vars = 0 to max_input_vars = 6000.
There are several installations of php on my server that the server company configured. I believe the max_input_vars = 0 is to prevent email spammers from using the server to send spam. The php.ini file lives somewhere, not sure where, but I was able to modify it via the cPanel on my site admin.
I've encountered a very odd issue in regards to session variables and local variables in php.
I'm trying to figure out if I am not understanding something about sessions in php or if this is an issue with the php version my host is using.
Here is a very simple code to demonstrate the weird issue:
session_start();
var_dump($kenny);
var_dump($_SESSION['kenny']);
$_SESSION['kenny']='def';
var_dump($kenny);
var_dump($_SESSION['kenny']);
$kenny = 'abc';
var_dump($kenny);
var_dump($_SESSION['kenny']);
The first time I run the code, I get the following results (as one would expect):
NULL NULL NULL string(3) "def" string(3) "abc" string(3) "def"
I run it a second time (without closing my browser, of course), I get this now!
string(3) "def" string(3) "def" string(3) "def" string(3) "def" string(3) "abc" string(3) "abc"
I run it a 3rd, 4th, 5th time and so on, I get this!!!
string(3) "abc" string(3) "abc" string(3) "def" string(3) "def" string(3) "abc" string(3) "abc"
It looks to me like the session variable 'kenny' and local variable $kenny become aliases to one and the other after running the script more than once. hmm... I really don't think this is how session variables and local variables work in php. Please correct me if I'm missing something here.
My web host is running php 5.2.2. When I try this exact same code on other hosts running php 5.2.1, 5.2.14 and 5.3.1, they always give me what I expect:
1st time:
NULL NULL NULL string(3) "def" string(3) "abc" string(3) "def"
thereafter:
NULL string(3) "def" NULL string(3) "def" string(3) "abc" string(3) "def"
I checked the change log on php.net and didn't find anything that I can relate to that may address this issue. But like I mentioned, an earlier build (5.2.1) works ok, so that's very puzzling to me.
If anyone runs any other version of php 5.2.x, please give it a try and let me know if you see the same issue. Or if anyone has any insight into the issue, I'd really appreciate any feedback.
Thanks a million!
This is probably because the register_globals directive is on. It doesn't say it on that page that $_SESSION variables are included, but it says here:
If register_globals is enabled, then
the global variables and the
$_SESSION entries will automatically
reference the same values which were
registered in the prior session
instance. However, if the variable is
registered by $_SESSION then the
global variable is available since the
next request.