Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)

Anyone got a view on whether this patch is a sensible approach ? Anyone successfully used in the live environment ?

Cheers

El

i think this would be a great feature, works well!

It was exactly what i needed atm. thanks for the patch works perfectly.

In Drupal7, this can be changed in modules/field_ui/field_ui.admin.inc
The line that defines the range of values says now '#options' => array(FIELD_CARDINALITY_UNLIMITED => t('Unlimited')) + drupal_map_assoc(range(1, 10)),

@El Bandito,
IMO the proposed solution is OK for a simple modification.
an alternative is to change the widget from 'select list' to an 'textbox'. An empty field then means 'unlimited'.
(This is also proposed in #680616: Setting a custom "number of values" for a multi-value ImageField?)
This is a bit more complicated, and would be the better way for definitive approach.

Also I'd like to set the 'number of values' different per Content Type, rather then creating different fields that only differ in this respect. I'm not sure if this is possible.

This patch makes no sense for version 7.x-2.x. CCK does not control any of this in D7. And if we change it in D6, the change won't work in D7 and you will have data and settings that may not migrate correctly.

Sorry for reviving the issue:
Anyone knows if there is something for D7 in contrib?

I found the only way in D7 is: custom_formatter.

Comment #6 works for me... I don't like the idea of having to remember to change that every time there is a core update though...

I know the core team worked very hard on D7 and I'm not trying to bash their work, but it's stuff like this that was so simple in D6 CCK, that has now become a pain in the ass with D7 fields... I realize there has to be a give and take somewhere, but I feel like a lot of the work that was put into CCK that made it such a wonderful project, was stripped out when it was incorporated into D7. Now we are left with "work-arounds" to things that were previously possible.

Anyone else kinda frustrated with the approach that was taken with D7 fields in comparison to D6 CCK? I'm sorry but a website that is created today, is not going to be the same website in two years. Things change, people learn and then go back to tweak their initial design. It's almost like the idea in the sprints was to lock things down to make it easier and safer for the new guy, except that the new guy doesn't know enough about what he's doing, to be able to properly sit back and "design" the site for what it will become in two years.

Sorry for the rant but I've run into more than one situation with fields where I can't do what I used to be able to do, just like this topic is describing. I'm not usually one to complain but I'm hoping that the squeaky wheel will eventually get some oil in this area of Drupal.

How about something like:

UPDATE field_config SET cardinality = 15 WHERE field_name = 'field_my_field_name'

The way I understands Fields in D7 is that they can be configured in code and the UI is in all respects supplemental to defining things in code, regardless of whether or not it's what is used 99% of the time.

So with all that in mind, why not just change the field configuration to use 15 in the field's configuration?

The approach in #12 works but the change isn't reflected in the settings. Couldn't they be easily overridden?

Why not just do a hook_form_alter() and changing the field to a textfield? Would that break something later on?

A form alter should be fine; the cardinality is nothing more than an integer. The only thing that's not playing nice here is that the form element is a select and can't realistically support a limitless number of values.

A select with 1-10 + unlimited is good for your average user, however I would prefer a text field where I enter a number.

Couldn't there be a simple "Field Settings" page that would allow overall customizations such as this? I don't really know what other customizations could be done, but I'm sure somebody could think of one : )

Here's a patch, can anybody test it?

This issue belongs to drupal core field system I think.

so I created this issue : http://drupal.org/node/1588624

Yes, #1588624: Can field cardinality (number of values) range be other than 1-10, unlimited ? replaces this issue. The issue title maybe not clear enough, but the patch specifies a "higher top limit" by letting the user type what he want as "number of values" as talked in #14.

So may I change the status to "fixed" because the problem isn't here but in the drupal core field system.

Features need to go into d8 first.

I have tested #16. It works nicely, however it lacks validation.

- You can enter an invalid number like '3sdf'.
- When saving, no error appears, and the value is not changed.

Compare this with a Number field:
- You can enter an invalid number like '3sdf'.
- When saving, the error "Only numbers are allowed." appears, and the value is not changed.

I considered making the cardinality to a Number field, but that introduces a dependency on the Number module.

An addition on teseting #16:
The number 0 is allowed, which was not in the old situation, generating an indetermined situation.

Hi,

I've added a validation code for the 0 value. Thanks for testing.

The last patch uploaded is for Drupal 7

As @marcingy mentioned, this would need to be patched in Drupal 8 first, per the backport policy.

See also #1331110: Change "Number of values" on field_ui_field_edit_form() to textfield?.

Hello,

with #6 it's ok for me. But is it possible to create a new function in template.php not to change the code in Drupal core? If we update Drupal, we lost the patch.

Thanks.

@jramby, the correction in #24 is in custom module 'field_cardinality'. The original patch #16 was in core module 'field_ui'.

What about for D6?

Here's a patch that uses the #states API to show/hide an extra number field if you select 'Other' in the select field.

Tagging also

Added validation function. Played around a bit with container inline, but I suck at it :)

That looks great !

+
+
   $form['field']['cardinality'] = array(

One newline too many :-)

+    '#default_value' => ($field['cardinality'] < 10) ? $field['cardinality'] : 'other',

Should be <= 10, no ?

I'd also suggest reducing the number of values in the select - 1 to 4 or 5 should be enough, then you use "More".
(putting that value in a variable would probably help for adjustments and make the code clearer)

We should try to bring a FAPI / UI guru to help with the container inline stuff, I suck at it too :-(

I actually got it working! :)

Didn't attach an interdiff as that would be almost as big as the patch.

This looks great! Is a great feature, that I'd always thought we missed.

Fixed tests + added some additional tests for the new element.

Woops, remove tag.

Better patch so in case something else than a numeric value is submitted to the 'other' field, the number validation will show a nicer error message. I think this one can be set RTBC.

Aw sweet, that's pure loveliness !
Bojhan approves the UI, code is fine, let's get this in :-)

I have one minor nitpick, but that's not enough to hold a commit.
There's no technical reason to restrict #min = 6 on the textfield. I could pick "more" and finally decide to enter 3, it would still be valid and nothing would break. We have no reason to "force" the user to be consistent where we could easily be forgiving.
(although #min needs to be at least 1 of course)

Makes sense indeed, old-school interdiff!

This is awesome! Here's some very minor docs cleanup and re-wrapping of comments at 80 chars.

+++ b/core/modules/field_ui/field_ui.admin.incundefined
@@ -921,12 +921,31 @@ function field_ui_field_edit_form($form, &$form_state, $instance) {
+
+  $cardinality = $field['cardinality'];
+  $form['field']['container'] = array(
+    '#field_prefix' => '<div class="container-inline">',
+    '#field_suffix' => '</div>',
     '#description' => $description,
+    '#type' => 'item',
+    '#title' => t('Number of values'),

What's wrong with #type => 'container'?

Also is there a generic 'select or other' issue somewhere? It'd be good to see if we could implement this as a fapi type rather than the two fields.

What's wrong with #type => 'container'?

Using #type container made the form spacing go completely borked iirc. I'll recheck again and post screenshots with the differences between the two.

There's a generic select or other, but no patch at all - http://drupal.org/node/1207060 . There doesn't seem to be much excitement around it either and http://drupal.org/project/select_or_other is also a really nice and fully coded alternative that has support for field api system as well. So I'd rather just go ahead, but that's just me of course :)

How the hell did that happen.

Oh man.

What about replacing the select element by a checkbox for "unlimited"? The select and textfield elements have a functional overlap which reminds me of the date selector we have/had in core: a select element with loads of possible options and one option for custom formats that made a textfield pop up. People tended to overlook the "custom" option.

The textfield is hidden with states when necessary, so it works fine as intented.

+++ b/core/modules/field_ui/field_ui.admin.inc
@@ -921,12 +921,31 @@ function field_ui_field_edit_form($form, &$form_state, $instance) {
+    '#options' => array(FIELD_CARDINALITY_UNLIMITED => t('Unlimited')) + drupal_map_assoc(range(1, 5)) + array('other' => t('More')),

+++ b/core/modules/field_ui/field_ui.admin.inc
@@ -921,12 +921,31 @@ function field_ui_field_edit_form($form, &$form_state, $instance) {
+    '#title' => t('Custom value'),

Perhaps use the same wording for the select option as for the number field title?

+++ b/core/modules/field_ui/field_ui.admin.inc
@@ -1037,6 +1056,13 @@ function field_ui_field_edit_form_validate($form, &$form_state) {
+    form_error($form['field']['container']['cardinality_other'], t('Please enter a number.'));

We don't use "please" in UI texts (http://drupal.org/node/604342)

The textfield is hidden with states when necessary, so it works fine as intented.

I'm not saying it doesn't work as intended. I'm only saying we have/had similar behavior with date formats which didn't work as well as expected, and that there is an overlap between what the select and textfield elements offer. My suggestion was to use a checkbox instead of a select list (so the #states behavior can be kept).

#51 Makes sense to me. In terms of usability a checkbox seems more appropriate.

Let's keep it originally, bojhan already approved, no need to bikeshed this again.

@dodorama: those are radio-buttons there in your mockup. Also, this is primarily about limiting the amount of values, so any UI that puts the 'unlimited' option first is a no-go imo.

The feature itself is the big win here, not the UI polish. Lets do that in a follow-up if you think it's needed.

Needs work for catch's remarks in #45.

@yoroy You're 2 times right. those are Radios, and we want this in and then eventually follow-up.

Changed the form error message to the title of 'Number of values' element. I left 'Custom value' there because then it won't upset screen readers as such.

As why I use the item type instead of container is for a technical reason: container can't handle the #title and #description property. see screenshots:

container

item

Looks good. Setting back to RTBC.

OK please add a comment as to why this can't use the container type, I'm sure it won't just be me who sees that and wonders.

I added a comment to #1207060: Interface pattern for custom option as alternative to predefined choices but fine with putting this in then potentially converting it to a generic element if we end up with one.

+++ b/core/modules/field_ui/field_ui.admin.incundefined
@@ -924,17 +924,20 @@ function field_ui_field_edit_form($form, &$form_state, $instance) {
+    // We can't use the container element because it doesn't support the
+    // title and description property.

Nitpick: Maybe "title or description properties" would be better?

The test needs to be updated now, it's still looking for "Please enter a number."

Crap, forgot to change the assert text too.

@Cottser - crosspost hehe. Could be that 'properties' is better, English is not my mother tongue, so I probably miss some details now and then, feel free to reroll :)

@swentel - Here's the proposed change to that comment :)

And back.

#64: 680546-62.patch queued for re-testing.

And back again.

Looks like catch has been involved in this one.

OK that looks good. Committed/pushed to 8.x.

+++ b/core/modules/field/modules/text/lib/Drupal/text/Tests/TextTranslationTest.php
@@ -90,7 +90,7 @@ function testTextField() {
-    $edit = array('field[cardinality]' => -1);
+    $edit = array('field[container][cardinality]' => -1);

+++ b/core/modules/field_ui/field_ui.admin.inc
@@ -921,13 +921,35 @@ function field_ui_field_edit_form($form, &$form_state, $instance) {
-  $form['field']['cardinality'] = array(
...
+  $form['field']['container'] = array(

Mmmm, this change led to a quite confusing form value structure. The 'container' in there does not really make sense.

Attached patch fixes that.

True, the container should be transparent to the structure of the resulting form values.

#71: drupal8.field-cardinality-other.71.patch queued for re-testing.

#71: drupal8.field-cardinality-other.71.patch queued for re-testing.

Ok, this re-test will fail again, will post new working patch after the bot comes back.

#78: drupal8.field-cardinality-other.78.patch queued for re-testing.

Yup, better now :-)

#78: drupal8.field-cardinality-other.78.patch queued for re-testing.

Yes please lets get this in, and also backport it to D7.

Is the custom option going to be called "More" as in the screenshot in #56? I looked at the latest patch, but couldn't find the label text for the custom value.

If it is "More", then that is a not so good choice from an UX perspective. Simply using "Custom" in the drop down would be best.

But maybe I have misunderstood the screenshot?

I'll work on a reroll.

@tsvenson - There was a commit made to 8.x already (see #70), now we're working on some tweaks on top of that commit. I believe the text is currently "More".

@Cottser - Ahh, did look for if a commit had been made, obviously I didn't catch that :)

Would be great if you could post screenshots of the UI, including with the drop down in full view. That would give me enough to really understand the UX going on here. Particularly it will give me a better idea of how that "More" is used.

@tsvenson - As far as I know #78 doesn't change any UI, so here are some screenshots from D8 HEAD.

@Cottser - Thanks for so quickly posting those screenshots.

"More" is definitely the wrong choice here. More for me translates into that something is missing from the dropdown. Also, when it is selected it says "More 6" and what does that actually mean, more 6:s, more than 6???

In my opinion "Custom" is the common term used for this and it also makes a lot more sense since above you have static option, unlimited included, and then Custom wont cause any confusion.

Great if you can include that in the follow up patch your working on.

Just to confirm. Is the input field always shown (since its visible with a 6 in the screenshot)? It should only be visible when the Custom option is selected.

It should only be visible when the Custom option is selected.

That's the case right now.

I can live with 'Custom', doesn't really matter to me.

@swentel - Thanks for clarifying that, it wasn't obvious for me just looking at the screenshot.

@tsvenson - See also #1207060: Interface pattern for custom option as alternative to predefined choices where a few ideas are bouncing around. I'm fine with changing to 'Custom' for this patch though, I'll incorporate that into the reroll.

@Cottser - Thanks for pointing me to that issue. Particularly since it has the ambition to create a universal standard.

Also thanks for the quick replies and turnaround of this issue.

Here's the reroll, the only change from #78 is changing the UI text from 'More' to 'Custom'.

The "Custom" change didn't get included in that patch, so here is the updated patch with an interdiff thrown in for good measure.

Ahem.

Yeah, sorry, I was the one who asked for "More" rather than "Other / Custom". I'm fine with "Custom" if UX people like it better.

A couple minor points on #96 :

+++ b/core/modules/field_ui/field_ui.admin.incundefined
@@ -533,21 +533,23 @@ function field_ui_field_settings_form($form, &$form_state, $instance) {
+  $form['field']['cardinality']['cardinality'] = array(

['cardinality']['cardinality'] is not too great. 'cardinality_container' ? 'cardinality_wrapper' ?

+++ b/core/modules/field_ui/field_ui.admin.incundefined
@@ -600,10 +602,15 @@ function field_ui_field_settings_form($form, &$form_state, $instance) {
+  $cardinality = &$form_state['values']['field']['cardinality'];
+  $cardinality_other = &$form_state['values']['field']['cardinality_other'];
+  if ($cardinality == 'other') {
+    if (empty($cardinality_other)) {
+      form_error($form['field']['cardinality']['cardinality_other'], t('Number of values is required.'));
+    }
+    else {
+      $cardinality = $cardinality_other;

Can we avoid the "by ref" magic ? I find it more confusing than useful here, and it's actually not needed at all for $cardinality_other.

No need to be sorry @yched. You do an absolutely awesome job with development and have my outmost respect to that. I'm just glad to help out with areas where my skills and experience can do good, hopefully allowing you to be able to focus on what you like best.

#96: 680546-96.patch queued for re-testing.

So, first of all, the past 30 comments should have been in a followup issue. We really shouldn't reopen issues for non-rollbacks.

Secondly, I think we're taking the wrong approach here. Having 1-5, OR more, OR unlimited in the same box is confusing, redundant, and unnecessary. Just use the number widget by default, and let it select anything from 1 to whatever the user wants. Toggle unlimited on or off somehow.

The number widget makes selecting 1-5 completely redundant. We can reduce the complexity, the number of clicks, and the general WTF by losing the select box entirely and just doing something like this:

Maximum number of values

  |-------------------------------|
[ | - Restrict number of values   |v]    selecing this reveals a number field thingie. it's the default selected value.
  | - Unlimited values            |     selecting this hides the number field thingie
  |-------------------------------|

[  5_    (^v) ] Number of values       (number field thingy)

Edit: Also, folks in IRC keep referencing #1207060: Interface pattern for custom option as alternative to predefined choices like it's a magic bullet, but I don't think that this should even NEED that pattern. It's a conditional field, not a "select or other."

Makes sense, I'll code this later

I'm told my ASCII art is unclear. There are two fields: A single-value select dropdown, and a number doodad that is conditional on the value of the first. So you'd see one of two things:

Maximum number of values
[ Restrict number of values |v] (select box)
[ 5_ (^v) ] values (number field thing)

Or:
Maximum number of values
[ Unlimited values |v] (select box)

Edited to be not-wrong.

xpost

Thanks swentel!

Also adjusting the title since the current one is misleading. :) Next time, let's leave the issue fixed and file a new one, so that there is a 1:1 title to commit relationship unless it's a big enough deal to roll back the change.

something like that http://jsfiddle.net/LXtZU/

xpost

Ok, this cleans up the container form structure and also addresses the select box problem, to be fair, this makes much more sense indeed.

- edit - This also simplified the tests a lot.

Tried the patch, I think it works pretty well.

- would be good to size the number field a bit smaller
- screenshot has some wording suggestions: lets not talk about users at all, use limited/unlimited and not repeat some of the keywords etc.

(wrong screenshot)

Fixes the test and implements the suggestions from #110.
Setting the size seems to be impossible though for the number element.
The validate function could also be removed, yay for cleanup!

Thank you people for taking care of this issue this way! ...and @yoroy with the limited/unlimited simplification idea: just brilliant man!! ;)

This looks great. Also love @yoroy's simplification.

There's only one trap here: The description makes it sound as if the "Add another item" button would only appear when "Unlimited" is selected. But that's not the case. Field widgets always progressively advance into more rows, unless the limit is smaller than 3 (I believe) — i.e., you always get an "Add another" button, unless the widget shows the maximum allowed items that can be entered already.

I wonder whether we need any description at all though?

Isn't "Unlimited" and "Limited" (+ value) crystal clear already?

@swentel: Regarding #size, just add 'size' to form_pre_render_number(), please. The HTML5 DOM Interface for input type=number still declares it as attribute unsigned long size. I've done exactly that change for some other patch in the queue already, but can't remember which one. Happy to do it here.

@sun - tried adding the size, but doesn't seem to have a lot of effect - see attached patch - unless I'm doing something extremely stupid.

Regarding the text of 'unlimited' - the behavior is actually kind of weird after some testing:

- text - limited set to x = x textfields on the form
- image - limited - 1 image field, new one comes on automatically after upload
- text unlimited : 'add another item' button
- image unlimited : no 'add another item' button, but comes automatically after upload

No time anymore to dig in this today though.

The changes for #size look fine to me. Browsers usually size the field a bit larger than the specified size. Did you try smaller values, like 3 or 2 or 1?

Let's try a smaller #size of 2. If that still doesn't work, no biggie, let's move forward.

The situation with the Add another button appearance with regard to unlimited/limited sounds like it would be best to remove the description entirely for now, in combination with a follow-up issue to investigate WTF is actually happening there? ;)

I've tried everything with that size, from 1 to 100 - no luck :)
Removed the text, I can live with a follow up or even a 'This is ok without, let's leave it like that'.

File widgets re-implement their own handling of "multiple widgets + add more".
Can't remember the exact reasons, maybe @quicksketch does - had to do with the "remove" button, that is specific to file / image widgets.

+++ b/core/modules/field_ui/field_ui.admin.inc
@@ -521,38 +521,39 @@ function field_ui_field_settings_form($form, &$form_state, $instance) {
-    // We can't use the container element because it doesn't support the title
-    // or description properties.
-    '#type' => 'item',
...
+     // We can't use the container element because it doesn't support the title
+     // or description properties.
+     '#type' => 'item',

Unintended + bogus whitespace change.

+++ b/core/modules/field_ui/field_ui.admin.inc
@@ -521,38 +521,39 @@ function field_ui_field_settings_form($form, &$form_state, $instance) {
     '#field_prefix' => '<div class="container-inline">',
     '#field_suffix' => '</div>',
...
+  $form['field']['cardinality_container']['cardinality'] = array(
...
+    '#prefix' => '<div class="container-inline">',
...
+  $form['field']['cardinality_container']['cardinality_number'] = array(
...
+    '#suffix' => '</div>',

The second additional/duplicate DIV.container-inline looks unnecessary to me?

The first one on 'cardinality_container' should be sufficient?

+++ b/core/modules/field_ui/field_ui.admin.inc
@@ -521,38 +521,39 @@ function field_ui_field_settings_form($form, &$form_state, $instance) {
+    '#title' => t('Allowed number of values'),

Can we move this #title to the select element?

Otherwise, we have an accessibility problem, since the select element does not have a label.

Doing so should also allow us to turn the wrapping #type 'item' into a regular #type 'container'.

+++ b/core/modules/field_ui/field_ui.admin.inc
@@ -521,38 +521,39 @@ function field_ui_field_settings_form($form, &$form_state, $instance) {
+    '#default_value' => $cardinality != FIELD_CARDINALITY_UNLIMITED ? $cardinality : 1,

Shouldn't this default to NULL?

Hm. Perhaps 1 is the most common case.

That said — do we actually validate somewhere that one can't assign a lower number than the highest delta in existing field data?

+++ b/core/modules/field_ui/field_ui.admin.inc
@@ -521,38 +521,39 @@ function field_ui_field_settings_form($form, &$form_state, $instance) {
-    '#title' => t('Custom value'),
+    '#title' => t('Number'),
     '#title_display' => 'invisible',

"Limit" might be a better (hidden) label?

+++ b/core/modules/field_ui/field_ui.admin.inc
@@ -577,20 +578,6 @@ function field_ui_field_settings_form($form, &$form_state, $instance) {
-function field_ui_field_settings_form_validate($form, &$form_state) {
-  // Validate field cardinality.
-  $cardinality = $form_state['values']['field']['container']['cardinality'];
-  $cardinality_other = $form_state['values']['field']['container']['cardinality_other'];
-  if ($cardinality == 'other' && empty($cardinality_other)) {
-    form_error($form['field']['container']['cardinality_other'], t('Number of values is required.'));
-  }

Why is the validation for a limited number removed?

We still need that validation, since this is a compound/conditional validation scenario — i.e., the number field is #required, but only if the cardinality is set to limited.

+++ b/core/modules/field_ui/field_ui.admin.inc
@@ -598,14 +585,12 @@ function field_ui_field_settings_form_submit($form, &$form_state) {
+  $cardinality = $field_values['cardinality'];
+  $cardinality_number = $field_values['cardinality_number'];
+  if ($cardinality == 'number') {
+    $cardinality = $cardinality_number;
   }

> php -r "var_dump('-1' == 'number');"
bool(false)

Lucky you. ;)

Nevertheless, a type-strict comparison might be safer?

Changes

• Strict comparison
• Fixed whitespace
• Bring back validation +test - was needed indeed.
• Use $has_data with #disabled property to prevent changing limit in case there's data - that was a regression long before this patch
• Use 'limit' instead of 'Number' for hidden title
• Removed obsolete prefixes - couldn't use the container #type though as the title started floating as well - unless I'm doing something wrong

Hmm actually this didn't seem to be regression, re-uploading one second.

+++ b/core/modules/field_ui/lib/Drupal/field_ui/Tests/ManageFieldsTest.phpundefined
@@ -240,7 +238,7 @@ function assertFieldSettings($bundle, $field_name, $string = 'dummy test string'
-  function testDefaultValue() {
+  function _testDefaultValue() {

@@ -297,7 +295,7 @@ function testDefaultValue() {
-  function testDeleteField() {
+  function _testDeleteField() {

@@ -343,7 +341,7 @@ function testDeleteField() {
-  function testHiddenFields() {
+  function _testHiddenFields() {

@@ -378,7 +376,7 @@ function testHiddenFields() {
-  function testRenameBundle() {
+  function _testRenameBundle() {

@@ -391,7 +389,7 @@ function testRenameBundle() {
-  function testDuplicateFieldName() {
+  function _testDuplicateFieldName() {

@@ -410,7 +408,7 @@ function testDuplicateFieldName() {
-  function testWidgetChange() {
+  function _testWidgetChange() {

@@ -453,7 +451,7 @@ function testWidgetChange() {
-  function testDeleteTaxonomyField() {
+  function _testDeleteTaxonomyField() {

Why are we silently disabling these tests?

tagging

Removed the uncommented tests.

Re-roll against head, can we RTBC this please ?

Well, because you say please :)

Tested it and it works fine here.

Committed 071dccf and pushed to 8.x. Thanks!

This is just reorganizing stuff in an admin form. Not sure this deserves a change notice ?

I agree with yched here. This is just a simple UI change, no API change or so.

how about D 7 ?

After so much back and forth - this is the visual result as committed in #130:

No change notice needed, therefore removing tag.

Now, most aspects of this task are a bit feature-ish, but not being able to choose a number > 10 definitely is a WTF, so IMHO this should really be backported to D7. I'm going to take care of this.

how about D 7 ?

Needs no change notification and is already in the D7 branch.

Before going on holidays for a few days, I want to share with you a preliminary D7 backport, which does a number of things a bit differently, and IMHO cleaner than the current D8 solution. I unfortunately don't find the time to present the changes for now.

Certainly this would need to be applied to D8 first, and I have another D8 followup patch in the works, but I'm now just posting this, so the testbot can run over it and maybe someone wants to play with it.

Okay, let's first go back to D8 for the followup.

To be fair, we've had enough follow ups in this one already, I suggest we really start from a fresh one.

Agreed.

Just the backport, for refacotring ,see #141 and #142

#138 works for me on Drupal 7.26 also with using the plupload_field_sources.
Thank you.

Will be nice to have kind of allert when trying to add more then 20. As for now it's only upload the first 20 with no message.

I just stumbled on this. FYI, I made a sandbox module a while ago that changes all cardinality inputs to text inputs, allowing arbitrary values:

https://www.drupal.org/sandbox/sreynen/1324292

I used #145. Great work.

I've create a sandbox project here: https://www.drupal.org/sandbox/ydahi/2421885

The module allows users with the permission "Administer content types" to set the lower and upper limits for the range of values. The unlimited cardinality is still made available.

The module use hook_form_alter to globally change the cardinality instead of hacking the core cck module.

We keep the "needs backport" tag on permanently; otherwise we have no way of knowing which issues got committed to 8.x first. Yes it's not entirely consistent. :(

Just noticed this is still open for backport to D7. Between then and now we changed our practices to create separate issues for D7 backports. So contributors who are interested in this feature for D7 can create that separate issue and maybe a fresh start will help. :)

Reopened #1588624 (and added it to this as a child issue, is that okay?) for the D7 backport.

can we use token in this field and set variable amount of fields?