Posted by jover on September 2, 2011 at 6:45am
5 followers
Jump to:
| Project: | Date |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
I'm using a custom multistep form on a node with several date fields spread over multiple steps.
To hide the date fields which should not be visible on certain steps, I use #access=FALSE (just like any other field though).
$form[$field]['#access'] = FALSE;The outcome is that all date fields are not saved at the end of the multistep form (on node_save)...
A quick and dirty hack is to hide the date fields with HTML instead of using the #access variable.
$form[$field]['#prefix'] = '<div style="display:none;">';
$form[$field]['#suffix'] = '</div>';However, this little hack causes other functionality not to work properly, for example prefilling the #default_value of a date field using the value of a date field of a previous step.
The following ticket describes possibly related bug: #1144074: does not play well with multistep / does not validate correctly when #access=false
Comments
#1
Renamed the issue from 'Dates not saved by #access=FALSE on multistep forms' as it's a more generic issue.
To reproduce:
- Create a date field and add to a node type.
- In a module, set the #access to user_access('administer nodes') on that date field using hook_form_alter().
- Logged in as a user with administer nodes permission (user 1), create a node and fill in the value of the date field.
- Logged in as a user without administer nodes permission (user 2), edit the node and save.
- Edit the node again as user 1, the value has been wiped.
This issue happens regardless of which widget is used.
(I'm having this issue with the latest development version.)
#2
Didn't knew the problem was so general, but it seems to be correct (so new issue title is better).
#3
For module developers, there's a fairly simple workaround. This isn't working code, just to give an idea:
<?php
function MYMODULE_form_alter(&$form, $form_state, $form_id) {
//Testing here of the form(s) you want to alter
$form['THE_DATE_ELEMENT']['access'] = user_access('THE_PERMISSION');
$form['user_cannot_access_date_element'] = array(
'#type' => 'value',
'#value' => !user_access('THE_PERMISSION'),
);
$form['#validate'][] = '_MYMODULE_date_workaround_validate';
}
function _MYMODULE_date_workaround_validate($form, &$form_state) {
if ($form_state['values']['user_cannot_access_date_element']) {
unset($form_state['values']['THE_DATE_ELEMENT']);
}
}
?>
#4
I guess this workaround will only work for normal forms, not for multistep forms...
The date values must stay in the $form_state variable, they should only be accessible on one step of the multistep form.
#5
Same problem on a single step form for me. Completely breaking my website as I keep a date field as expiry for paid nodes.
User edits and saves his node, in my system, now he's no longer paid for it.
Gonna have some unhappy people on my site with this one :)
#6
I believe this is caused by a bi-product of this
#408770: #access of date_combo fields prevents validation
http://drupal.org/node/408770#comment-1818564
Also for those looking for information related to #access = FALSE and $form_state['input'] vs. $form_state['values'] take a look at the documentation here: http://api.drupal.org/api/drupal/includes--form.inc/function/form_builder/7
#7
A problem that only happens when you do something like create a multi-step form is not a critical bug that makes the module unusable.
When you set #access to false on *any* field you should also be setting #value for that field (move whatever is in #default_value to #value), because the form api won't be processing the value normally.
That may be all that is needed.
#8
I think this is the similar issue like here #1178716-27: Translating node deletes date field entry
Work on patch is in progress.
#9
See the issues in #1178716: Translating node deletes date field entry, which also was setting #access to false. When that issue is marked fixed it should mean that all the #access issues are fixed.