cck的字段有多个值的时候 表单默认显示几个空值 几个值 两个值 node form CCK multiple values: two empty fields showing up it one 有大用

For one field and an "add more" button, i imagine you would set the original value of the CCK field to 1, and add your own "add more" button, then change the field to "multiple values", then redirect back to the page & hide your "add more" button?

Haven't tried it though

The number or fields initially displayed could be a setting on the fields settings form.
By stealing Views' dependent.js, we could even display it only if the 'multiple' setting is 2+

I personally have no intention to work on this in a near future, so patches welcome...

I'll try to write a patch for that... Our clients wanted to see only one empty field.

Where to look for?

You'll want to check :
- content_multiple_value_form() in includes/content.node_form.inc
The beginning of the function determines how many widgets to display.
- content_field_edit_form() / content_field_edit_form_submit() in includes/content.admin.inc
Handles the fields settings form. The setting will need to be added below the 'widget' section ('These settings apply only to the %field field as it appears in the %type content type')

I'd suggest leaving out the dependant.js stuff I mentioned in #2 for now.

Ok, after look into the code I understand the logic behind multiple values fields.
Let me explain it here:

A field have an options to indicate it can have 1, 2, 3,... unlimited values in the settings page.

It interpreters to the value of  $field['multiple'] , it can be 0, or 1, or 2,3,... etc. '0' means you set 'the field has 1 value' in the options, thus no multiple values. '1' means unlimited. Any number greater is considered the fixed value of 'the field has x values'.

Now let's look into the situation

  switch ($field['multiple']) {
     ....
    case 1: // unlimited
      ...
 

(in includes/content.node_form.inc)

The ideas here is always have a extra empty field to let the user input data. So it should show 1 widget when there's no data, 2 widgets(1 filled, 1 empty) if there's 1 data, 3 widgets (2 filled, 1 empty)..., so on.

It works when there are already some data. However here comes the problem when there's no data: the  count($items)  is always 1, whether it's no data or 1 data. If there's no data, it's something like

array(
 '0' => array('uid' => NULL)
)

, which is set by content_set_empty() .

So, when there's no data, the count is still 1, then plus another emtpy field, it's 2 empty fields.

I've fixed this by set the count correctly when there's no data or 1 data.

The patch is attached.

Sorry, but -1.
Even if that's not clearly apparent in the code comments, providing 2 empty widgets is the *intended* behavior.

+1 for making this an option, defaulting to 2.

So let me make it clear, the wanted behavior will be:

Set an option - 'minimum widgets for unlimited values', defaulting to 2

For unlimited values:
when the field has no data -> show $min widgets,
when the field has 1 data -> show 1 data + 1 empty field,
when the field has x data -> show x data + 1 empty field,

If that's correct, I'll roll another patch.

Agreed on this :-)

made variables per field, which are set in the content_edit_form and can be accessed like:

variable_get('content_minimum_widgets_'. $field_name, '2')

patch attached. (apply against rc10)

made variables per field, which are set in the content_edit_form and can be accessed like:

variable_get('content_minimum_widgets_'. $field_name, '2')

patch attached. (apply against rc10)

Great ! I'll try to test soon.

Storing this setting in a variable is not right, though. Variables are used for storing various pieces of data for which there is no dedicated table and storage schema.
For fields and field settings, we have those : it's the content_node_field and content_node_field_instance tables.

If the value is stored in $field['widget']['minimum_widgets'] by the time content_field_instance_update($field) is called,
content_field_instance_update() normally takes care of storing this in content_node_field_instance.widget_settings.
Then, later on, the value should be available $field['widget']['minimum_widgets'] when you need it.

Also, I should probably have warned you that we'll probably want to wait until the offcial 2.0 release is out before committing this. We're trying to release shortly now, and I'd prefer not to rush code in.

As we are putting this option in the 'widget' setting instead of 'field' setting, I can't find a way to save it in the content module level, because all the field widget settings seems to be implemented by individual cck field modules.

It's always something like:

  $setting_names = module_invoke($field['module'], 'field_settings', 'save', $field);

and the content module itself seems not having any widget settings at all, so it's kind of hard for me to store it in some content related tables.

When you have time to test, can you change the storage of the variable as well?

Frankly, I think displaying a single widget is better by default.. I dislike the two extra widgets, especially with the add another option. I'd be down to display only a single widget for empty fields, and no extra widgets once the field is populated as a default. It leaves the UI less cluttered. It seems like a good solution until the appropriate database modifications and ui can be put in place for controlling the number of additional widgets displayed.

@yang_yi_cn: could you move the storage for that setting to the content_field_instance table? I think that would be a big step towards satisfy both yched and myself. and thanks for your first patch. I for one am using it. :)

@dopry - i'm still confused about the original idea (above) to have this show 2 empty by design...that's a very cluttered UI and crowds the node add/edit forms out the wazoo when many cck's are used and many are set to unlimited (or high numbers)

@zilla: Thats just the way it has been.. called legacy and too late to change expected behavior. moving this to a configuration option is ideal so you can choose. Do you have time to update the patch for this setting moving the value to the node_field_instance table?

i don't! i'm totally inept with code so am more than reluctant to commit a patch for a module as significant as this!

hi, i think dopry is right in 15 above. the extra field is pointless if you have "add another" right below it. showing two empty fields looks weird to everybody i've showed this too. i'll probably solve this with jquery until it the behavior is parameterized into what, 2.2???

just as a follow up to the post i just made, i just put this into my javascript, with "elar-processed" being the class i assign to stuff that i've processed already:

Drupal.behaviors.elar = function(context) {
$('table.content-multiple-table').not('.elar-processed').addClass('elar-processed').find('tr:last').hide(); //remove() didn't work so well
}

this seems to work just fine. removing from the DOM with remove(), on the other hand, seems to cause problems in at least some cases.

anyway, offered up to those of you with a personal preference for Javascript workarounds over PHP patches.

Semi-related request : #344587: Enable 'add more' button for non-unlimited fields.(both requests are better dealt with separately, though).

This thread is on my list of things to review / tackle. Karen and I both have little time for the time being, plus our focus is shifting to Fields in D7 core, so this list doesn't move too fast right now...

#350343: When "Unlimited" selected, show only one field instance was marked duplicate.

I agree with opinions here, too space for nothing, please consider removing (or have the an option to) the second input instance. Add more is more than enough for me, just a point of view,. is the patch for the stable release? or we are expecting something more sophisticated? thanks

So I successfully used the patch on my site when it was hosted on my local computer. But now that I've moved it to a remote host the option is no longer there and my fields went back to the default of 2.

Any ideas?

Nevermind, it turns out that somehow the backup of cck got set as the default, and that copy did NOT have the path applied.

all is well with the world again.

At my surprise, with the field having type of filefield and imagefield gives the result as one field displays at a time of node/add
Would be great if other fields are also like that admin setting for this would be a more better option.

Will this patch work on 6.x-2.2?

No offense, but displaying 2 fields by default seems more like a bug than a feature. What is the logic behind that?

"What is the logic behind that?" Anyway if they have a logic they is not for 80% of user -> http://www.d7ux.org

A made some test with users and one right solution is this one:

- Show one empty field
- Show "add an other buton" to explain you can add more field but rename it in "add an other name of the field"
- When you add an image or files and the user press "upload" add an new field bellow (because you have an action from the user, so you can transform the interface).

After this bug is corrected a good new feature is the possibility to change how many empty field need to be show.

I think this is something that will be affected by #196421: Deleting unwanted multiple values / multiple values delta issues

- Show one empty field
- Show "add an other buton" to explain you can add more field but rename it in "add an other name of the field"
- When you add an image or files and the user press "upload" add an new field bellow (because you have an action from the user, so you can transform the interface).

bump. I was sent here from the imagefield issue thread. I'm not sure if I should request this in another thread maybe, but I'm simply looking for the same behavior exhibited for a specific value of imagefields as when having set unlimited values of imagefields in the content-type edit form. One imagefield input by default, then others added upon user upload until the (value) limit is reached.

It's not a bug if it's intentional. We're asking for a new feature that hasn't ever existed.

Simple patch for showing one empty field by default.

Hey Gyt,

Thanks for posting this patch. Patched up content.node_form but it doesn't appear to work on my end. I still get a list of X number input fields. Do I have to recreate my content-type or imagefield to make this work?

Hm, imagefield already has this feature. Try to create new node - one empty field will appear. When you edit node, you "still get a list of X number input fields" + one empty field.

Imagefield apparently doesn't have anything to do with this - I was sent here from there having requested this feature. I've attempt to create a new node and still get a list of X (6 set right now) number of empty inputs fields.

Would like to see this feature implemented, don't care which way is the default but having two empty fields is something our users are confused by! +1 subscribing.

subscribing

This patch does part of the job. In my test it successfully gets rid of extra fields on nodes that are *not yet saved*. Once the node is saved, the extra blank field returns.

Simply adding a minus one to count($items) seems to solve it in both cases -- not sure what's going on with all this minusing of values but it does work for me.

Forgot to set this back to needs review.

Ha, nevermind this technique totally breaks table dragging. I think the code in the current patch may be on the right path, with the remainder of the fix involving the tabledrag/ahah voodoo that I haven't quite wrapped my head around.

Using patch from #36 with CCK 6.x-2.4 and it seems to work fine. Thank you Gyt!

Once the node is saved, the extra blank field returns.

It isn't a big problem for me. If you want to solve it, try this patch or CCK 3.0 (dev version).

My patch only solve problem in the title: "two empty fields showing up - make it one".

This is what I did to solve the problem ->

for the function in content.node_form.inc called content_multiple_value_form(&$form, &$form_state, $field, $items)

I edited case 1 of the first switch statement,

  switch ($field['multiple']) {
...
    case 1:
      $filled_items = content_set_empty($field, $items);
      $current_item_count = isset($form_state['item_count'][$field_name])
                            ? $form_state['item_count'][$field_name]
                            : count($items);
      // We always want at least one empty icon for the user to fill in.
	  //no I don't!
      $max = ($current_item_count == 0)
              ? $current_item_count
              : $current_item_count - 1;

      break;
...

Seems to work fine for me... any issue with doing this?

Is this going into the module? Which patch is recommended?

To get this in, it should be optional as in #12, but it needs to follow indications in #13. That means, this needs:

1) Add a new option to widget settings form (patch in #12 is a good example).
2) Adjust CRUD code to handle this new option (sadly, this is not covered by #12, it uses Drupal variables instead, which is wrong here).
3) Apply the option to multiple value widgets in node edit form.
4) Test, test, test...

#36 works great for me with cck 2.5. One "unlimited" location field was showing up double, and now it shows up once. My "unlimited" e-mail and phone fields are still showing up double/triple for old users, but in new users starting with all fields blank, it displays only one field as expected.

Definitely a successful patch if you apply it before your members all sign up and initially fill out their fields. Thanks.

#36 works also for my fields in node creation and editing

As a quick test option, you could also try making the first field and its handlebar invisible by using CSS.

Is this change going to take a place in the next release?

The following form alter is what I'm using. I don't know how safe it is, but based on limited testing it seems to work for new node form, edit form, and also "Add another item" button seems to work as intented. How safe is it to do this?

/*
 * Remove the extra empty field on multiple valued CCK fields
 */
function dap_theme_form_alter(&$form, &$form_state, $form_id) {

  if( $form['#id'] == 'node-form' ) {

    $content_type = content_types($form['#node']->type);
    foreach( $content_type['fields'] as $field_name => $field ) {

      if( $field['multiple'] ) {

        $num_of_filled_values = count($form['#node']->$field_name);
        $index_of_extra_form_field = max($num_of_filled_values, 1);

        unset($form[ $field_name ][$index_of_extra_form_field]);
      }
    }
  }
}

Subscribe. I hope this will get fixed soon.

Its working fine. thanks ..

Subscribing, looking for better solution. Currently had to work around by injecting a fake button after the table with jquery, keeping one field visible and hide the rest, and toggle subsequent fields to show one after another with a big caveat that when two or more fields are filled already, they will be folded/hidden unless the button is clicked again :(

Thanks

+1 patch #36 by Gyt (which is same as patch #5 by yang_yi_cn but without comments).

Tested
CCK 2.6
Drupal 6.16
PHP 5.29

Tested compatible with
CCK Fieldgroup Tabs 1.2
Flexifield 1.x-dev (2010-Apr-11)
Modal Frame CCK Editor 1.0

Providing widget level configuration would be just one more (unnecessary) step for every unlimited value field I would have to do since I can't think of a scenario where 2 empty fields would ever be preferred. My 0.02...

subscribing

Patch #36 works for me, too. Tested with Drupal 6.16 and CCK 6.x-2.7.

Yes. Love it.. thank you. Agree that two empty is pointless and frustrating clutter.

+1 for this patch - this needs to be fixed

Another +1 - applied #36 CCK 6.x-2.7 and looks like it works well!

I also applied the patch #36 with success.

I make some user test on 10 peoples. It's pretty obvious than the majority (100% for me) prefer one field. The default should be one. And perhaps an other module can add multiple field as an option...

Patch #36 works on the latest Drupal 6.19 and CCK 6.x-2.8. Thanks for fixing this annoying bug!

+1 to #5 which I've tried and am using with a project and I assume +1 to #36 as well, if it does the same thing ...

Thanks for the patches! IMO having only one field at the start is nicer and more intuitive.

+1 to #5 and #36.

+1 for this as default

<?php
/*
* Remove the extra empty field on multiple valued CCK fields
*/
function dap_theme_form_alter(&$form, &$form_state, $form_id) {

  if( $form['#id'] == 'node-form' ) {

    $content_type = content_types($form['#node']->type);
    foreach( $content_type['fields'] as $field_name => $field ) {

      if( $field['multiple'] ) {

        $num_of_filled_values = count($form['#node']->$field_name);
        $index_of_extra_form_field = max($num_of_filled_values, 1);

        unset($form[ $field_name ][$index_of_extra_form_field]);
      }
    }
  }
}
?>

subscribe. +1 to #5 and #36

subscribe. +1 to #5 and #36. Works perfectly!

+1 For the option,
+1 for one field default.

+1 for #36.

I noticed that Gyt submitted his patch June 2009. This issue was marked "Reviewed & tested by the community" on 8/10/2010. CCK's latest stable version was released 8/11/2010. It is now 12/1/2010. When is this patch going to make it into a stable version?

Thanks!

I attached very slighty modified version of patch from #36. I only changed path to modified file. This change is needed, becouse according to http://drupal.org/patch/create all patches should be applied from root directory of module. This makes possible to apply this patch using drush_make.

Proper fixes for the way cck multiple values are handled are here (for 2.x): #530828: Provide "Add more values" button for fields (and multigroups) with fixed number of multiple values
and here for (3.x 'multigroup'): #841914: Provide options to set how many fields are initially displayed and how many are added on click of "add more"

#77 worked for me with CCK 6.x-2.8 on Drupal 6.20.

I regret to say I cannot understand the logic at all for thinking that two blank fields makes sense as a default for an unlimited-values field. This has always seemed to be a huge ?? for me, and I am glad to have CCK now patched with #77. I never hack core and never hack modules if I can avoid it, but fixing this was a total non-negotiable for the client site I'm working on at present so I will just have to maintain this modification until CCK implements it. Please!

I just wanted to note that #36 still applies successfully on CCK 6.x-2.9.

Patch in #77 worked quite nicely for me. Thanks!

The patches in #36 and #77 will never be committed for reasons clearly stated in #8, #13 and #51.

This patch is based on #12 and adds an extra field to the content_node_field_instance table. I'm not sure of the correct way to handle this, I added it manually to the database and updated the schema in content.install. Upgrading the module and a fresh install have not been tested.

I'm also not sure if the git patch creation process is correct, the instructions on drupal.org seem to mix up module maintainers with patch submitters.

Please ignore the above patch, this one should actually create the field.

Updated schema version. Learn something new every minute.

Although if it's not in D7 then it may not go anywhere.http://drupal.org/node/530828#comment-3998880

Patch #84 applied correctly and generally works fine. However, I get the wrong number of text fields when creating a new node or editing a node that has no values for that field. I get one fewer on the form than selected in the field configuration. Still, it is a great patch -- very useful for data entry.

Patch #84 worked great for me, thanks! One potential gotcha, though. If you're using source control, Mercurial locked the file and made it unreadable at first, giving me this error:

Fatal error: require_once() [function.require]: Failed opening required './modules/cck/includes/content.node_form.inc' (include_path='.;\xampp\php\PEAR') in \xampp\htdocs\includes\module.inc on line 274

Restoring correct file permissions and recommitting the files fixed it.Comment

@imclean, is it possible to do this in contrib for D7?

While CCK is built in in D7 - It'd be nice to see these working there as well.

@JGonzalez did you find a solution for D7 at all? Is there a seperate thread I can subscribe to on the topic for D7 and help with a solution?
Dan

@retrodans: The accepted solution here works perfectly for D7!

Is there a fix yet for Drupal 6? Do any of these patches work good for production?