I was working with old legacy code and checked if it's running with PHP7. I got an exception (Array to string conversion) with following code:
json_decode($json_string)
->$array['id']
->foo
What helped was to use the curly brackets:
json_decode($json_string)
->{$array['id']}
->foo
My question is, was that already wrong PHP5 and if not, which change is the reason for that? Could not find anything because did not know for what to search... One idea I had is that the new introduced AST produces this behavior?
I think you are right. From what I know in PHP5 that works without any exception, but PHP 7 wants to be just a little bit more strict, because cases like this can cause a lot big problems after when not used correctly.
Related
Following the Google Calendar API quickstart for PHP, I've followed the steps but, got the verification code and instead of getting the expected output " No upcoming events found " I get a
No idea how to move forward from here...
Welcome to StackOverflow!
I've encountered this very same error with numerous WP plugins that had been developed before PHP 5.6 and where programmers have been, well, lazy. Once these plugins get upgraded to PHP 7, exceptions are thrown for things that were mere deprecation warnings a few years ago.
From what I see in your logs, you have a dependency somewhere on Guzzle. According to Guzzle's own documentation, the recent versions require PHP 7.2.5 to work. Therefore, I can only assume that you are:
using a plugin or something similar that is based on an outdated version of Guzzle or you're using Guzzle yourself, but for some reason relying on a deprecated version of it (in the former case, you'd have to pester the plugin developer to update their own dependencies...);
using PHP 7.2 or perhaps even a later version.
You should be using PHP 7.4 or 8.0 as of mid-2021 (everything else has been deprecated), so your installation is fine. It's just the obsolete code coming from that outdated version of Guzzle that requires updating.
So, a simple fix for that issue is to look at the culprit — open on your favourite editor the file C:\xampp\htdocs\api\vendor\guzzlehttp\guzzle\src\Handler\CurlFactory.php and scroll down to line 67 (where the exception was thrown).
According to the trace you've posted, on that line you should have something like:
if (count($some_variable_name_here) [...]) { [...] }
What happened, in this case, was the following:
The count() function requires what PHP calls a Countable object. Generally speaking, historically, these were arrays of some sort.
Lazy programmers often use count() simply to check if the array is empty or not. In the pre-PHP7 days, count(NULL) was defined as being 0 or false, like so many other things in PHP. In other words: if the array was either empty (i.e. initialised but still without any item stored inside) or uninitialised (i.e. still assigned to NULL) or non-existent (i.e. a new variable which had not been declared before), then, by definition, count(NULL) was false.
This allowed lazy programmers to check for a handful of potentially different error conditions with a single if (!count($myArray)) { [...] do this; }. In other words, you would just execute that code inside brackets if $myArray existed, was correctly initialised, and had at least one valid element. All that with a 'simple' check!
Unfortunately, from the perspective of the interpreter and JIT compiler, as well as many other modern optimisation tools used by recent versions of PHP, this is terribly inefficient — besides being very sloppy programming. Starting with PHP 5.6, this misuse of count() became flagged as a warning, then later shown as a deprecated, and finally started throwing exceptions.
So, in your case, whatever is on line 67, count($some_variable_name_here) has been passed an empty/invalid variable/array/object, and while this would be fine before PHP 7, it now throws an exception: count() will not work with so-called 'uncountable' objects, and for all purposes, an unexisting/empty/invalid object is uncountable by definition.
To fix it, all you need to do is to check first if the object is valid and not null, and then you can check if it has any elements inside it. In other words, instead of having something like:
if (count($some_variable_name_here) [...]) {
[... do something ...]
}
change it to:
if (!empty($some_variable_name_here) && is_countable($some_variable_name_here) && count($some_variable_name_here) [...]) {
[... do something ...]
}
Note that empty() is a shortcut for !isset($var) || $var == false, and that PHP evaluates expressions from left to right, aborting as soon as a final result is known. If the variable is empty, the first check will immediately return true and the remaining checks will not even be called; by design, empty() does not throw an error or an exception and is safe to use in all scenarios where variables are in an 'unknown' state.
In many cases, you might get away just by checking if the object $some_variable_name_here is countable or not; a NULL object is not countable, so, it would also fail. In other cases — most frequent these days — you might not really know what has been passed: it might not be a valid, countable object. It might have more than one element, or zero. It might be just garbage and not properly initialised. Or any other possible combination. In those cases, being extra-careful with the checks (as opposed to being sloppy and relying upon PHP to do something useful with an otherwise useless variable/array/object) pays off.
Anyway, I've checked, and the current version of Guzzle's CurlFactory.php still has a count() for function release(), which is what is called before the exception is thrown. However, your own code is clearly different (at the time of writing, the current version has the count() on line 80, not 67), so it's very hard to say if you can correct it easily (there might be other, more subtle errors in the code calling release()...).
One assumes that Guzzle's latest version will fix these and other issues you might have — mostly because they demand PHP 7.2.5 or later, and that means that they have made changes to fix earlier things that didn't work as they should, and such changes were only possible with PHP 7.2.5.
Thus the recommendation is to upgrade your version of Guzzle. If there is any good reason to keep an outdated (and potentially bug-ridden and security-flawed) version around, well, now you know how to do a simple fix. At the very least, your code won't throw an exception; with luck, it will even work as you expect...
Happy hunting!
I upgraded from php 5 to 7.2, and there is no problem at local (some changes needed, but it solved).
One of my function not working in production server.
The code looks like this:
$someBool = in_array($some, array("asd", "fgh", "etc"));
If I make a var_dump on this, the result is UNKNOWN:0, but if I make a vardump exactly below this (there is no any if station before dump), the function works correctly, end the dump result will be bool (true) or bool (false).
(I don't overwrite this variable)
Again if I comment the var_dump line, the function works incorrectly.
There is anybody who has idea what can cause this behaviour?
Thanks for your help.
In the original function:
$needCmdText = in_array($fieldName,array(
'cmdpreid','cmdpostid','cmdskipid',
'cmdfixid','cmdexpid','cmdsysid'
));
Where the $fieldName always 'cmdexpid' from the client. (at my test cases)
And a funny news, a simple echo solve the problem too, but it should be under this.
I changed the php 7.2 to 7.1, which solved the problem without any code changing. (No need to dump, to solve).
I think there is a strange bug in php 7.2, which doesn't occure in windows environment.
I am trying to execute this code (it was working on php5, now I'am on php7):
$this->links->$data[$te]['attributes']['ID'] = $data[$te]['attributes']['URL'];
But I get this error:
ContextErrorException: Notice: Array to string conversion
Thanks in advance
This is down to the change in how complex variables are resolved in PHP 5 vs 7. See the section on Changes to variable handling here: http://php.net/manual/en/migration70.incompatible.php
The difference is that the expression:
$this->links->$data[$te]['attributes']['ID']
is evaluated like this in PHP 5:
$this->links->{$data[$te]['attributes']['ID']}
and like this in PHP 7:
($this->links->$data)[$te]['attributes']['ID']
See https://3v4l.org/gB0rQ for a cut-down example.
You'll need to amend your code to be explicit, either by using {} as appropriate, or by breaking it down into two lines. In this case, where you've got code that works fine in PHP 5, pick the former, since it will mean the behaviour stays consistent in all versions of PHP.
i mentioned a strange issue regarding this topic.. I "solved" it myself, but wanted to discuss if anybody understands the problem behind this.
This query works fine with php 7.0:
$image = (ProductImage::all()->where('productHistory_id', $product->history_id))->first();
And causes a syntax error, unexpected '->' (T_OBJECT_OPERATOR).
This query (without the brackets) works fine with php 7.0 and 5.6:
$image = ProductImage::all()->where('productHistory_id', $product->history_id)->first();
whaaaat?!
Kind regards,
Nico
PHP type checking was eavily revamped between 5.x and 7.x
In both versions the expression:
ProductImage::all()->where('productHistory_id', $product->history_id)
return an instance of a QueryBuilder.
I suspect the presence of the parenthesis cause in earlyer versions of the PHP interpreter to understand it as a scalar value (as in (1+1)+1)) instead of an object value.
This explains why you get an unexpected object operator because PHP 5.X doesn't understand the return of the (...) expression as an object correctly.
This bug is caused exactly by the same parsing error as this one about array dereferencing. It was present on PHP pre 5.4 and was caused by the intereter not detecting the return of a function as an array without using a variable to store it beforehand.
Also on a side note, the parenthesis doesn't change anything as operations on objects are always executed left to right in a statement. May I recommend you to avoid adding useless noise to your codebase?
when I was looking for some MVC framework, I got the website:
http://www.phppatterns.com/docs/design/archive/model_view_controller_pattern
however, like the code listed there makes me confused about references.
For example:
$dao=& new DataAccess ('localhost','user','pass','dbname');
$productModel=& new ProductModel($dao);
each instance it makes, it adds '&' before the new operator, what does it exactly mean? the reference to the instance? Actually, I removed all the '&' before all these kind of instances and the code still works perfectly.
Another, codes like :
function ProductView (&$model) {
$this->model=& $model;
}
I really think it could be revised like:
function ProductView (&$model) {
$this->model=$model;
}
Am I right? what's the differences between these two? Actually, like the MVC code example listed above? if you revise the code like I did, the code still works.
Then, I got this post somewhere else:
http://schlueters.de/blog/archives/125-Do-not-use-PHP-references.html
does it make sense? any suggestions about this would be helpful.
Prior to PHP version 5 objects were passed by value and you had to explicitly specify the ampersand to get the object by reference.*
In PHP 5+, all objects are passed by reference and thus using ampersand is redundant.
Furthermore, as of PHP 5.3.0, code like the above will generate a STRICT error of "Assigning the return value of new by reference is deprecated".
If you're curious about the historical use (PHP 4 or before) of "$o =& new Object()" code see php-by-reference (in particular, the accepted answer there provides a good explanation).
To summarise:
in PHP 5 or above, it makes no difference. The code will work as expected with no memory or other differences.
In PHP 5.3 you might get some STRICT notices complaining about this usage (assuming you have STRICT notices turned on).
In PHP 4.x (or earlier) this method was used to prevent unnecessary duplication of objects.
(*) Passing references around is a good thing - no need to create copies of objects when you only need the one instance.