Undefined index Notice on existing Indices

[ag_47]

I've been making some changes/upgrades to a page, and noticed the warning messages in the error log.

>> Undefined index: indexName in /path/page on line X

Everything used to work perfectly (and it still does actually), and no warnings are generated on my machine (running 5.2.6; the host is running 5.2.8).
I tried printing the array (POST) and all the reported indecies are there. I tried printing the return value of isset() of an index in question (returned true), but a warning is still generated on the next line..

What I have is a form is being posted to the same page, but a javascript function first modifies the action field of the form (and attaches a (GET) variable to the url) before submitting. This is what I added while upgrading - am I missing something?

If you need further details, please don't hesitate to ask.
Thanks.

[coopster]

In which superglobal array are you attempting to use that index, $_POST or $_GET? And do you see the index defined in that particular superglobal array?

[penders]

What I have is a form is being posted to the same page, but a javascript function first modifies the action field of the form (and attaches a (GET) variable to the url) before submitting. This is what I added while upgrading - am I missing something?

This should be OK. Both the $_GET[] vars from the action URL and the $_POST[] vars from the form should be populated.

NB: The names are case sensitive, so 'Name' and 'name' are different.

[ag_47]

@coopster
The indecies are in POST, and yes, they are defined (both by printing the POST array or checking with isset() ). The script actually executes no problem and the data submitted in the form gets processed no problem - that's why this puzzled me.
Note: I haven't tested anything with REQUEST (see if any warnings arise from the same indecies)..

[penders]

The script actually executes no problem and the data submitted in the form gets processed no problem - that's why this puzzled me.

It might still work because the (empty) value that it defaults to is still valid?

...and no warnings are generated on my machine...

If 'display_errors' is Off then they won't be output to the browser. E_NOTICE's are not necessarily reported by default as they do not necessarily indicate an error, although I would have thought that an 'Undefined Index' should be fixable?!

...but a warning is still generated on the next line.

And what is that next line? You could perhaps post your code block.

[ag_47]

1. Empty values are actually not allowed (in the algorithm). And of course I tested with actual data - it did get processed.
2. Display errors is On, for all errors (E_ALL and STRICT, the local server for testing)
I intentionally generated an Undefined index error on the local side, to make sure an error is printed (which is did - but nothing is generated for the actual code)

Here is what's basically happening (roughly). Sorry for not including code examples before, I didn't want to over-complicate things by providing too much detail.

if(isset($_POST['my_var'])){ //added for Testing 
echo 'OK'; //OK is displayed on form submission 
} 
if($_POST['my_var'] == 'Some_val'){ //An error is generated at this line, for my_var 
..do some stuff 
} 
//...another case: 
$_POST['another_var'] = str_replace(.., $_POST['another_var']);//single error generated  
some_func($_POST['another_var']); //no errors

All errors seem to be generated during the first occurrence of an index, once it get's re-assigned (to itself with minor changes) it's no longer a problem..

Thanks for all the help.

[eeek]

once it get's re-assigned (to itself with minor changes) it's no longer a problem..

Well, yeah, of course. That creates the index if it wasn't already there.

[penders]

It sounds as if your code is being called twice (perhaps in error? try echoing a $COUNT++ - global variable?)... the first time that index is not defined. I would have thought your code should read more like:

if(isset($_POST['my_var'])) { 
 //echo 'OK'; //OK is displayed on form submission  
 if($_POST['my_var'] == 'Some_val'){ //An error is generated at this line, for my_var  
  ..do some stuff  
 } 
}

Always checking that $_POST is set before it is used. Is your code executed when the page is first rendered?

[ag_47]

Hi, well, I'm baffled.
Again, the script used to work smoothly. It still does, without any errors on my local machine, and the unusual ones on the server. There were at least 5 different indecies that would generate errors, the first one being as I mentioned above. Anyway..I decided to try a different check to see if the form is still processed and if errors are generated:

if(isset($_POST['my_var']) && $_POST['my_var'] == 'Some_val'){ 
 ..do some stuff  
 }  

Well, it worked, and this seems to have suppressed ALL the errors (even for other indecies).
Note that having the isset() in a separate if() statement above the the variable doesn't help.
Still not sure why this is the case.. but it works! (I don't normally check all the variables with isset like this (but my other means).. )

Thanks for all the advice.

[penders]

Again, the script used to work smoothly. It still does, without any errors on my local machine, and the unusual ones on the server.

Perhaps you just didn't notice the server errors before? Has PHP been upgraded? Has the level of error_reporting changed?

Note that having the isset() in a separate if() statement above the the variable doesn't help.

Do you mean a completely separate if() as in your example above? Well, that would only work if you did something (or set something) that prevented the next if() from firing. But (just to clarify) these two statements are the same (logic wise):

if(isset($_POST['my_var'])) { 
 if($_POST['my_var'] == 'Some_val') { 
  ..do some stuff  
 }  
}

if(isset($_POST['my_var']) && $_POST['my_var'] == 'Some_val') { 
 ..do some stuff 
}

(But the 2nd one is more tidy, and possibly more efficient)

Anyway..I decided to try a different check to see if the form is still processed...

Just a point, how do you check to see if the form is processed?

if (form is processed) { 
 ..process all form data 
 ..all form elements should be set - should be no need to check? 
 ..(apart from possibly checkboxes etc.) 
}

[ag_47]

Perhaps you just didn't notice the server errors before? Has PHP been upgraded? Has the level of error_reporting changed?
..Do you mean a completely separate if() as in your example above?

No, I would have noticed them before. PHP being upgraded was one of the reasonable explanation I could think of..but I'm not sure if that's what happned.

Yes, separate if like in the example above. I don't see how that's different from combining them..
The way the form is processed is I check to see if some 'crucial' variables are set, then filter the variables and check size restrictions (so empty case would result in an error)..