In the old form api, hook_form_alter had $form['#post'] available (with raw $_POST data) for checking submitted values. That's gone as of FAPI 3 landing. The attached patch sets $form_state['post'] for now.

Needs review by FAPI experts :)

CommentFileSizeAuthor
#11 form_18.patch4.99 KBchx
#8 form_17.patch4.99 KBchx
#7 form_16.patch3.56 KBchx
#5 form_15.patch449 byteschx
form-state-post.patch848 byteswalkah
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

code looks fine. trivial even ... perhaps elaborate on how you are using this.

walkah’s picture

Very simply it allows hook_form_alter to make it's form alterations based on submitted values. Specifically, for OpenID - since I'm altering the user_login form (and block) - I change the #validate and #submit values to use the openid submit function.

There are, of course, other possible usages - frankly, I consider this a regression - as the functionality was available in FAPI previously.

eaton’s picture

Status: Needs review » Reviewed & tested by the community

I think there would be ways to get around this -- other approaches to swaping #validation handlers -- but keeping $_POST around in the $form_state is probably the best solution for now; that's what $form_state is for.

My only thought is that it might be useful to keep $form_state['post'] around; even after the 'values' array is built it can be useful for comparison purposes...

Marking RTBC as-is, though. Thanks, walkah.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD.

chx’s picture

Status: Fixed » Reviewed & tested by the community
FileSize
449 bytes

Consistency.

chx’s picture

Status: Reviewed & tested by the community » Needs work

Consistency but let it be #post.

chx’s picture

Status: Needs work » Needs review
FileSize
3.56 KB

If the issue is what the title says then this is the correct way: add back $form['#post'] .

chx’s picture

FileSize
4.99 KB

While at it let's make the input for drupal_execute $form_state['post'] sounds more logical.

eaton’s picture

I agree wholeheartedly with the change to drupal_execute; calling the input for that form_values is pretty deceptive, since it's treated as post rather than the cleaned up values. Could lead to confusion.

eaton’s picture

Status: Needs review » Reviewed & tested by the community

And it even applies against the latest HEAD!

chx’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
4.99 KB

Ugh! I put the , TRUE to the wrong drupal_prepare_form call which would cause rebuilt form (we formerly called them multistep) to become #programmed ... this would have been a very hard to catch bug.

moshe weitzman’s picture

so, we want this one or no?

catch’s picture

Status: Needs review » Needs work

No longer applies - this been fixed elsewhere?

dpearcefl’s picture

Status: Needs work » Postponed (maintainer needs more info)

Is this still a problem in current D6?

dpearcefl’s picture

Status: Postponed (maintainer needs more info) » Needs work

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.