possible bug in FAPI 5.6 (query string killed)
I'm trying to have a form that has a query string other than q/clean path. eg. $form['#action'] = url($_GET['q'],$query); going somewhere like /obj/action/?id=37 Avoiding to specify #action doesn't pass the additional query string. $form['#action'] = url($_GET['q'], drupal_query_string_encode($_GET,Array('q'))); This put in the <form action what I'd expect but later browser get redirected to the path without the additional query. So somehow it is impossible to pass a non positional parameter. whatever is returned from add_item_form_submit get encoded. Am I missing something? Is there a way to handle non positional parameters? thx -- Ivan Sergio Borgonovo http://www.webthatworks.it
If the only thing you want to do is redirect the user after form submission, just set the #redirect property of the form. $form['#redirect'] = 'my/custom/path'; Alternatively, you could call your form with a parameter: http://example.com/my/form?destination=my/custom/path If you want to do some more advanced processing, I would put the additional information you want to add in a form element of type 'value', and it will be available in the form validation and submit handlers without ever appearing to the user. $form['my_custom_path'] = 'my/custom/path';
On Mon, 14 Jan 2008 09:37:19 -0800 "Florian Loretan" <floretan@gmail.com> wrote:
If the only thing you want to do is redirect the user after form submission, just set the #redirect property of the form.
$form['#redirect'] = 'my/custom/path';
Alternatively, you could call your form with a parameter:
$_GET stuff get encoded or trimmed. No matter if I put it into the #action, #redirect or "hardcode" it into the return of _submit. My interest in $_GET in spite of hooks is I've a bunch of parameters that are common to forms and are useful in the final form landing page. If they were "positional" I'd have to extract them in different ways accordingly to the length of the path in the menu hook. So similar form may redirect to /bla/bli/blu?id=37 /bim/bum?id=37 /bau?id=37 and there is a part of common code that will pick up the id and build up some content. But no matter how I try to pass an additional query param through the FAPI it gets mangled or chopped. It get chopped/mangled just after the _submit hook. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Mon, 14 Jan 2008 19:01:49 +0100 Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
But no matter how I try to pass an additional query param through the FAPI it gets mangled or chopped.
It get chopped/mangled just after the _submit hook.
While drupal_goto accept a $query all FAPI functions pass down just a $path. If you put the $query in the $path it get encoded wrongly. If you keep it in the $query it get lost. I didn't follow all the FAPI chain but no matter how it may or may not be kosher if it works I'm going to put a drupal_goto at the end of my _submit function. I'd prefer to do otherwise and be able to see stuff get down to the FAPI from #action/#redirect to end without this trick. Is there any reason $query is not propagated other than it is boring thing to code? thx -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo wrote:
So similar form may redirect to /bla/bli/blu?id=37 /bim/bum?id=37 /bau?id=37
and there is a part of common code that will pick up the id and build up some content.
But no matter how I try to pass an additional query param through the FAPI it gets mangled or chopped.
It get chopped/mangled just after the _submit hook.
Try $form['#redirect'] = array('blah/bli/blu', 'id=37'); See http://api.drupal.org/api/file/developer/topics/forms_api_reference.html/5#r...
On Mon, 14 Jan 2008 09:13:55 -1000 Rob Barreca <rob@electronicinsight.com> wrote:
See http://api.drupal.org/api/file/developer/topics/forms_api_reference.html/5#r...
thanks a lot you saved me some sleep. I didn't see the Array form. -- Ivan Sergio Borgonovo http://www.webthatworks.it
participants (3)
-
Florian Loretan -
Ivan Sergio Borgonovo -
Rob Barreca