To reproduce:
Create a node with a single instance date_popup field on it. Only add a from_date for simplicity. Mine date Year-Month-Day granularity. Save your node.
Create a node and input a value into this node.
Create a simple hook_form_alter() which changes the node_edit for you node type and add $form['your_date_field']['#access'] = FALSE; For easier testing maybe only do this for a particular user and not others. Then open two browsers to test.
Clear cache. Edit the node. Submit.
Desired behavior:
Values are kept in the node.
Actual behavior:
Values are cleared.
I've tracked this down to a couple issues:
#1 date/date_elements.inc
function date_combo_element_process($element, &$form_state, $form) {
if (isset($element['#access']) && empty($element['#access'])) {
return $element;
}
This code is not setting #default_value for the element to get sent. Thus no value passed along to node_save and the value gets wiped out.
#2: date/date_popup/date_popup.module
In function date_popup_element_value_callback()
$form_state['input'] isn't populated with values from #access = FALSE fields.
I've modified the code like this:
- $input = drupal_array_get_nested_value($form_state['input'], $element['#parents'], $input_exists);
+ $input = drupal_array_get_nested_value($form_state['values'], $element['#parents'], $input_exists);
There are still more issues to be worked out, but I'm not sure if I'm going to be able to figure them out in a proper manner to form a patch.
Let me know if you need any additional assistance with this.
Similar issues:
#408770: #access of date_combo fields prevents validation
#1267434: Dates fields set to #access=FALSE are emptied on save
Documentation
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
Update
It doesn't need to be a date popup widget, all others including text and select, fail as well.
Comments
Comment #1
j0rd CreditAttribution: j0rd commentedUpdated title.
Comment #2
j0rd CreditAttribution: j0rd commentedSame issue under -dev.
Comment #2.0
j0rd CreditAttribution: j0rd commentedAdded some documentation.
Comment #3
j0rd CreditAttribution: j0rd commentedUpdating title.
Comment #4
omercioglu CreditAttribution: omercioglu commentedSub
Comment #5
das-peter CreditAttribution: das-peter commentedsub - since of not yet deployed "Follow" button :)
@j0rd thanks for tracking this down and connect the related issues!
Comment #6
doana CreditAttribution: doana commentedThis issue is affecting one of my sites as well. Thanks to everyone who's working on this!
Comment #7
j0rd CreditAttribution: j0rd commented@doana, not sure if anyone is working on this, so make your voice heard and hopefully we can get some eyes on this.
For me, I've had to remove the use of date for my module because of this problem. I've replaced it with an interger input field which is a unix datetime. I've also added some javascript to provide the calendar popup interface.
Then I'm using this snippet, so that views provides me with the unix datetime to use in my filters:
I may release this little node as a light weight/simple alternative to the date module, but really, if this is fixed in date, it wouldn't be an issue. Plus I really enjoy date_api.module for working with my dates...
If anyone has access to date module maintainers, please let them know about this issue.
Comment #8
das-peter CreditAttribution: das-peter commentedNot sure if this is a
D7 stable release blocker
?For me it sounds like an essential issue that could break a lot of stuff and thus like a
D7 stable release blocker
.Opinions on that?
Comment #9
j0rd CreditAttribution: j0rd commented@das-peter from me looking into the code, it looks like quite a few things needs to get re-factored to resolve this issue.
In my opinion currently, it appears that date module is doing certain things out of order, which is causing this problem. Perhaps Drupal itself has some issues in core as well.
Problem exists from hacking layers and layers of fixes for other issues, creating thing one.
At least from my research digging into this.
Needs someone with a good understanding of Drupal Form API & The Date module to get fixed. Anything I could do, would most likely break other things.
For me, it's a release blocker. I've had to stop using the module. I need the ability to restrict the end user from modifying the value in this date field, as it's tied to payments. If someone smart decides to manipulate the hidden value, then they can get all sorts of free goodies.
Comment #10
renat CreditAttribution: renat commentedFor me, this is a release blocker, too. It leads to the user's data loss and makes impossible usage of some other modules. But, of course, would be nice to hear a word from Date's maintainers.
Comment #11
das-peter CreditAttribution: das-peter commentedI've created a summary with a patch here: #1178716-21: Translating node deletes date field entry
My problem with the patch is that I'm absolutely short on time. And since I haven't one of the mentioned scenarios, in a project I've to work on, I can't sideline project time to make wide test runs. Thus it would be great if you could apply the patch and test it in your scenarios.
Comment #12
KarenS CreditAttribution: KarenS commentedThis is basically a duplicate of #1178716: Translating node deletes date field entry, which is where all the work to fix it is going on. I think most of the issues are fixed in the very latest -dev code, but I'm still working through it.
Comment #12.0
KarenS CreditAttribution: KarenS commentedAdded additional information.