I'm using Date 6.x-2.2 and the latest dev version of Multistep. If I add a "Date" field to a field group with a step value other than "All", I get the warning:

warning: array_shift() [function.array-shift]: The argument should be an array in includes/form.inc on line 1326.

It looks like the date field isn't getting completely hidden, causing Drupal to try and fail to render it.

Steps to reproduce

  1. Create a content type with more than one step.
  2. Create a field group, and set it to any step other than "All".
  3. Create a "Date" field with any widget type (calendar pop-up or custom input field), and use the default values for all of the field settings.
  4. Add the Date field to the field group.
  5. Open the node add/edit form for that content type.

Expected Behavior

The field group, with the date field inside, is displayed only on the appropriate step, and no errors are displayed.

Actual Behavior

The field group, with the date field inside, is displayed only on the appropriate step, but the PHP warning message about array_unshift() is displayed on every step.

Comments

guypaddock’s picture

guypaddock commented
Title: array_shift() array when using Date fields » array_shift() warning when using Date fields
ryanilg’s picture

ryanilg commented

I am having the same issue.

But with another issue, which probably has something to do with the array issue.
If you go back and edit the post starting on the first step, it clears the date that was previously inserted.
If you jump straight to the page with the date options on it, it will retain the proper dates.

guypaddock’s picture

guypaddock commented

This may be related to this issue with the Date module:
http://drupal.org/node/408770

guypaddock’s picture

guypaddock commented

Odd. If I move the #access check in the date_elements.inc from date_combo_process() to date_combo_validate(), the warning goes away, but I'm still left with the problem ryanilg describes.

I tried tracking down the cause by creating a content type with 2 steps and all field groups on step 1, with one field group containing a date module. I saw the same "date loss" behavior as if the date field was on a different step. It seems to be related to setting $form_state['rebuild'] = TRUE in multistep_form_alter, as when I added a return statement before that line, the date field no longer lost its value. I don't think it's standard practice to re-build the form in hook_form_alter, as I believe that hook runs AFTER the form has been built the first time, and modules like date could be keeping state. Usually, the form is rebuilt in the next/previous submit buttons.

ryanilg’s picture

ryanilg commented

Yeah there are still issues when moving the #access check.

It gets rid of the error on the initial load of the form, but as soon as you post, you start getting a few other errors saying you need to put something in the date form. I need to get to the bottom of this in the next couple days as well. I have and will be doing some more tinkering to see if I can find the issue, but hopefully someone else might know whats going on.

At this point I can live with the form dropping the values, but the error messages are something that cannot happen.

vkareh’s picture

vkareh commented

Thanks for digging through this, guys. At this point I certainly need help, as I've been trying to fix this date issue for many months and haven't had any success. The issue in #408770: #access of date_combo fields prevents validation did not fix it, but it did point me in a new direction. Now I'm trying to see whether #403404: Default value set to 1000 years back when #access is FALSE has anything to do with it, since in many cases the year gets dropped and I get a range from 9 to 2009 (I have the setting as -3:+3).

Setting $form_state['rebuild'] = TRUE in a different function (or not setting it at all) makes the form render the same step over and over, no matter which step you're at. This week I'll start testing with $form_state['storage'] to see if I can store the step there, while redirecting to the same step, and letting the form itself (not the URL) dictate which step should be rendered. In any case, the values should be stored to the database at each step, not only to $form_state['storage']. We'll see what happens.

Thanks for all your help! Keep it coming!

vkareh’s picture

vkareh commented

Okay, I traced it back to the #access in date_combo_process() (#408770: #access of date_combo fields prevents validation). If I remove the patch, the warning goes away, since the $element is not being dropped.

To solve this, I tried keeping the patch, but instead of return; I did return $element;. That way the function is not being executed, but the $element is still being returned to properly continue with the _form_builder_handle_input_element() function.

vkareh’s picture

vkareh commented
Status: Active » Needs review

See here for a patch: http://drupal.org/node/408770#comment-1818564 (use with caution).

Also, I removed $form_state['rebuild'] in the new development snapshot. It appears to be unnecessary, but I'll test it further to verify whether it's consistent.

vkareh’s picture

vkareh commented
Assigned: Unassigned » vkareh
Status: Needs review » Fixed

I changed the way the fields are set to be done at the field level (instead of at the widget level). This should no longer be an issue in the new development snapshot.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.