Document that $form_state['redirect'] can contain url options like query, not just a path [#284468]

Currently it is not possible to specify query parameters when specifying a 'redirect' url through the $form_state. A very, very simple change would enable this while maintaining full backward compatibility. This change is just exposing the functionality which already exists in drupal_goto(), but is limited by drupal_redirect_form().

This is actually a two part request.

1.) drupal_redirect_form() should accept an additional (third) parameter for query parameters, which would be passed to drupal_goto() as its second parameter. The default value for this new/third parameter to drupal_redirect_form should be null, which would ensure backward compatibility since the second parameter to drupal_goto() already assumes a default value of null.

2.) The call to drupal_redirect_form() from drupal_process_form() should allow the specification of $form_state['redirect_query'] (or some other similarly named key) to be passed as that new/third parameter. This will allow the specification of query parameters as easily & consistently as specifying $form_state['redirect'].

Comments

Comment #1

carteriii CreditAttribution: carteriii commented 19 July 2008 at 02:42

Well, after even more reading of drupal_redirect_form(), I now see that it checks to see if the $redirect is an array, in which case it passes that array to call_user_func_array. This in fact lets a user pass query parameters by using a line such as

$form_state['redirect'] = array('newurl', 'queryparam1=val1&queryparm2=val2);

I humbly suggest this very worthy capability be added to some documentation somewhere. I really have looked all over and have never seen this mentioned or even an example of someone else using it. Surely I can't be the first.

Comment #2

Pasqualle

🇭🇺 Budapest

CreditAttribution: Pasqualle commented 16 September 2008 at 00:53

Version:

6.3

» 7.x-dev

Comment #3

effulgentsia CreditAttribution: effulgentsia commented 7 March 2010 at 01:36

Title:	drupal_redirect_form should mirror drupal_goto, accepting URL query parameters from $form_state	» Document that $form_state['redirect'] can contain url options like query, not just a path
Component:	forms system	» documentation
Category:	feature	» task

I agree that making this existing D6 and D7 feature known would be good. Currently FAPI documentation is a bit of a mess. For example, where should all the interesting keys of $form_state be documented? Should we open a meta issue or issue tag for trying to get a handle on this beast?

Comment #4

jhodgdon

she/her

English

CreditAttribution: jhodgdon commented 8 March 2010 at 15:51

effulgentsia: Yes, we probably do need to have more/better documentation on the Form API somewhere.

I think the best place to document the elements of $form_state would be on the Form API @defgroup page:
http://api.drupal.org/api/group/form_api/7

I also think that the information about redirecting should be added to drupal_redirect_form(), as was requested in the original issue report here.

What else do you think we should document about $form_state? Things I can think of:
- How to extract the values, and how it's different depending on tree/not-tree

I guess that is the main thing I have ever extracted out of $form_state... Anything else that should be documented?

Comment #5

jhodgdon

she/her

English

CreditAttribution: jhodgdon commented 31 May 2011 at 15:50

Status:

Active

» Closed (duplicate)

rfay is working on $form_state documentation on
#859970: Cleanup form_api $form_state docs - keys in 2 places, missing some

I think we should close this as a duplicate.

Comment #6

carteriii CreditAttribution: carteriii commented 31 May 2011 at 17:04

That other node you reference says it is for version 8.x-dev. Is the doc really not going to get updated for v7, since the information certainly does apply to versions earlier than 8? Perhaps it's not a big deal not to have it documented back in v6 and v7. I trust whatever decision you guys make; just wanted to make sure.

Comment #7

jhodgdon

she/her

English

CreditAttribution: jhodgdon commented 31 May 2011 at 18:37

In the Drupal project, our policy is that all bugs get fixed in the in-development version first (which is 8.x right now), and then if appropriate, the fix also gets added to 7.x, 6.x, etc. In this case, 7.x would be definite (probably the same patch would get committed to 7.x and 8.x at the same time), and then we would hopefully also have someone make an equivalent fix to the 6.x documentation.