When adding existing field "Label" is cleared when exiting field

The intended behavior is that the 'Label' input gets pre-populated with the label of the selected "existing field".

#6: existing_field_ui.patch queued for re-testing.

Strange, I can't seem to apply ?

DOh, I overlooked the date on #6.

Rerolled, and fixed / reorganized a bit. Should work ok now.

Steps to reproduce :
- On a default install, go to admin/structure/types/manage/page/fields ('Manage fields' for 'Page' node type)
- 'Add existing field' row shows two potential fields to add : field_image, field_tags (defined for 'article' but not for 'page')
- when you select one of those,
the 'Label' input should get populated with the Label of the existing instance,
the 'Widget' select should be updated to show widgets for the corresponding field type (image or taxo_term) [edit: forget it, that part works], and should be prepopulated with the widget used by the existing instance.

None of the two work currently. I don't know at which point this got broken. Note that this is JS-only, so there's no writing tests for this.

[edited out]

nevermind, not critical.

Coming over belatedly from #735204: vanishing label text from manage fields page.

#9: field_ui_add_existing_js-684310-9.patch queued for re-testing.

I agree this sounds annoying, but it's certainly not "major".

Reroll of #9. Tested manually, works.

Steps to reproduce :
- On a default install, go to admin/structure/types/manage/page/fields ('Manage fields' for 'Page' node type)
- The 'Add existing field' row shows two potential fields to add : field_image, field_tags (defined for 'article' but not for 'page')
- when you select one of those, the 'Label' input should get populated with the Label of the existing instance.

JS behavior only, not bot-testable.

beloved bot, can I haz test ?

subscribing

This yched's patch works fine. How about to commit it in D7?

#21: field_add_existing_prepopulate_label-684310-21.patch queued for re-testing.

#21: field_add_existing_prepopulate_label-684310-21.patch queued for re-testing.

With the patch in #21 I was seeing two ' - Select an existing field - ' options: one being added to the $existing_field_options array, and one being added as the #empty_option. I removed the one from the $existing_field_options array and rerolled the patch for git and coremageddon. It seems to work fine. I hope the bot agrees.

True, thanks for the reroll ! Now we need someone to RTBC...

Maybe we should only update the label automatically, when the user hasn't manually entered something.

Other than that:

• $existing_field_options is renamed. Maybe rather leave it as it is or rename the function that creates it, too.
• The list of fields should still be sorted.

Updated patch:
- Re-adds the sorting.
- Removes the custom '...' ellipsis when truncating the strings and uses the one built in truncate_utf8()
- Only overwrites the "Label" input if it didn't receive manual edits (or if it's back to empty)

I'd rather keep the function name.

Applies, works, looks awesome. Presumably passes the tests. Thank you :)

Minor point: Maybe val(...) instead of attr('value', ...)?

The rest of core is more consistent on val() vs attr('value'), so yeah.

Alright. Thanks.

Looks like this has had plenty of manual testing, so committed/pushed to 8.x.

Doesn't this also need a backport?

Working backport with just the filenames changed attached.

Applies cleanly to current 7.x HEAD and functionally identical to D8 version which has been committed.

Oh man! This bug is really annoying. So happy to see a fix!

Committed and pushed to 7.x. Thanks! :)