Fields with unlimited cardinality show 1 extra input field

Hey @darren-oh, I will adjuste that.
Also I'm having some problems to fix this test failing. This particulary test are failing without my patch. I don't know how to fix it.

FYI the ultimate fix will be covered in ✨ Initial number of fields visible on the form should be configurable for fields set to unlimited value Active truly doubt this one will be merged.

Thanks @smustgrave, I was trying to fix the php units that are failing.
Also the approach to have config to set how many empty items to be displayed is better.

Should we close this issue?

The issues are similar but not the same.

No matter if this issue will be merged or not, I spent too much time investigating this issue to not provide the possible fix that I found :). If the issue ✨ Initial number of fields visible on the form should be configurable for fields set to unlimited value Active is still not merged someone can use this patch.

Removing extra input when the field settings have a default value. See the picture attached.

With this change, we don't have an extra input by default in any situation, only when the user clicks in add more button.
Also, the test that failed for me doesn't make sense so I changed how the test works. But I think is necessary to be validated by someone else.

This is the test that failed.

Drupal\Tests\field\Functional\FormTest::testLabelOnMultiValueFields
Behat\Mink\Exception\ExpectationException: The string "alert('a configurable field');" was not found anywhere in the HTML response of the current page.

The test check $this->assertSession()->assertEscaped("

");
But when we create a field with this label the tag script is filtered and the label becomes alert('a configurable field');
So I think the correct way to validate if the tag script is filtered is to check if the tag script doesn't appear on the page as my changes do.
But will amazing if someone else confirms that in a code review.

$this->assertSession()->pageTextContains("alert('a configurable field');");
$this->assertSession()->pageTextNotContains("

");

@joaopauloc.dev thanks for the patch. #58 🐛 Fields with unlimited cardinality show 1 extra input field Needs work Patch Applied on 10.1.x-dev and it fixes the issue.

Didn't work as expected when we use unlimited fields with paragraphs.

Seems to me like there might be a lot of crossover between this and ✨ Fixed maximum number of field values, but use «add more» similar to when cardinality «unlimited» is used Needs work

Maybe both should be triaged into a _Optimising add more button behavior_ issue

I like this idea, but I would suggest that this should be something that could be configured in the widget settings.

Strongly agree! :)

Hi!

Thanks joaopauloc.dev for the patch. Unfortunately i could not apply it for 9.5.x so here it goes a path for that version.

I have noticed a duplicated declaration of $context that you have removed in your patch (I think the reason it does not work with 9.5.x), but i have opened an issue ( https://www.drupal.org/project/drupal/issues/3378657 🐛 Duplicate declaration of $context in WidgetBase Fixed ) to spot that duplication and remove it, so i have omitted it from my patch.

PD: I have not tested it within fields inside paragraphs, but once i have a bit of time, i will check this too

Best

Hey folks, I created a new merge request regarding the comments above, the number of extra inputs to be displayed should be a configuration.

A new configuration was added to the field storage settings, like the image below:

When the unlimited option is selected a new field is displayed for the user to choose how many extra inputs will be displayed.

1. By default, I choose 1, because this is how it works today, one extra input appears.
2. If the user selects 0, no extra input will appear, if the user is adding the form entity. Only one input will appear.
3. If the user selects 0 and is editing the form entity, if there is no value one input will appear, otherwise only the input with value populate will appear without any extra input.

Example:
Field with 3 extra inputs to be displayed:

So, for the editing form, as I configured 3 extra inputs but populated only 2, any extra input will appear.

Once we define a number of extra inputs to be displayed when the user is adding the number of inputs selected will appear, If the user is editing but there is no value added previously, the number of inputs keeps the configuration, since the user added more or fewer items that were configured, only the values populated is displayed without any extra input.

Maybe we need to discuss the rules mentioned above, how we should display the inputs if the user is editing.

If we are going to change the schema we will need an upgrade path with tests.

There's another aspect, which makes this fix major from my perspective. If the added field is a required field (or contains a required field in a compound custom widget type), there's no way to remove the extra field and you're unable to submit the form with the required field!

That makes using #required impossible on custom compound field widgets!
But without the required indicator, the user can't see which compound fields are required, until submit (validation)!

So the best solution is to not add the new line automatically and be able to remove it.
Just ran into this when implementing Homebox 3.x.

Adding 10.2 support for patch #3

@sathishkumar

Thanks for the patches, but the changes will be merged to the development branch first, then backported.

I can't reproduce the behaviour reported in #69 on D11.

Steps:

1. Add a new field with unlimited cardinality
2. Add a node with one value
3. Edit the node, see the extra input
4. Save

Bumping down to normal, unless someone has different steps to reproduce that? I am 50-50 on the usability aspect, I could see both sides of the argument.

prashant.c → changed the visibility of the branch 11.x to hidden.

• Rebase the current PR branch with 11.x
• Tested on Drupal 11 have following points

1. The placement of the section Extra inputs to displayis not good from the usability point as it giving an impression that the cardinality text field is standalone, it has moved the cardinality text field which should be next to the dropdown Allowed number of values
2. When the cardinality has been specified, the value in the Extra inputs to display text field should be validated for the max value either on Form submit or on value change, currently it allows greater values than cardinality, however on the frontend displaying the fields correctly but the value is still allowed to be entered

Thanks!

quietone → credited Omega_yang → .

I was triaging ✨ Remove auto added empty field from multiple values field. Needs work and came here because this seems like a duplicate. In fact this was closed as a duplicate of a different issue and credit was moved over there. That was issue ✨ Initial number of fields visible on the form should be configurable for fields set to unlimited value Active . After reading three incomplete issue summaries and the comments on three issue, I have decided that this one should go back to the original intention, which was a UX issue. And, since this is the older issue and has more discussion I am closing ✨ Remove auto added empty field from multiple values field. Needs work as a duplicate and moving credit. The work here, from about #47 is out of scope and should move to ✨ Initial number of fields visible on the form should be configurable for fields set to unlimited value Active , the original issue to add the extra configuration.

This issue is solely about the UX of the extra blank field that appears on edit. See the remaining tasks for what needs to be done.

Everyone, please keep the issue summaries up to date. Incomplete summaries makes it more difficult to work with an issue and to get it to commit. Thanks.