Posted by shimmyshack on 05/16/07 09:30

On May 16, 6:05 am, kenoli <kenol...@gmail.com> wrote:
> There is a form on the page with a post method and some submit
> buttons, however, none of them are triggered here. The script is
> called using an <a>tag with this kind of thing:
>
> <a href = "<? echo 'http://' . $_SERVER['PHP_SELF'] . '?pid=' .
> $row[id]; ?>" >Delete</a>
>
> It just leaves the page and starts again at the top of the script. It
> works fine. What caused me to catch it is that I was using:
>
> if (!isset($_POST))
>
> to set a switch variable in the case that the data had not been sent
> via a post submit. It wasn't working so I checked and found the
> $_POST variable was sure enough set, but empty.
>
> What would be setting the $_POST variable if the form wasn't
> triggered.
>
> --Kenoli
>
> On May 15, 5:24 pm, Mike P2 <sumguyovrt...@gmail.com> wrote:
>
> > On May 15, 7:38 pm, kenoli <kenol...@gmail.com> wrote:
>
> > > I have a script that submits form data via a "post" method to another
> > > script. I have an href link in the destination script that links back
> > > to itself for processing form data on that page with some "get" data
> > > appended to the URL. I noticed that after clicking on that link and
> > > sending the action back to itself, a check of isset($_POST) returns
> > > true while displaying the content of $_POST displays an empty array.
> > > I had expected isset($_POST) to return false, thinking the script
> > > would unset the $_POST array when the <a> link sent it back to
> > > itself. Instead, it leaves $_POST set but empty.
>
> > > What is the convention here?
>
> > > --Kenoli
>
> > You should check if some variable from the posting form is set instead
> > of the entire $_POST. The submit button or something like that. If the
> > variables are the same for some reason, you can add a hidden field in
> > the posting form and check if that is set.
>
> > -Mike PII

try it with GET, COOKIE, REQUEST, FILES, SESSION, all will be set but
empty (if you arent populating them).
they are superglobals, always set in the current scope.

[Back to original message]