Notice: Undefined index...

[FutureShock]

I have since recently turned up my error reporting on a production site
to E_ALL to ensure I am using 'best practices' when writing out code.

So far it has helped me discipline myself with initializing my
variables. I am running into a problem with my $_POST array though.

I am self-referencing a form page for processing, so at the beginning I
am looking for the existence of certain $_POST variables for processing.

I am setting an 'action' field to 'login' for example.

I have done this on several occasions with no problems and even in this
case there is no fatal error. I am however receiving a NOTICE that my
$_POST variables I am looking at is undeclared.

"Notice: Undefined index: action"

I cannot openly see a way to declare the $_POST['action'] prior to
checking it since it is set by the server when the page is loaded.

Here is my actual code snippet:

if($_POST['action'] === 'login') {
//process data//
}

Will I need to learn to ignore this specific error or is there something
I am not seeing?

Thanks
Scotty

[Charles Calvert]

On Sat, 16 Aug 2008 21:02:05 -0700, FutureShock <fu*********@att.net>
wrote in <Zn*****************@flpi143.ffdc.sbc.com>:

[snip]

>"Notice: Undefined index: action"

I cannot openly see a way to declare the $_POST['action'] prior to
checking it since it is set by the server when the page is loaded.

Here is my actual code snippet:

if($_POST['action'] === 'login') {
//process data//
}

Use the function isset():

$action = isset($_POST['action']) ? $_POST['action'] : '';
if ($action == 'login')
{
// process data
}

Now you have a declared variable that will have either the value
posted or a default value. You can use a different default value
depending on the type the variable holds (e.g. 0 or -1 if numeric).
--
Charles Calvert | Software Design/Development
Celtic Wolf, Inc. | Project Management
http://www.celticwolf.com/ | Technical Writing
[phone] | Research

[FutureShock]

Charles Calvert wrote:

On Sat, 16 Aug 2008 21:02:05 -0700, FutureShock <fu*********@att.net>
wrote in <Zn*****************@flpi143.ffdc.sbc.com>:

[snip]

>"Notice: Undefined index: action"

I cannot openly see a way to declare the $_POST['action'] prior to
checking it since it is set by the server when the page is loaded.

Here is my actual code snippet:

if($_POST['action'] === 'login') {
//process data//
}

Use the function isset():

$action = isset($_POST['action']) ? $_POST['action'] : '';
if ($action == 'login')
{
// process data
}

Now you have a declared variable that will have either the value
posted or a default value. You can use a different default value
depending on the type the variable holds (e.g. 0 or -1 if numeric).

BINGO!!!

* writes this one down in notebook.

Thanks very much for your time.

So as long as I am not trying to look at the value of it, it won't
complain about it.

Scotty

[Nicolas Bouthors]

FutureShock nous disait :

if($_POST['action'] === 'login') {
//process data//
}

Will I need to learn to ignore this specific error or is there something
I am not seeing?

I'm always starting by :
if ($GLOBALS['_SERVER']['HTTP_METHOD'] == "POST") {
// Do stuff
header("Location: self.php");
exit();
}

This avoids your problem of undef item in $_POST *and also* forces the
user to use GET for viewing a form. Therefore a page refresh NEVER
re-posts stuff.

Cheers,

Nicolas

--
Nicolas - 06 20 71 62 34 - http://nicolas.bouthors.org/album/

[Jerry Stuckle]

Nicolas Bouthors wrote:

FutureShock nous disait :

>if($_POST['action'] === 'login') {
//process data//
}

Will I need to learn to ignore this specific error or is there something
I am not seeing?

I'm always starting by :
if ($GLOBALS['_SERVER']['HTTP_METHOD'] == "POST") {
// Do stuff
header("Location: self.php");
exit();
}

This avoids your problem of undef item in $_POST *and also* forces the
user to use GET for viewing a form. Therefore a page refresh NEVER
re-posts stuff.

Cheers,

Nicolas

Completely worthless. It doesn't allow you to process information
posted to the page and display them, for instance.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Nicolas Bouthors]

Jerry Stuckle nous disait :

Completely worthless. It doesn't allow you to process information
posted to the page and display them, for instance.

Assuming the rest of the page starts with a mysql_fetch it does ;)
The intent is to always post to change data, and to always get to view
data.

My opinion anyway, glad you shared yours,

Nico
--
Nicolas - 06 20 71 62 34 - http://nicolas.bouthors.org/album/

[Jerry Stuckle]

Nicolas Bouthors wrote:

Jerry Stuckle nous disait :

>Completely worthless. It doesn't allow you to process information
posted to the page and display them, for instance.

Assuming the rest of the page starts with a mysql_fetch it does ;)
The intent is to always post to change data, and to always get to view
data.

My opinion anyway, glad you shared yours,

Nico

Not at all. For instance, how are you going to post information back to
the page, validate it, and if it's incorrect, display the data with an
error message?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Andrew Poelstra]

On 2008-08-17, Jerry Stuckle <js*******@attglobal.netwrote:

Nicolas Bouthors wrote:

>Jerry Stuckle nous disait :

>>Completely worthless. It doesn't allow you to process information
posted to the page and display them, for instance.

Assuming the rest of the page starts with a mysql_fetch it does ;)
The intent is to always post to change data, and to always get to view
data.

My opinion anyway, glad you shared yours,

Nico

Not at all. For instance, how are you going to post information back to
the page, validate it, and if it's incorrect, display the data with an
error message?

Save the invalid data in $_SESSION and redirect back to the original page
with $_GET["err"] set or something, instead of redirecting to the success
page.

--
Andrew Poelstra ap*******@wpsoftware.com
To email me, use the above email addresss with .com set to .net

[Jerry Stuckle]

Andrew Poelstra wrote:

On 2008-08-17, Jerry Stuckle <js*******@attglobal.netwrote:

>Nicolas Bouthors wrote:

>>Jerry Stuckle nous disait :
Completely worthless. It doesn't allow you to process information
posted to the page and display them, for instance.
Assuming the rest of the page starts with a mysql_fetch it does ;)
The intent is to always post to change data, and to always get to view
data.

My opinion anyway, glad you shared yours,

Nico

Not at all. For instance, how are you going to post information back to
the page, validate it, and if it's incorrect, display the data with an
error message?

Save the invalid data in $_SESSION and redirect back to the original page
with $_GET["err"] set or something, instead of redirecting to the success
page.

This is probably one of the worst ways to do it. Not only does it
require extra processing on both the server the the client, you now have
to keep track of additional data within the $_SESSION. Additionally,
you're doing the data entry on one page and validation on another -
which means if there is any change in the form, you have to update (at
least) two pages, instead of just one.

It means a lot of completely unnecessary work for both the computers and
the programmer.

Much cleaner is to post back to the same page, validate the data and if
it's good, do whatever you need with the data. As a final step (and
only a final step), just redirect to a "thank you" page or whatever else
is appropriate.

That way you're not doing unnecessary redirects for error handling and
you keep everything in one file. Much cleaner.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Michael Fesser]

..oO(Nicolas Bouthors)

>FutureShock nous disait :

>if($_POST['action'] === 'login') {
//process data//
}

Will I need to learn to ignore this specific error or is there something
I am not seeing?

I'm always starting by :
if ($GLOBALS['_SERVER']['HTTP_METHOD'] == "POST") {
// Do stuff
header("Location: self.php");
exit();
}

This avoids your problem of undef item in $_POST *and also* forces the
user to use GET for viewing a form. Therefore a page refresh NEVER
re-posts stuff.

Ugly, too complicated and even violating the HTTP RFC. The correct way
is to check that the POST values exist before you want to use them.

Micha

[FutureShock]

Jerry Stuckle wrote:

Andrew Poelstra wrote:

>On 2008-08-17, Jerry Stuckle <js*******@attglobal.netwrote:

>>Nicolas Bouthors wrote:
Jerry Stuckle nous disait :
Completely worthless. It doesn't allow you to process information
posted to the page and display them, for instance.
Assuming the rest of the page starts with a mysql_fetch it does ;)
The intent is to always post to change data, and to always get to view
data.

My opinion anyway, glad you shared yours,

Nico
Not at all. For instance, how are you going to post information back
to the page, validate it, and if it's incorrect, display the data
with an error message?

Save the invalid data in $_SESSION and redirect back to the original page
with $_GET["err"] set or something, instead of redirecting to the success
page.

This is probably one of the worst ways to do it. Not only does it
require extra processing on both the server the the client, you now have
to keep track of additional data within the $_SESSION. Additionally,
you're doing the data entry on one page and validation on another -
which means if there is any change in the form, you have to update (at
least) two pages, instead of just one.

It means a lot of completely unnecessary work for both the computers and
the programmer.

Much cleaner is to post back to the same page, validate the data and if
it's good, do whatever you need with the data. As a final step (and
only a final step), just redirect to a "thank you" page or whatever else
is appropriate.

That way you're not doing unnecessary redirects for error handling and
you keep everything in one file. Much cleaner.

I have found that keeping all the form entry, processing, validating and
error reporting on one page makes my job tons easier.

And as Jerry said, now you only have one page to alter if you need to
change anything.

Thanks
Scotty