When you create a new field, or add existing, it is visible in Manage Display and edit pages as soon as you hit the save button on the Manage Fields page.

Reproduce:
- Use existing or create a new field
- Click save
- Wait until the field settings appear, but don't do anything
- Open Manage Display and the field is available there
- Open the content type you added it to and edit it, the field is already there

This happens for taxonomy terms as well.

Even worse, you can add content, upload images, etc and save without Drupal complaining. If you upload an image you will even see the preview when the upload is done. There are thus no indication that something is wrong.

When you discover this mistake and make all the settings for the field, all content added disappears.

Drupal also does not warn if you navigate from the field settings page without having completed it.

Fields should not be visible until all required settings for it has been done.

Comments

marcvangend’s picture

marcvangend
he/him
Primary language Dutch
Location Amsterdam
CreditAttribution: marcvangend commented
Version: 7.0-alpha5 » 7.x-dev

I'm not sure if this is critical. AFAIK it's the same in D6, so it's not a regression. Filing this against 7.x-dev so more devs will see it.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Priority: Critical » Normal

I also think this isn't critical, you have to deliberately break the workflow (or something serious has to happen which breaks it) to end up in this state.

tsvenson’s picture

tsvenson CreditAttribution: tsvenson commented

@catch you mean your workflow when you add the field?

What about the case when you are updating a pretty busy live site. Only way to avoid having the new field show up would be to put the whole site in maintenance mode to make sure that no user starts adding stuff in it until it s completely configured.

Other things that might hinder you complete it is that you lose internet connection, power cut, the browser or your computer crashes, etc. The field is still there and not until you can logon and complete the settings it will work properly.

OK, I know this does not happen often, but I still believe that the new field should not be visible anywhere else until it is properly configured.

marcvangend’s picture

marcvangend
he/him
Primary language Dutch
Location Amsterdam
CreditAttribution: marcvangend commented

For a use case like that, you can use the import-export function.

bjaspan’s picture

bjaspan CreditAttribution: bjaspan commented

I'm generally inclined to agree with the basic premise of this issue. Field creation and setup via Field UI is not inherently atomic, and since we provide the UI arguing that "you can solve this problem with export/import" is not satisfying. Note also that export/import cannot handle updating fields at all.

We already have a "deleted" property on fields and instances. Changing that to "status" and supporting "disabled" as an option would be a pretty small change and would be in the spirit of the kind of API/data consistency that we aimed for with Field API. We would need to think a bit about the consequences of disabling a field or instance with existing data. For example: If a field is required, gets disabled, and an entity is created, now that entity exists without data that the Field API says should be there. However, that also happens when a required is created after entities already exist, so it is not a new problem. Certain operations would want to ignore disabled fields and the rest would not; offhand, I'd say all Field Attach API operations should ignore them, while Field CRUD/Info API should not (e.g. I can list, update, and delete a disabled field, even though its content/forms will not show up on entities).

tsvenson’s picture

tsvenson CreditAttribution: tsvenson commented

@bjaspan Just adding a reference to #821336: Option to disable fields instead of being forced to delete them since this is related to your comment.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

@bjaspan: field_update_instance() in a hook_update_N() works great, if you need rock solid deployment, you shouldn't have Field UI module enabled at all.

Having said that, allowing a field to be disabled while it's in the progress of being set up, then enabled when it's fully configured, seems like a good idea if it's not too much work.

yched’s picture

yched CreditAttribution: yched commented

I don't like either the fact that UI field creation is not atomic.
I opened #508684: Field storage always uses default field settings quite some time ago, and didn't really have nor take the time to get back at this. This would very much deserve to be refactored into a true multistep form.
+ the field_ui_get_destinations() / field_ui_next_destination() functions that handle the 'multiple redirects' are the last piece of 'eww' CCK code that remain in core.
The 'Display' part of the UI kept me rather busy the last couple weeks, but the 'Manage fields' / 'add field' / 'edit field' side could still use some love :-(.

Might be paranoia, but I'm really wary about 'disabled' fields. We already have 'inactive' fields (compared to CCK D6, this has been reduced to the single case when the field type module is disabled), and this in-between "I'm there but I'm not there" state can be fairly tricky to handle in dark corners.

tsvenson’s picture

tsvenson CreditAttribution: tsvenson commented
Version: 7.x-dev » 8.x-dev

Was looking for an old issue of mine and stumbled on this one. Is this still valid for 8.x too?

swentel’s picture

swentel CreditAttribution: swentel commented
Status: Active » Closed (duplicate)

I'd say, add more comments to #1963340: Change field UI so that adding a field is a separate task. There are so many issues re: field ui that it's not funny anymore. We need a big plan first :)