QUERYSTRING not displaying in URL nor setting in PHP from JavaScript [RESOLVED]

[Phenix]

I've been using the following code successfully to display two buttons that would browse to either the Manager page or to the History page.

<FORM METHOD="GET" ENCTYPE="application/x-www-form-urlencoded">
<button type="submit" onClick='JavaScript: form.action="admin/index.php";'>Manager Page</button>&nbsp;
<button type="submit" onClick='JavaScript: form.action="history/index.php";'>History Page</button>
</FORM>

Now I'd like to pass a QUERYSTRING when the Manager button is pressed, "dir=a", but it does not display in the browser URL Address box and certainly is not present in $_GET['dir'] from PHP.

<FORM METHOD="GET" ENCTYPE="application/x-www-form-urlencoded">
<button type="submit" onClick='JavaScript: form.action="admin/index.php?dir=a";'>Manager Page</button>&nbsp;
<button type="submit" onClick='JavaScript: form.action="history/index.php";'>History Page</button>
</FORM>

I even tried changing onClick to onSubmit with no success.

<FORM METHOD="GET" ENCTYPE="application/x-www-form-urlencoded">
<button type="submit" onSubmit='JavaScript: form.action="admin/index.php?dir=a";'>Manager Page</button>&nbsp;
<button type="submit" onClick='JavaScript: form.action="history/index.php";'>History Page</button>
</FORM>

Now I just noticed that the ? is appearing (so I assume it was always appearing) in my browser URL Address box appended to index.php like so index.php?, even though I had no querystring. JavaScript is turned on in my browser.

What am I missing? And why would I intermittently see a session id in the URL Address box? I'm not turning cookies on and off.

I might try passing another session variable around instead of the querystring, but I don't see why I should have to.

[The Hobo]

Try this:

<FORM METHOD="GET" ENCTYPE="application/x-www-form-urlencoded"> 
<input type="hidden" name="dir" value="a">
<button type="submit" onClick='java script: form.action="admin/index.php";'>Manager Page</button>  
<button type="submit" onClick='java script: form.action="history/index.php";'>History Page</button> 
</FORM>

[Phenix]

Thanks Hobo!

Was that weird or what?

Now I won't need that work-around for executing php code conditionally. I'll put the conditional code in value="(...)".

[CornedBee]

That wasn't weird at all. If the form submit method is GET then the browser first strips away any custom get string that might be there.

It isn't fault of PHP either, that is done by the browser.

[Phenix]

I'd swear I've seen querystrings attached to form submissions (in the view source for the action). Are you saying they must have all been POST methods?

I did think it might have been the browser, possibly with JavaScript turned off (but JavaScript Form Validation was working), but then I noticed the question mark displaying in the URL Address box depending on my use of PHP Sessions.

[techgnome]

<FORM METHOD="GET" ENCTYPE="application/x-www-form-urlencoded" action="admin/index.php"> 
<input type="hidden" name="dir" value="a">
<button type="submit">Manager Page</button>  
</FORM>
<FORM METHOD="GET" ENCTYPE="application/x-www-form-urlencoded" action="history/index.php"> 
<button type="submit">History Page</button> 
</FORM>

[phpman]

this thread doesn't make sense.

why go out of your way to use javascript when you don't have to.

<FORM METHOD="POST" action="admin/index.php?dir=a"> 
<input type="submit" value="Manager Page">  
</FORM>

<FORM METHOD="POST" action="history/index.php"> 
<input type="submit" value="History Page">
</FORM>

if you are worried about javascript being off them why do it that way?

also why do you have the enctype in there? you can have it set int the php.ini to put the session_id in the url automatically, or you can do it in the htaccess file. depending on your host.

EDIT: in order to send variables to anotehr page VIA a GET from a form you first have to put the varialbe in the forms action. making the variable in a hidden form input will not send it in the url. if you want hidden form inputs you have to use POST

[Phenix]

The Hobo's technique solved my problem, but we can continue this for best practices.

why go out of your way to use javascript when you don't have to.

JavaScript is in there because I was using it anyway for form validation, and I had seen it as a solution for using multiple buttons to submit a form. So I was building on JavaScript and having multiple FORMS per each single button seemed incorrect. For the two button part that I posted about, I agree as far as best practices, that it would make sense to just use html and the multiple forms.

your code: ...

I never would have thought to use POST since I wasn't sending anything large or private.

if you are worried about javascript being off them why do it that way?

My PC had been acting funny (things solved? by rebooting), so I thought it may have turned off JavaScript without my knowing it.

also why do you have the enctype in there?

I think this is the default ENCTYPE, but I just put it in explicitly.

you can have it set int the php.ini to put the session_id in the url automatically, or you can do it in the htaccess file. depending on your host.

I mentioned that I was using PHP Sessions because I thought it might help diagnose the problem.

in order to send variables to anotehr page VIA a GET from a form you first have to put the varialbe in the forms action. making the variable in a hidden form input will not send it in the url. if you want hidden form inputs you have to use POST

I haven't tried your code. But wouldn't it disagree with CornedBee's comments about the browser stripping away custom querystrings? I actually didn't need to hide the data, I just needed to pass it.

Thanks for your opinion.

[phpman]

the browser doesn't strip away strings.

how can it if you send a form POST or GET.

you can have this

<form action="page.php?action=log" method="POST">

<input type="hidden" value="1" name="member">


so you have that. it is set to POST and will put in the query string "action=log" also it will send the hidden variable.

so how can it strip the query string? maybe I am confused?

but of course if you set it to GET than what ever the forms action is will be the query string in the url

[CornedBee]

phpman:

<form action="myfile.php?some=other" method="post">
<input type="hidden" name="other" value="some" />
</form>

Will result in the target URL sent:
myfile.php?some=other
and in PHP:

$HTTP_POST_VARS: other->some
$HTTP_GET_VARS: some->other 

But this:

<form action="myfile.php?some=other" method="get">
<input type="hidden" name="other" value="some" />
</form>

Will result in the target URL sent:
myfile.php?other=some
and in PHP:

$HTTP_GET_VARS: other->some 

because the browser strips away the query string in the action and instead appends the one generated by the get form.

[phpman]

thanks for explaining that. I never use GET so I was unaware of that happening.

[Phenix]

CornedBee,
So then what I could have done was to use the code I had in my original post of this thread but change from the GET method to the POST method (and I still would have received $_GET['dir']=a)?

<FORM METHOD="POST" ENCTYPE="application/x-www-form-urlencoded"> 
<button type="submit" onClick='java script: form.action="admin/index.php?dir=a";'>Manager Page</button>  
<button type="submit" onClick='java script: form.action="history/index.php";'>History Page</button> 
</FORM>

[CornedBee]

Yes, that should have worked.

[The Hobo]

Originally posted by CornedBee

$HTTP_POST_VARS: other->some
$HTTP_GET_VARS: some->other 

$HTTP_GET_VARS: other->some 

The $HTTP_ globals are deprecated and should not be used or referenced.

[CornedBee]

Whatever...

$_GET and $_POST if you want.

[The Hobo]

Originally posted by CornedBee
Whatever...

If you want to use and demonstrate deprecated functionality that may not exist in future releases, go right ahead.

But it's not a good idea if you ask me.

[CornedBee]

I knew that the expand-globals feature was deprecated, but I didn't know about the HTTP_* vars. Why did they change it?

[The Hobo]

Originally posted by CornedBee
I knew that the expand-globals feature was deprecated, but I didn't know about the HTTP_* vars. Why did they change it?

They wanted to have a way to have the variables to be available in every scope without having to be defined global. So rather then change the way the $HTTP_ variables worked, they just added the superglobals. Why they did it that way, I'm not sure.

Personally, I like them better just because they're shorter to type.

There are also security issues, but that's more for $var and $_POST['var'], but I'm sure $HTTP_ vars took care of that, too.

I highly doubt they $HTTP_ vars will be removed, but I still think it's best to use the superglobals just incase.