Fields UI (in Core)

tstoeckler's picture

With Field API in Core I think we are shooting ourselves in the foot if we ship without a UI for it.

That having been said, let's see where we are at.
The Current Field UI / CCK UI still lives in contrib because it is said to be too complex or downright bad to belong in core.
Hence, if we want a Field UI in core we need to make it less complex. If you visit admin/build/types with CCK UI enabled you have have an admin page that needs to achieve all of the following:

  1. Creating content types
  2. Edit existing content types' settings
  3. Delete content types
  4. Create fields
  5. Assign created fields to certain content types ("Create field instances")
  6. Edit existing field instances' settings
  7. Change the order of the fields in a content type
  8. Configure the display settings of all fields on a content type depending on the display type (teaser, full node, ...)

Now who is to blame for calling this complex!
So what can be done:
1. - 3. Are essential part of the content types screen and have nothing to with the Field API.

4. Creating fields: For me this doesn't belong here. In Field API content types are bundles which create instances of already existing fields. So why not go the way of the API? IMO Fields deserve their own page in the admin area: Think of admin/build/fields where you can add new fields and existing ones are listed. I created a mock-up of what this could look like:
This very much resembles various other list/add sections in the Drupal admin area so there shouldn't be anything new about it.

5. -7. Adding, editing, ordering field instances: In my proposal this would be left for the bundles' interface, in this case the node type / content type interface. After a field has been created (see above) the workflow would be the following:
visit admin/build/types and notice the "manage fields" link for the content types:
Clicking on one of those "manage fields" links brings you to the following page:
Here you can reorder the fields / field-like things (7.)
If you want to add an existing (!) field to this content type, you click the tab "Add fields" (should probably be "Add field") at the top.
This leaves you here:
There you can select a field and set up the settings of that field (the settings would have to change via JS to reflect the currently selected field (maybe it would even be best to leave out the settings here)). Clicking "Add" at the bottom sends you back to the previous page.
Clicking on edit on one of the fields gives you a similar page to the previous (except the "Select the field" part is gone, of course).

8. Display settings: Even though I understand how crucial this is to certain sites, I would leave this out of the Core Field UI for now (!).

fields_ui_add_field_instance.png93.87 KB
fields_ui_list_fields.png84.36 KB
fields_ui_add_field.png88.42 KB
fields_ui_list_content_types.png103.09 KB
fields_ui_configure_content_type_1.png70 KB


Screenshots broken ;-)

yched's picture

Thanks for rolling the ball, tstoeckler !
No time to comment right now, but the screenshot links are broken.


tstoeckler's picture

Thanks, re-uploaded the files.
Btw, the nervewrecking inconsistencies of upload.module are another reason why we need a Field UI (and FileField) in core!

I'm trying to wrap up a

yched's picture

I'm trying to wrap up a UI-oriented summary of the Field API concepts and features to set a basis for discussion.

For now, I'll just remind that CCK HEAD ( or from CVS) contains a working D7 port of the current CCK D6 UI. Not perfect, and doesn't support all Field API features (notably formatter settings), but lets you add/edit/remove fields on node types and users (work in progress for taxo terms).

I'll also point to Dries's recent post, 'Field UI' section, for a good summary of where we stand.

A few comments

yched's picture

A few comments on the OP:

  • tasks 1-3 (creating and editing content types) do not belong to the current CCK D6 UI or to the D7 Field UI, whatever it will be. For instance, fields can now be assigned to taxo terms in each vocabulary, and the pages to create, update, delete vocabularies naturally don't belong to the Field UI.
  • Definitely worth considering, but I'm personally not sure that separating 'create fields' from 'create instance on a given bundle' is a good idea, because it forces you to go to two different places to do something like 'add a text field to story nodes'. Compare with the current, 'relatively' streamlined UX for the same task in D6


tstoeckler's picture

I'm personally not sure that separating 'create fields' from 'create instance on a given bundle' is a good idea, because it forces you to go to two different places to do something like 'add a text field to story nodes'

True, I just really like the resemblance of UI and API in that case. With e.g. terms being fieldable and probably more to come, I just really like that you can get an overview of all fields at admin/build/fields. Similar to the admin/build/fields with the current CCK D7 UI.

I read Dries' post and I'm glad that yoroy and Bojhan are apparently on this.

I'll see what happens in this direction and maybe post something that takes your concern into account...

UI-oriented summary of Field API

yched's picture

I posted this as a separate page to be able to refer to it easily.
Although, it seems that g.d.o wiki pages do not support comments, so we might want to keep this thread for the discussions - or any other place more inline with the D7UX habits ?

I opened up the wiki page

moshe weitzman's picture

I opened up the wiki page for comments.