I came across this forum as it had a solution for an error like this. My error is this:
"Notice: Undefined index: Submit in C:\sokkit\site\joomla102\components\com_report\report.php on line 22"
"Submit" is the value of which the form has been submitted, would this be related to my query a number of lines before this value is tested?
No code, no help ! (please use the [ php ] ... [ /php ] tags, without spaces of course)
Undefined index means that there was a call made to an array, but the given index does not exist in the array. Indexes are case SENSITIVE...
suntra wrote:Undefined index means that there was a call made to an array, but the given index does not exist in the array. Indexes are case SENSITIVE...
Does this apply to Global arrays?
Edit:
@list(,$title,,,,,$section_id) = mysql_fetch_array($query_content);
# I have not called the primary key from this database array
if (mysql_num_rows($query_content) == 1 && ($section_id == _REQUEST_SEC | $section_id == _RESPONSE_SEC) ){
if ($_POST['Submit']){ # This is the line the error is on
What does the "<input name="Submit" ...>" look like in the source ? How is name="Submit" spelled ? It is "submit", "Submit", "SUBMIT", ... ?
Instead of code such as
if (!$_SESSION['user']) {, you should be using something like:
if (!empty($_SESSION['user'])) {or
if (!isset($_SESSION['user']))<input type="submit" name="Submit" value="Report" />
Hmmm.. strange...
What if you print_r($_POST) ? Can you see something with "Submit" ?!
echo '<pre>';
print_r($_POST);
echo '</pre>';
Just to clarify - do you see this error message only before you submit the form, and not when you actually submit the form?
If this is the case, then there's nothing wrong with your code (minus the fact it's not written properly) - it's doing exactly what it's supposed to. That's why you should address the issue mentioned in my post above.
bradgrafelman wrote:Just to clarify - do you see this error message only before you submit the form, and not when you actually submit the form?
I have never seen the error myself, my client has passed it onto me when he ran the script. So I'm trying to fix this blindfolded.
bradgrafelman wrote:If this is the case, then there's nothing wrong with your code (minus the fact it's not written properly) - it's doing exactly what it's supposed to. That's why you should address the issue mentioned in my post above.
I think it's the package I've been designated to use, it has a global registering script changing all $_*[(key)]-s to $GLOBAL[(key)] which I am now experimenting with.
Saying my code is not "written properly", I don't see what is and what isn't properly written. I understand what you've posted but I don't think they matter (in this case) as the bool will return true or false in all three of the cases.
treesforlunch wrote:it has a global registering script changing all $_*[(key)]-s to $GLOBAL[(key)] which I am now experimenting with.
Ah, another deprecated, improper coding method. This is basically mimickin the register_global directive, which has long ago been classified as a security risk and as such highly deprecated (in fact, it doesn't even exist anymore as of PHP6).
treesforlunch wrote:I don't think they matter (in this case) as the bool will return true or false in all three of the cases.
Well, they "don't matter" if you don't care about generating notices like the one you've pasted. Since you pasted that error to us, I figured they did matter to you.
bradgrafelman wrote:Ah, another deprecated, improper coding method. This is basically mimickin the register_global directive, which has long ago been classified as a security risk and as such highly deprecated (in fact, it doesn't even exist anymore as of PHP6).
Yeah, that's what I was thinking but it seems to be the method used in this package.
bradgrafelman wrote:Well, they "don't matter" if you don't care about generating notices like the one you've pasted. Since you pasted that error to us, I figured they did matter to you.
The package is probably intended as a temporary stopgap measure to allow developers to port older code to the "newer" superglobals without having to rewrite everything at once. Since they'll be gone in PHP 6 I guess the developers figured that >5 years' warning was plenty.
