When setting up a Node Reference field (to take one example), the admin can select the maximum number of nodes which may be referenced using that field. The current settings for the maximum are 'Unlimited' and 1 to 10. I would like to suggest adding the numbers 20 to 100 by 10s as this would be a very useful enhancement. There are cases where 10 nodes are not enough but I do not want to set it to 'unlimited'. Having the extra numbers gives more control and better flexibility.

The attached screen grab shows the drop-down list before and after, and the attached patch makes the following one-line change to $form['field']['multiple'] in content.admin.inc

<?php
 
'#options' => array(1 => t('Unlimited'), 0 => 1) + drupal_map_assoc(range(2, 10)),
?>

becomes

<?php
'#options' => array(1 => t('Unlimited'), 0 => 1) + drupal_map_assoc(range(2, 10)) + drupal_map_assoc(range(20, 100, 10)),
?>

Jonathan

Files: 
CommentFileSizeAuthor
#138 D7-cardinality-680546-138.patch10.14 KBPancho
FAILED: [[SimpleTest]]: [MySQL] 41,134 pass(es), 7 fail(s), and 0 exception(s).
[ View ]
#135 allowed_number_of_values.png15.44 KBPancho
#128 680546-128.patch9.07 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 55,609 pass(es).
[ View ]
#127 680546-127.patch9.08 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 54,429 pass(es).
[ View ]
#127 interdiff.txt2.97 KBswentel
#122 680546-119.patch11.72 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 53,926 pass(es).
[ View ]
#122 interdiff.txt6.66 KBswentel
#119 680546-119.patch11.78 KBswentel
FAILED: [[SimpleTest]]: [MySQL] Setup environment: Test cancelled by admin prior to completion.
[ View ]
#119 interdiff.txt6.72 KBswentel
#116 680546-116.patch8.95 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 53,312 pass(es).
[ View ]
#116 interdiff.txt789 bytesswentel
#114 680546-115.patch8.92 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 53,419 pass(es).
[ View ]
#114 interdiff.txt1.42 KBswentel
#111 680546-111.patch7.98 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 53,329 pass(es).
[ View ]
#111 interdiff.txt3.25 KBswentel
#111 cardinality-allowed.png15.47 KBswentel
#110 680546-allowed-values.png397.66 KByoroy
#109 680546-allowed-values.png238.16 KByoroy
#107 680546-107.patch7.08 KBswentel
FAILED: [[SimpleTest]]: [MySQL] 53,272 pass(es), 8 fail(s), and 0 exception(s).
[ View ]
#107 cardinality-restrict.png25.49 KBswentel
#107 cardinality-unlimited.png24.22 KBswentel
#96 680546-96.patch6.93 KBCottser
PASSED: [[SimpleTest]]: [MySQL] 50,006 pass(es).
[ View ]
#95 interdiff.txt815 bytesCottser
#94 680546-94.patch6.8 KBCottser
PASSED: [[SimpleTest]]: [MySQL] 50,723 pass(es).
[ View ]
#88 680546-dropdown.png53.24 KBCottser
#88 680546-more.png49.97 KBCottser
#78 drupal8.field-cardinality-other.78.patch6.73 KBswentel
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal8.field-cardinality-other.78.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#78 interdiff.txt719 bytesswentel
#71 drupal8.field-cardinality-other.71.patch6.71 KBsun
FAILED: [[SimpleTest]]: [MySQL] 48,966 pass(es), 1 fail(s), and 1 exception(s).
[ View ]
#64 680546-62.patch6.61 KBCottser
PASSED: [[SimpleTest]]: [MySQL] 49,026 pass(es).
[ View ]
#64 interdiff.txt737 bytesCottser
#62 680546-61.patch6.61 KBswentel
FAILED: [[SimpleTest]]: [MySQL] 48,917 pass(es), 1 fail(s), and 0 exception(s).
[ View ]
#59 680546-59.patch6.6 KBswentel
FAILED: [[SimpleTest]]: [MySQL] 48,760 pass(es), 1 fail(s), and 0 exception(s).
[ View ]
#59 interdiff.txt1.24 KBswentel
#56 Screen Shot 2012-11-28 at 20.23.03.png21.13 KBswentel
#56 Screen Shot 2012-11-28 at 20.24.21.png32.29 KBswentel
#56 680546-56.patch6.4 KBswentel
FAILED: [[SimpleTest]]: [MySQL] 48,759 pass(es), 109 fail(s), and 23 exception(s).
[ View ]
#56 interdiff.txt805 bytesswentel
#52 select.jpg20.97 KBdodorama
#44 680546-44.patch6.39 KBCottser
PASSED: [[SimpleTest]]: [MySQL] 48,786 pass(es).
[ View ]
#44 interdiff.txt2.22 KBCottser
#43 680546-43.patch6.39 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 48,786 pass(es).
[ View ]
#43 interdiff.txt124 bytesswentel
#41 680546-41.patch6.39 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 48,764 pass(es).
[ View ]
#41 interdiff.txt701 bytesswentel
#39 680546-39.patch6.39 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 48,754 pass(es).
[ View ]
#36 680546-36.patch3.02 KBswentel
FAILED: [[SimpleTest]]: [MySQL] 48,762 pass(es), 8 fail(s), and 0 exception(s).
[ View ]
#36 Screen Shot 2012-11-24 at 02.40.33.png30.84 KBswentel
#34 680546-34.patch2.56 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 48,772 pass(es).
[ View ]
#32 680546-32.patch1.85 KBswentel
FAILED: [[SimpleTest]]: [MySQL] Repository checkout: failed to checkout from [git://git.drupal.org/project/drupal.git].
[ View ]
#32 Screen Shot 2012-11-24 at 01.14.47.png27.84 KBswentel
#24 cardinality_validation.patch910 bytesjramby
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch cardinality_validation.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#16 field_cardinality_to_textfield.txt901 bytesjramby
_cck.field_multiple_maximums.patch.txt605 bytesjonathan1055
cck field multiple maximums expanded to 100.jpg118.85 KBjonathan1055

Comments

jonathan1055’s picture

This enhancement was in response to image module issue #581174: Set the allowed number of image attachments. #21 and #22. I would suggest it would be a useful extra for many modules. Please consider adding it, as it would appear a simple change, or please explain if it is not simple and I am missing the point.

Jonathan

El Bandito’s picture

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

Cheers

El

jonathan1055’s picture

Well, I'm using it in a live environment but I guess you may have assumed that already ;-)

I hope it can be included, as it is such a simple patch but with a great increase in usefulness. As more modules start to use CCK node reference instead of rolling their own code, this could become even more of a required enhancement.

Jonathan

mattiasj’s picture

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

b0r7’s picture

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

olmomp’s picture

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)),

johnv’s picture

Title:Add more values for 'multiple' field maximums, eg. nodereference» Add a custom 'number of values' for 'multiple/ multi-value' field. (e.g. nodereference, imagefield)
Version:6.x-2.6» 7.x-2.x-dev

@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.

KarenS’s picture

Status:Needs review» Closed (won't fix)

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.

Fidelix’s picture

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

ispboy’s picture

I found the only way in D7 is: custom_formatter.

philsward’s picture

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.

csdco’s picture

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?

jnettik’s picture

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?

csdco’s picture

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.

philsward’s picture

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 : )

jramby’s picture

StatusFileSize
new901 bytes

Here's a patch, can anybody test it?

jramby’s picture

This issue belongs to drupal core field system I think.

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

jonathan1055’s picture

This issue is marked as 'closed (wont fix)' so it does not show up on members dashboards, even after an update. So if you want to continue this thread you will need to alter the status.

Does #1588624: Can field cardinality (number of values) range be other than just "1 to 10 and unlimited" ? replace this issue? If so, its ok to leave this thread closed. But I was not asking for unlimited, I wanted to specify a higher top limit.

jramby’s picture

Status:Closed (won't fix)» Fixed

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.

jonathan1055’s picture

Project:Content Construction Kit (CCK)» Drupal core
Version:7.x-2.x-dev» 7.14
Component:content.module» field system
Status:Fixed» Active

Hi,
OK in which case this issue can be moved into Core field system, as it contains more of the useful background, but nolonger relates to CCK. If you re-post your latest patch here, then the new issue #1588624: Can field cardinality (number of values) range be other than just "1 to 10 and unlimited" ? can be marked as 'closed(duplicate)'.

marcingy’s picture

Version:7.14» 8.x-dev

Features need to go into d8 first.

johnv’s picture

Title:Add a custom 'number of values' for 'multiple/ multi-value' field. (e.g. nodereference, imagefield)» Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)
Status:Active» Needs review

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.

johnv’s picture

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

jramby’s picture

StatusFileSize
new910 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch cardinality_validation.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Hi,

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

Status:Needs review» Needs work

The last submitted patch, cardinality_validation.patch, failed testing.

jramby’s picture

Version:8.x-dev» 7.x-dev

The last patch uploaded is for Drupal 7

Cottser’s picture

Version:7.x-dev» 8.x-dev

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

Cottser’s picture

kumkum29’s picture

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.

johnv’s picture

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

manoloka’s picture

What about for D6?

swentel’s picture

Status:Needs work» Needs review
StatusFileSize
new27.84 KB
new1.85 KB
FAILED: [[SimpleTest]]: [MySQL] Repository checkout: failed to checkout from [git://git.drupal.org/project/drupal.git].
[ View ]

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

Screen Shot 2012-11-24 at 01.14.47.png

swentel’s picture

Tagging also

swentel’s picture

StatusFileSize
new2.56 KB
PASSED: [[SimpleTest]]: [MySQL] 48,772 pass(es).
[ View ]

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

yched’s picture

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 :-(

swentel’s picture

StatusFileSize
new30.84 KB
new3.02 KB
FAILED: [[SimpleTest]]: [MySQL] 48,762 pass(es), 8 fail(s), and 0 exception(s).
[ View ]

I actually got it working! :)

Screen Shot 2012-11-24 at 02.40.33.png

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

Status:Needs review» Needs work

The last submitted patch, 680546-36.patch, failed testing.

Bojhan’s picture

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

swentel’s picture

Status:Needs work» Needs review
Issue tags:+Needs usability review
StatusFileSize
new6.39 KB
PASSED: [[SimpleTest]]: [MySQL] 48,754 pass(es).
[ View ]

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

swentel’s picture

Woops, remove tag.

swentel’s picture

StatusFileSize
new701 bytes
new6.39 KB
PASSED: [[SimpleTest]]: [MySQL] 48,764 pass(es).
[ View ]

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.

yched’s picture

Status:Needs review» Reviewed & tested by the community

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)

swentel’s picture

StatusFileSize
new124 bytes
new6.39 KB
PASSED: [[SimpleTest]]: [MySQL] 48,786 pass(es).
[ View ]

Makes sense indeed, old-school interdiff!

Cottser’s picture

StatusFileSize
new2.22 KB
new6.39 KB
PASSED: [[SimpleTest]]: [MySQL] 48,786 pass(es).
[ View ]

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

catch’s picture

Status:Reviewed & tested by the community» Needs work
+++ 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.

swentel’s picture

Title:Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)» Refine permissions for Field UI
Component:field system» field_ui.module
Assigned:Unassigned» swentel
Category:feature» task
Issue tags:+Novice

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 :)

swentel’s picture

Title:Refine permissions for Field UI» Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)
Component:field_ui.module» field system
Issue tags:-Novice

How the hell did that happen.

swentel’s picture

Category:task» feature

Oh man.

Xano’s picture

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.

swentel’s picture

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

Xano’s picture

+++ 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).

dodorama’s picture

StatusFileSize
new20.97 KB

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

swentel’s picture

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

yoroy’s picture

@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.

dodorama’s picture

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

swentel’s picture

Status:Needs work» Needs review
StatusFileSize
new805 bytes
new6.4 KB
FAILED: [[SimpleTest]]: [MySQL] 48,759 pass(es), 109 fail(s), and 23 exception(s).
[ View ]
new32.29 KB
new21.13 KB

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

Screen Shot 2012-11-28 at 20.23.03.pngitem

Screen Shot 2012-11-28 at 20.24.21.png

yched’s picture

Status:Needs review» Reviewed & tested by the community

Looks good. Setting back to RTBC.

catch’s picture

Status:Reviewed & tested by the community» Needs work

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.

swentel’s picture

Status:Needs work» Needs review
StatusFileSize
new1.24 KB
new6.6 KB
FAILED: [[SimpleTest]]: [MySQL] 48,760 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

Status:Needs review» Needs work

The last submitted patch, 680546-59.patch, failed testing.

Cottser’s picture

+++ 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."

swentel’s picture

Status:Needs work» Needs review
StatusFileSize
new6.61 KB
FAILED: [[SimpleTest]]: [MySQL] 48,917 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

Crap, forgot to change the assert text too.

swentel’s picture

@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 :)

Cottser’s picture

StatusFileSize
new737 bytes
new6.61 KB
PASSED: [[SimpleTest]]: [MySQL] 49,026 pass(es).
[ View ]

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

yched’s picture

Status:Needs review» Reviewed & tested by the community

And back.

Status:Reviewed & tested by the community» Needs work

The last submitted patch, 680546-62.patch, failed testing.

swentel’s picture

Status:Needs work» Needs review

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

swentel’s picture

Status:Needs review» Reviewed & tested by the community

And back again.

webchick’s picture

Assigned:swentel» catch

Looks like catch has been involved in this one.

catch’s picture

Status:Reviewed & tested by the community» Fixed

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

sun’s picture

Assigned:catch» Unassigned
Status:Fixed» Needs review
StatusFileSize
new6.71 KB
FAILED: [[SimpleTest]]: [MySQL] 48,966 pass(es), 1 fail(s), and 1 exception(s).
[ View ]
+++ 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.

Status:Needs review» Needs work

The last submitted patch, drupal8.field-cardinality-other.71.patch, failed testing.

yched’s picture

Status:Needs work» Needs review

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.

Status:Needs review» Needs work

The last submitted patch, drupal8.field-cardinality-other.71.patch, failed testing.

swentel’s picture

Status:Needs work» Needs review
swentel’s picture

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

Status:Needs review» Needs work

The last submitted patch, drupal8.field-cardinality-other.71.patch, failed testing.

swentel’s picture

Status:Needs work» Needs review
StatusFileSize
new719 bytes
new6.73 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal8.field-cardinality-other.78.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Status:Needs review» Needs work

The last submitted patch, drupal8.field-cardinality-other.78.patch, failed testing.

swentel’s picture

Status:Needs work» Needs review
yched’s picture

Status:Needs review» Reviewed & tested by the community

Yup, better now :-)

sun’s picture

Category:feature» task
catch’s picture

Status:Reviewed & tested by the community» Needs work

The last submitted patch, drupal8.field-cardinality-other.78.patch, failed testing.

tsvenson’s picture

Issue tags:+needs backport to D7

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?

Cottser’s picture

Assigned:Unassigned» Cottser

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".

tsvenson’s picture

@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.

Cottser’s picture

StatusFileSize
new49.97 KB
new53.24 KB

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

680546-dropdown.png680546-more.png

tsvenson’s picture

@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.

swentel’s picture

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.

tsvenson’s picture

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

Cottser’s picture

@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.

tsvenson’s picture

@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.

Cottser’s picture

Assigned:Cottser» Unassigned
Status:Needs work» Needs review
StatusFileSize
new6.8 KB
PASSED: [[SimpleTest]]: [MySQL] 50,723 pass(es).
[ View ]

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

Cottser’s picture

StatusFileSize
new815 bytes

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

Cottser’s picture

StatusFileSize
new6.93 KB
PASSED: [[SimpleTest]]: [MySQL] 50,006 pass(es).
[ View ]

Ahem.

yched’s picture

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.

tsvenson’s picture

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.

Xano’s picture

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

xjm’s picture

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."

swentel’s picture

Assigned:Unassigned» swentel

Makes sense, I'll code this later

xjm’s picture

Assigned:swentel» Unassigned

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.

xjm’s picture

Assigned:Unassigned» swentel

xpost

Thanks swentel!

xjm’s picture

Title:Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)» [Followup] Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)

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.

jibran’s picture

Title:[Followup] Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)» Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)

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

jibran’s picture

Title:Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)» [Followup] Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)

xpost

swentel’s picture

StatusFileSize
new24.22 KB
new25.49 KB
new7.08 KB
FAILED: [[SimpleTest]]: [MySQL] 53,272 pass(es), 8 fail(s), and 0 exception(s).
[ View ]

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.

cardinality-restrict.pngcardinality-unlimited.png

Status:Needs review» Needs work

The last submitted patch, 680546-107.patch, failed testing.

yoroy’s picture

Status:Needs work» Needs review
StatusFileSize
new238.16 KB

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)

yoroy’s picture

StatusFileSize
new397.66 KB

before/after screenshot with wording suggestions

swentel’s picture

StatusFileSize
new15.47 KB
new3.25 KB
new7.98 KB
PASSED: [[SimpleTest]]: [MySQL] 53,329 pass(es).
[ View ]

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!

cardinality-allowed.png

klonos’s picture

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

sun’s picture

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.

swentel’s picture

StatusFileSize
new1.42 KB
new8.92 KB
PASSED: [[SimpleTest]]: [MySQL] 53,419 pass(es).
[ View ]

@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.

sun’s picture

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? ;)

swentel’s picture

StatusFileSize
new789 bytes
new8.95 KB
PASSED: [[SimpleTest]]: [MySQL] 53,312 pass(es).
[ View ]

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'.

yched’s picture

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.

sun’s picture

Status:Needs review» Needs work
+++ 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?

swentel’s picture

Status:Needs work» Needs review
StatusFileSize
new6.72 KB
new11.78 KB
FAILED: [[SimpleTest]]: [MySQL] Setup environment: Test cancelled by admin prior to completion.
[ View ]

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
swentel’s picture

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

Status:Needs review» Needs work

The last submitted patch, 680546-119.patch, failed testing.

swentel’s picture

Status:Needs work» Needs review
StatusFileSize
new6.66 KB
new11.72 KB
PASSED: [[SimpleTest]]: [MySQL] 53,926 pass(es).
[ View ]
swentel’s picture

Assigned:swentel» Unassigned
xjm’s picture

+++ 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?

xjm’s picture

Status:Needs review» Needs work
swentel’s picture

Issue tags:+Field API

tagging

swentel’s picture

Status:Needs work» Needs review
StatusFileSize
new2.97 KB
new9.08 KB
PASSED: [[SimpleTest]]: [MySQL] 54,429 pass(es).
[ View ]

Removed the uncommented tests.

swentel’s picture

StatusFileSize
new9.07 KB
PASSED: [[SimpleTest]]: [MySQL] 55,609 pass(es).
[ View ]

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

Bojhan’s picture

Status:Needs review» Reviewed & tested by the community

Well, because you say please :)

Tested it and it works fine here.

alexpott’s picture

Title:[Followup] Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)» Change notice: [Followup] Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)
Priority:Normal» Critical
Status:Reviewed & tested by the community» Active
Issue tags:+Needs change record

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

yched’s picture

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

swentel’s picture

Title:Change notice: [Followup] Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)» [Followup] Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)
Priority:Critical» Normal
Status:Active» Fixed

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

protools’s picture

how about D 7 ?

Status:Fixed» Closed (fixed)

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

Pancho’s picture

Version:8.x-dev» 7.x-dev
Assigned:Unassigned» Pancho
Status:Closed (fixed)» Patch (to be ported)
Issue tags:-needs backport to D7, -Needs change record
StatusFileSize
new15.44 KB

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

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.

Maks’s picture

how about D 7 ?

Pancho’s picture

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

Pancho’s picture

Status:Patch (to be ported)» Needs review
StatusFileSize
new10.14 KB
FAILED: [[SimpleTest]]: [MySQL] 41,134 pass(es), 7 fail(s), and 0 exception(s).
[ View ]

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.

Pancho’s picture

Status:Needs review» Needs work
Pancho’s picture

Version:7.x-dev» 8.x-dev
Issue tags:+needs backport to D7

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

swentel’s picture

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

Cottser’s picture

Agreed.

swentel’s picture

Title:[Followup] Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)» Add a custom 'number of values' for 'multiple / multi-value' field. (e.g. nodereference, imagefield)
Version:8.x-dev» 7.x-dev
Issue tags:-needs backport to D7

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

amirtaiar’s picture

#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.

sreynen’s picture

Issue summary:View changes

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

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch, 138: D7-cardinality-680546-138.patch, failed testing.

lquessenberry’s picture

I used #145. Great work.

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch, 138: D7-cardinality-680546-138.patch, failed testing.

ydahi’s picture

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.