enabling multistep removes cck field default value textfield from existing fields

On a content type's 'manage fields' page. You will need to enter the Field Group step number. Click on configure in the operations column for the Field group you want to edit then you will see a new drop down menu allowing you to select the step number. Hope this helps

I can't reproduce the bug. Have you try using the latest dev snapshot? It might be fixed there.

I am seeing this problem also

I had some default values set up for my content type, and when I create a node, they show up regardless of the step that they are in.

---BUT---

If I try to add/change the default value of an item in a step other than 1, I can't. Here are my steps to reproduce.

1. add/enable module, create content type with groups and assign fields to groups and groups to steps
2. from admin/content/node-type/[CONTENT_TYPE_NAME]/fields edit a field that is in step 1
3. expand default value section of form and notice 3 fields - value, input type, and PHP code
4. go back to admin/content/node-type/[CONTENT_TYPE_NAME]/fields and move the afore-mentioned field to step 2 (don't forget to save)
5. edit this field now that it is in step 2
6. expand default value section of form and notice only 1 field - PHP code

I was running 6.x.1.x-dev, and also downgraded to 6.x-1.4

I also tried this with cck/views from head and from the latest stable (views 2)

I can confirm this problem as well. However, I did manage to identify the fact i can get the 'default value' options back if the fieldgroup is assigned to either "all" steps or step 1. It also works if I move the field itself to a different fieldgroup as long as the fieldgroup is assigned to step 'all' or 1. If assigned to any step > 1, the default value options (except for php code) vanish. It seemed odd to me so I tested it over and over and I can reproduce the behavior every single time.

I spent a couple of hours on this, but couldn't figure it out. I don't see anything in the code that would have this effect :-(

ok, i've at least narrowed it down to the multistep_field_access function-- remove that function and the default value reappears. Add the function back in and it disappears. Now if i can just figure out what's wrong with it...

Ok, i think I found the problem. I'm not too familiar with the cck field api, but the multistep_field_access function is called not only on the node form but also field edit form and the following code from the multistep_field_access function is responsible for the disappearing default settings:

// Set #access to FALSE if the current field does not belong in the current step.
if (isset($field['widget']['multistep']) && $field['widget']['multistep'] != $step && !$groups[$group]) {
  return FALSE;
}
// Set #access to FALSE if the current field's group does not belong in the current step.
if ($groups[$group]['settings']['multistep']['step'] != $step && $groups[$group]) {
  return FALSE;
}

This function probably needs to only be called on node forms and not also on field edit. But i'm not sure what the proper way to do this is.

ok, since this function appears to have been written only for the actual node edit form, i changed it to the following for testing purposes:

function multistep_field_access($op, $field) {
if (arg(0) != 'admin') {
  switch ($op) {
    case 'edit':
      // Do nothing if multistep is not enabled for this node type.
      if (!isset($field['type_name']) || variable_get('multistep_expose_' . $field['type_name'], 'disabled') != 'enabled') {
        return;
      }
  
      $step = _multistep_get_current_step($field['type_name']);
      // Render all steps if requested by a user with "toggle multistep" permissions.
      if ($step == 0 && user_access('toggle multistep')) {
        return;
      }
      $group = _fieldgroup_field_get_group($field['type_name'], $field['field_name']);
      $groups = fieldgroup_groups($field['type_name']);
      // Return if the current field belongs in every step
      if (isset($field['widget']['multistep']) && $field['widget']['multistep'] == 0 && !$groups[$group]) {
        return;
      }
      // Return if the current field's group belongs in every step
      if ($groups[$group]['settings']['multistep']['step'] == 0 && $groups[$group]) {
        return;
      }

      // Set #access to FALSE if the current field does not belong in the current step.
      if (isset($field['widget']['multistep']) && $field['widget']['multistep'] != $step && !$groups[$group]) {
        return FALSE;
      }
      // Set #access to FALSE if the current field's group does not belong in the current step.
      if ($groups[$group]['settings']['multistep']['step'] != $step && $groups[$group]) {
        return FALSE;
      }
  }
 }
}

This simply prevents it from being used on the field edit forms. It would be great if some of you also having this problem could make this change and do some tests. I'll be testing tomorrow.

OK, here's a patch that 1) fixes several php errors and 2) fixes the missing 'default value' fieldset. Seems to be working so far, but it would be nice to get some other testers to make sure it doesn't break other functionality.

That was actually the problem, for the Default value, the field is actually rendered. Since there is no step context on the admin screen, the module thought it was on steps 1 or 0, so it was hiding the field. Thanks for the patch: it worked very well!

I committed the patch to the latest development snapshot.

awesome-- glad to helpl ;-).

great module btw!

Still doesn't work for me with the latest DEV. snapshot.

I am now available to put in, and see a default value in edit content type pages. But the default value doesn't show up when trying to create content.

Am I the only one with that issue?

I just tested a fresh checkout of the dev snapshot and had no problem with default values for simple text fields and radio buttons.

What about "text area"?

no problem with a text area either.

I am having a similar problem for a date text field. The default value I set is not showing up on node creation when the field is on a step later than the first. When the field on the first step it shows the default value correctly.

This is the result of the way the Date module handles widget creation. It checks whether the node exists or not to set the default value. The code is in the date_local_date() function, which is called from _date_widget() in date/date/date_elements.inc. I have not yet found a way around it. Other CCK fields (at least the core ones) don't check whether the node exists or not: they just set the default value, which means that when you view the node after creating it, you will see the default values for all steps (even though you haven't submitted them yet).

I'm not entirely sure which should be the proper way of doing it, since a Date field is much more complex than, say, a Text field.

Problem is that CCK fills in default form values on node creation form only, not node edit. This is due to a subtle distinction between what "default value" means when using multistep versus when using full node creation form. In full form case, default values are only logically valid until the first time the form is submitted. In multistep case, default values are logically valid until the person explicitly submits the corresponding step.

One way to make this work is to "refill" the default values if the current step hasn't been submitted before.

Attached is a very crappy patch (sorry) against my local mercurial repository (sorry again).

Problems with this patch:
* Only tested for text area (I did warn the patch is crappy)
* Should possibly handle a case where a text field appears in all steps. I'm not sure if this is a problem.

Hopefully this will help you home in on a better solution.

What you said makes more sense than the way it's currently working:

In multistep case, default values are logically valid until the person explicitly submits the corresponding step.

Which then means that to supply default values for steps that haven't been submitted yet is wrong. Essentially, we would want to suppress all default values on all but the current step; then, for the current step at which we are load the default values if it hasn't been submitted yet.

Your patch seems to do the latter (I haven't tested it yet, although the code seems fine). Now we need to find a way to suppress default values on steps other than the current one. I will test it this week and see what I can accomplish, but so far I think you're on the right track! Thanks!