Posted by sun on May 21, 2012 at 12:52am
8 followers
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | forms system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | needs backport to D7 |
Issue Summary
Discovered in #1324618: Implement automated config saving for simple settings forms:
Problem
- When setting
$form['#tree'] = TRUE;and$form['#parents'] = array('foo');on the top-level $form itself, Form API is unable to find its own required form_id, form_build_id, and form_token values in the submitted form values.
This is an edge-case usage scenario, for which I doubt it makes sense to write tests for.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| drupal8.form-tree-true.0.patch | 1003 bytes | Idle | PASSED: [[SimpleTest]]: [MySQL] 36,602 pass(es). | View details |
Comments
#1
Sorry, forgot the totally important detail about also having custom #parents on the $form itself.
#2
Discussed with @chx that enforcing explicit #parents is better than #tree FALSE.
We also discussed whether the other form processing/validation code shouldn't rather check for $form['form_token']['#value'] instead of relying on submitted form values, but that would inherently add a dependency on the $form structure. Out of the two choices, enforcing #parents made more sense.
#3
Good to go.
#4
I reviewed this patch but it was not 100% clear. Given that both chx and sun approved it, and that all tests pass, I committed it anyway.
#5
Rerolled.
#6
Thanks!
#7
I had trouble getting my head around this one too. Ultimately, I think it just comes down to the fact that there's lots of code in the form API that looks for these things in the top level of $form_state['input'] or $form_state['values'], so we need to ensure that they will actually always be in the top level.
Out of curiosity, why? I would have found this code a lot easier to understand with #tree set to FALSE, because that's the standard way to accomplish the above. Is the concern that someone altering the form might be likely to change #tree by accident?
Anyway, this patch works fine as is, so although it seems like there might be room for a followup to clarify the code comments, etc.... I committed it to 7.x. Thanks!
http://drupalcode.org/project/drupal.git/commit/121b348
#8
Automatically closed -- issue fixed for 2 weeks with no activity.