Setting the machine-readable name of a field on one screen and the human-readable name on the next is confusing. It would be better to alter the add new fields screen so that you create both at the same time on the same screen. That also provides some context to better understand what they do. Once this is done, we can add a DROP task to add an auto-complete suggestion to the field name so that you enter a field label, and the javascript creates a suggested field name which you can keep or override.

Comments

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Having both on the same form would definitely be both more consistent with the way core does it, and also would avoid people constantly skipping over that Label field on the second page.

However, I think in both core and in CCK, we should just be smart and figure out the machine name ourselves, perhaps exposing a UI for it in some advanced screen. There's in almost 100% of the cases no reason for a user to know or care about how Drupal refers to the field.

moshe weitzman’s picture

moshe weitzman commented

The machine name of a field is vital for themeing and for dvelopment in general. I do not agree that this one of those "hide the guts" issues.

karens’s picture

karens commented

The reason for letting people control the field name is so we can be sure about what name we are creating, otherwise we unexpectedly end up with field_name1 and field_name2.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

@moshe: yes, and theming/development people are going to use devel theme module, contemplate, or print_r(). :P Why does this need to be exposed by default in the UI?

@Karen: How about a confirm form that says "You already have a field called 'Name.' Would you like to re-use this field in the X content type?" Ideally with a "What's this mean?" link that you can click for more contextual help.

karens’s picture

karens commented
Status: Active » Fixed

Just committed a fix for this. More work could be done by adding some jQuery to the process, but the process seems much more intuitive and less confusing.

Rework field and widget type handling to simplify the initial screen when choosing a field and widget type by making it a two-step process where you see only the widgets that apply to the field. Move the setting of the field label to the same place where you set the field name. Change the field edit screen to keep it from showing all the different widgets again and instead just display the current widget. Then add a button to change the widget which will take you to another screen to make the change since the rest of the page will need to change when the widget changes. Keep the changes to the widget label in that separate process, too, since that affects the menu tabs that need to be changed before redirecting back to the main page.

All working well except that changing the widget for an existing field is not redirecting back to the field edit page as it should.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

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