So currently I'm trying to fix up some old code for a stats server for a game (that is definitely outdated, and has been replaced recently with a new version). MUCH of the code is deprecated, so it's kind of guesswork on fixing it right, but I found a section thats completely broken that I have no idea how to fix, and it's causing a fatal error.
The code is as follows
for ($i=0; $i<$armyCount; $i++)
{
$summary['total']['time'] += $armies[0]['time'.$i];
$summary['total']['win'] += $armies[0]['win'.$i];
$summary['total']['loss'] += $armies[0]['loss'.$i];
$summary['total']['score'] += $armies[0]['score'.$i];
$summary['total']['best'] += $armies[0]['best'.$i];
$summary['total']['worst'] += $armies[0]['worst'.$i];
$summary['total']['brnd'] += $armies[0]['brnd'.$i];
}
The errors I get are as follows
Notice: Uninitialized string offset: 0 in C:\xampp\htdocs\dontneedthis\playerstats.inc.php on line 136
Fatal error: Cannot use string offset as an array in C:\xampp\htdocs\dontneedthis\playerstats.inc.php on line 136
I've seen similar questions asked, and seen how they were resolved, but I don't fully understand how it was done, so don't quite know how to go about fixing this one. Any assistance would be awesome, and I fully intend to release the bugfixed and fully working code (whenever I get that done) to the community that remains.
It looks like your $armies[0]['time'.$i] is initialized as an empty string and not as an array (likely $armies= "").
Notice: Uninitialized string offset: 0
That means that php tries to access your string-variable $armies as an array. If the string is non-empty then this would result in getting single letters from that string. But it seems that $armies is an empty string and so getting the letter with index 0 is not possible.
Fatal error: Cannot use string offset as an array
means that the result of the operation above (which showed the notice) cannot be accessed as an array. Remember that $armies is a astring and the first letter of the string was accessed and the result of this attempt will be accessed as an array.
Try resolving how the $armies variable is filled and why its filled the wrong way.
$armies is an empty string, and you are treating it as any array, in an unrecoverable way.
Show us what $armies should look like, what you get when you var_dump($armies);, and the code from where you assigned it, and we'll help you work out what went wrong.
Related
This question already has answers here:
PHP Notice: Array to string conversion only on PHP 7
(2 answers)
Array to string conversion - Variable function name calling
(1 answer)
Closed 11 months ago.
[NOTE: I solved this problem in the course of drafting the
question, but figured I would proceed with posting it for future
reference, since my extensive searching on the warnings delivered did
not provide the solution and I figure this might help someone in the
future.]
I have a class Thing that has properties $subthing_1, $subthing_2, $subthing_3, all of which are objects:
class Thing {
...
public $subthing_1; // object of type Subthing
public $subthing_2; // object of type Subthing
public $subthing_3; // object of type Subthing
...
}
If I want to get a particular subthing in an instance of Thing, I can do:
$thing->subthing_1
and this works just fine to deliver that subthing. But I want to generalize which of the subthings are called, so I have a routine that gets the name of a particular subthing, either 'subthing_1', 'subthing_2', or 'subthing_3', and stores it in a string in an array element. Thus, $subthings[4] has string value 'subthing_1', for example, and
$thing->$subthings[4]
should deliver exactly the same as $thing->subthing_1.
If I do
var_dump($subthings[4]);
the result is
string(10) "subthing_1"
and for
var_dump($thing);
the result is
object(Thing)#4 (87) {
...
["subthing_1"]=>
object(Category)#59 (12) {
...
}
...
}
Which is all fine and good. However, when I try to do this:
var_dump($thing->$subthings[4]);
I get this:
Warning: Array to string conversion ...
Warning: Undefined property: Thing::$Array ...
Warning: Trying to access array offset on value of type null ...
This confused me for a long time, because I couldn't see where an array was being converted to a string. $subthings[4] is clearly a string, as indicated by var_dump($subthings[4]), not an array.
These warnings are appearing in PHP 8.1 for code that worked just fine in PHP 5.5.
Eventually I reasoned that there must have been a syntax interpretation change somewhere between these two PHP versions.
Whereas in PHP 5.5, $thing->$subthings[4] is interpreted as $thing->{$subthings[4]}, in PHP 8.1 $thing->$subthings[4] is interpreted as {$thing->$subthings}[4].
I have searched high and low for documentation of this change, but I guess I am not hitting on the right keywords. I hope someone here can supply an answer for where this change is documented.
The SOLUTION is to surround the arrays with curly braces to enforce the expected (and formerly default) parse ordering:
$thing->{$subthings[4]}
As pointed out by Don't Panic, this evaluation syntax change is documented here:
https://www.php.net/manual/en/migration70.incompatible.php#migration70.incompatible.variable-handling.indirect
We have an old version of CakePHP that we've moved to a new server running PHP 5.6 and we've started to recieve this error when adding a product to the basket:
Warning (2): Illegal string offset 'AddBasketData'
[APP/controllers/personalisation_controller.php, line 848]
Here is line 848 within the file:
if (is_array($this->data['AddBasketData'])) {
$personalisation_data['Personalise'] = $this->data['AddBasketData'];
}else {
$personalisation_data['Personalise'] = array();
}
Could anyone shed any light on this, I think it's down to the specific PHP version we're running now but any help would be great.
Thanks
Transforming my comments into an answer :
The problem here seems to be that $this->data is a string and not an array.
You should test this first, then check if the offset AddBasketData exists, and finally if the offset AddBasketData is an array :
if (is_array($this->data) && isset($this->data['AddBasketData']) && is_array($this->data['AddBasketData'])) {
$personalisation_data['Personalise'] = $this->data['AddBasketData'];
} else {
$personalisation_data['Personalise'] = array();
}
Of course, that will only correct the symptoms (which is the raised warning), you might have some code debugging to do to find out why $this->data is a string instead of an array.
As noted by #roberto06 in the comments to your question, the reason you're getting the error is because you're trying to treat a string value as an array.
The reason for that specific error message is because you can use the array-offset notation to fetch a single character from the string. Just like you'd do in C's string arrays. But this only support numerical indices, and not a string index as shown in the code you posted.
Now, the easy way to stop the error from occurring is to simply test the type of the data, and whether or not the given index actually exists.Like so:
if (is_array ($this->data) && !empty ($this->data['AddBasketData'])) {
$personalisation_data['Personalise'] = $this->data['AddBasketData'];
} else {
$personalisation_data['Personalise'] = array();
}
However, seeing as you're not suddenly getting this error after update hints towards something else being the issue. Especially since the code you posted expects the value stored in the Personalise index to be an array. I'd trace where the $this->data member gets set, and changed, to see if you can find the underlying reason for why this apparent change in behavior. This might be the side-effect of a more nefarious subtle bug, after all.
I have a variable $newExtract[$x][3]. When I try to explode it as:
explode("/", $newExtract[$x][3])
It gives me error message:
"Notice: Undefined offset: 3 in C:\xampp\htdocs\torrent\classes\sm9.class.php on line 63".
But, when I echo it using echo $newExtract[$x][3]; die();, it gives me the result as 13/08/2012 20:58.
Can anyone help me what is happening? Why, I am not able to explode it?
Thanks
I've seen several places in PHP where implicit string conversion (or string dereferencing, in this case) causes issues and the simplest path to sanity is using an intermediate variable:
$date = $newExtract[$x][3];
explode("/", $date);
It seems to show up more often with certain internal functions, and I usually run into it more with objects and __toString(), but this wouldn't be the first time for this situation, either.
Now I am dealing with PHP but I`ve stucked with a strange issue:
I am making a simple foo for string length:
function slen($str) {
$len;
for ( $len=0; $str[$len]; $len++ ) {
/* while tehre is a symbol in $str continue counting, old C metnod */
}
return (int)$len;
}
it`s on as a code, and outputs the length but it booms with an PHP warning message :
PHP Notice: Uninitialized string offset: 3 in /home/ilian/Desktop/SERVER/ex4.php on line 5
And on my line 5 is the for loop initialization. So I got that PHP might be confusing by not knowing what kind of variables it checks for TRUE in that array because it can be
"Array", "HELLO", "MESS", 50 and length is 4 which is correct, but in the case I aam checking a simple string for length. Any easygoing explanation?
The problem is that at some point your condition ($str[$len]) will try to access an offset beyond the end of the string. That's your stopping condition, but that stopping condition throws the notice, since accessing an undefined offset is considered an error (and rightly so). You'll need to check whether the offset exists using isset($str[$len]), which does not throw a notice.
You don't have to write a function to get the length of a string, PHP has this built in for you in several internal functions:
strlen - Length of a string
mb_strlen - Length of a string which may have multi-byte characters within it
count - Length of an array or count of items in an object
If all you need is to count how long a string is, go with strlen, for arrays you'd use count. Much better than rolling your own.
As many of you already know, PHP 5.4 alpha has been released. I have a question regarding the following.
Simplified string offset reading.
$str[1][0] is now a legal construct.
How exactly does $str[1][0] work?
EDIT: http://php.net/releases/NEWS_5_4_0_alpha1.txt
It just means that when reading a string offset PHP returns a string again, on which you again can access an offset. (And on that access yet another offset. It gets funny with $str[0][0][0][0][0][0])
Before PHP 5.4 you would get an "Cannot use string offset as an array" error.
This is a side effect, and was mentioned in the proposal here:
http://php.markmail.org/thread/yiujwve6zdw37tpv
The feature is speed/optimization of string offsets.
Hi,
Recently I noticed that reading of
string offset is performed in two
steps. At first special string_offset
variant of temporary_variable is
created in
zend_fetch_dimension_address_read()
and then the real string value is
created in
_get_zval_ptr_var_string_offset().
I think we can create the real string
in the first place. This makes 50%
speed-up on string offset reading
operation and allows to eliminate some
checks and conditional brunches in VM.
The patch is attached (don't forget to
regenerate zend_vm_execute.h to test
it). However it changes behavior in
one bogus case. The following code now
will emit "b" (currently it generates
a fatal error - cannot use string
offset as an array).
$str = "abs";
var_dump($str[1][0]);
I think it's not a problem at all. "b"
makes sense because "abs"[1] -> "b"
and "b"[0] -> "b".
I'm going to commit the patch in case
of no objections.
Thanks. Dmitry.
This can actually create some interesting bugs when you upgrade code from php 5.3 to 5.4.
In 5.3 this construct would return false:
$array = array("This is a string");
echo isset($array[0][0][0]);
In 5.4 this would return true.