Normally, when a Drupal field is set to "Unlimited" (on the Field Settings screen), one has to click the "Add another item" button to generate an additional instance of it. However, with the Name field, an extra instance is erroneously tacked on each time the field is saved -- a problem that gets compounded with each additional update.
For example: if you added the Name field to a content type, set "Allowed number of values" to "Unlimited," then saved a node seven times (leaving the Name field blank each time), eight instances of the Name field would end up being attached to that node.
Interestingly, this same phenomenon happens when just configuring the Name field. On the Edit screen, in the "Default Value" section, an additional instance of the Name field is added every time that screen is saved.
These extra instances of the field become problematic when the Name field data is being displayed. If you added two names to a Name field and then viewed the node, the data would be formated like there are actually three or more names.
It's almost like the "blank" instance of the Name field isn't actually empty -- at least, as far as Drupal is concerned -- causing an extra instance of the field to be erroneously generated each time.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | name-2849973-7-name-widget-saving-empty-data.patch | 775 bytes | alan d. |
| #3 | name-unlimited-instances-problem-2849973-11942411.patch | 3.76 KB | slanger |
Comments
Comment #2
slanger commentedThe following patch should fix the problem. I'm sure there's a more elegant solution out there; but until someone figures it out, this will hopefully do the trick. :-)
When "Allowed number of values" is set to "Unlimited" on a patched version of the name field, it should behave more like other Drupal fields with that setting.
Testing
I tested to see if this patch has any negative effects when allowed number of values is set to a specific number.
Comment #3
slanger commentedTweaked the patch and queued it to be tested.
Comment #4
alan d. commentedif applicable, set to Patch (to be ported) after it is committed to 8.x :)
Comment #5
slanger commented@Alan D.: Let me know if there's something else you need me to do besides just changing the status. :-)
Comment #6
alan d. commentedSo patch is for D8 and has not been reviewed by anyone (coding standards and if it actually works). So the correct status is "Needs Review"
Once RTBTC, it would be applied to 8.x.
At this point, it is either fixed OR set to backport to 7.x IFF 7.x needs it
So, as of right now I haven't reviewed and a second person should do this before changing the status to Reviewed & tested by the community. I added the tag "needs backport to D7" just in case.
Comment #7
alan d. commentedAppears that massageFormValues() handles this nicely :)
Comment #8
alan d. commentedComment #9
alan d. commented