|
|
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.
Navigation:
[Reply to this message]
|