Last updated January 11, 2012. Created by arianek on November 30, 2009.
Edited by mgifford, Carolyn, LeeHunter, bmadore. Log in to edit this page.
The Field UI module provides an administrative user interface (UI) for attaching and managing fields. Fields can be defined at the content-type level for content items and comments, at the vocabulary level for taxonomy terms, and at the site level for user accounts. Other modules may also enable fields to be defined for their data. Field types (text, image, number, etc.) are defined by modules, and collected and managed by the Field module.

Uses
Planning fields
There are several decisions you will need to make before definining a field for content, comments, etc.:
- What the field will be called
A field has a label (the name displayed in the user interface) and a machine name (the name used internally). The label can be changed after you create the field, if needed, but the machine name cannot be changed after you have created the field. - What type of data the field will store
Each field can store one type of data (text, number, file, etc.). When you define a field, you choose a particular field type, which corresponds to the type of data you want to store. The field type cannot be changed after you have created the field. - How the data will be input and displayed
Each field type has one or more available widgets associated with it; each widget provides a mechanism for data input when you are editing (text box, select list, file upload, etc.). Each field type also has one or more display options, which determine how the field is displayed to site visitors. The widget and display options can be changed after you have created the field. - How many values the field will store
You can store one value, a specific maximum number of values, or an unlimited number of values in each field. For example, an employee identification number field might store a single number, whereas a phone number field might store multiple phone numbers. This setting can be changed after you have created the field, but if you reduce the maximum number of values, you may lose information.
Reusing fields
Once you have defined a field, you can reuse it. For example, if you define a custom image field for one content type, and you need to have an image field with the same parameters on another content type, you can add the same field to the second content type, in the Add existing field area of the user interface. You could also add this field to a taxonomy vocabulary, comments, user accounts, etc.
Some settings of a reused field are unique to each use of the field; others are shared across all places you use the field. For example, the label of a text field is unique to each use, while the setting for the number of values is shared.
There are two main reasons for reusing fields. First, reusing fields can save you time over defining new fields. Second, reusing fields also allows you to display, filter, group, and sort content together by field across content types. For example, the contributed Views module allows you to create lists and tables of content. So if you use the same field on multiple content types, you can create a View containing all of those content types together displaying that field, sorted by that field, and/or filtered by that field.
- Fields on content items
Fields on content items are defined at the content-type level, on the Manage fields tab of the content type edit page (which you can reach from the Content types page). When you define a field for a content type, each content item of that type will have that field added to it. Some fields, such as the Title and Body, are provided for you when you create a content type, or are provided on content types created by your installation profile. - Fields on taxonomy terms
Fields on taxonomy terms are defined at the taxonomy vocabulary level, on the Manage fields tab of the vocabulary edit page (which you can reach from the Taxonomy page). When you define a field for a vocabulary, each term in that vocabulary will have that field added to it. For example, you could define an image field for a vocabulary to store an icon with each term. - Fields on user accounts
Fields on user accounts are defined on a site-wide basis on the Manage fields tab of the Account settings page. When you define a field for user accounts, each user account will have that field added to it. For example, you could add a long text field to allow users to include a biography. - Fields on comments
Fields on comments are defined at the content-type level, on the Comment fields tab of the content type edit page (which you can reach from the Content types page). When you add a field for comments, each comment on a content item of that type will have that field added to it. For example, you could add a website field to the comments on forum posts, to allow forum commenters to add a link to their website.
Versions
Drupal 7
This module was introduced in Drupal 7. Unlike in earlier versions, you do not need to download a separate module to add fields to a content type.
The Content Construction Kit (CCK) in Drupal 6 and lower
Field UI module is the core version of the Drupal 6 CCK module.
Technical details
Default module: Yes.
Dependencies: Field, Field SQL Storage module or custom storage module.
Related Modules: Field, Field SQL Storage, File, Image, List, Number, Node, Taxonomy, User, Text
Permissions: None.
API Documentation: Field storage API
Database tables: None.
Comments
Remove/Delete a field
Hello,
How would one remove a field completely?
Many thanks
To remove a field completely...
To remove a field completely one would delete it from all existing content types where it exists.
However, some modules create fields automatically and must be uninstalled to have their fields removed ;-)
Remove fields completely
For Drupal7 only,
From direct database manipulations you can completely remove the fields.
{field_config} - metadata
{field_config_instance} - bundle data
{field_data_machine_name} - table holding the data for the fields
{field_revision_machine_name} - table holding the revision information for the fields
field_data_machine_name - this entirely depends on the module that implements the field api so its hard to get all of the fields, but can always be viewed from the manage fields of the content type, which is one way of finding the machine name for the field.
for eg. say, field has machine_name "link_value" the actual table storing information for this field will be "field_data_machine_name"
Excel the world with the drupalway
Drupal 7
Problems to import from drupal6 (cck and imagecache)
content-type with existing fields
I am trying to create a custom content type which allows the users to do any of the two things -
1) either upload a file
or
2) write a new publication.
For this - i created a custom content type - added fields - changed the desired display settings.
The content type perview looks like i wanted it to.
The went to 'add content' - under the newly created content type, added it to a menu item and published it.
However, while it shows nicely in the content type preview - it does not display the forms in the actually publsihed content.
Subscribed.
which has two existing fields - file/ long text.
Then I 'add content ' choosing this content type
content-type/existing fields/diplaying UI forms
I am trying to create a custom content type which allows the users to do any of the two things -
1) either upload a file (field type - 'file' )
or
2) write a new publication. (field type - 'long text')
For this - i created a custom content type - added fields - changed the desired display settings.
The 'content type ' perview looks like i wanted it to.
The went to 'add content' -> newly created content type -- added it to a menu item and published it.
However, while it shows nicely in the content type preview - it does not display the forms in the actually publsihed content.
Subscribed.
I am working with the existing fields so I presume i do not need to look at Field SQL Storage modules. (Or do I ?)
subscribe
subscribe
content-type/existing fields/diplaying UI forms
I am trying to create a custom content type which allows the users to do any of the two things -
1) either upload a file (field type - 'file' )
or
2) write a new publication. (field type - 'long text')
For this - i created a custom content type - added fields - changed the desired display settings.
The 'content type ' perview looks like i wanted it to.
The went to 'add content' -> newly created content type -- added it to a menu item and published it.
However, while it shows nicely in the content type preview - it does not display the forms in the actually publsihed content. How do i make the form appear ?
Subscribed.
I am working with the existing fields so I presume i do not need to look at Field SQL Storage modules. (Or do I ?)
Hi I have a content type
Hi
I have a content type which has just 3 fields, title, body, image. I try to adjust the display settings and I get an AJAX error:
Error:
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /drupal7/system/ajax
StatusText: OK
ResponseText:
Fatal error: Function name must be a string in c:\wamp\www\drupal7\modules\field_ui\field_ui.admin.inc on line 143
I'm really not sure what I've changed, but everything had been working perfectly for some time.
Jibb
Add a Class to an image field to allow CSS to be used
I have not been able to identify a way of applying CSS to images specifically on my node--blog.tpl.
Is there a method of creating a class name when creating the image field?
EDIT:
I found the answer and broke the site for a short time.
The name I specified here admin/structure/types/manage/blog/fields was just image so the class was field-name-field-image.
By changing every database field that related to this (about 10) I changed it to image_blog which creats a class of field-name-field-image-blog
Custom Content
When users sign up for accounts on our site, we would like to ask them additional questions about their location and how they found us for our records. I was able to create these fields just fine, but how do I compile all of the users and their responses in one report/exported file?
Sounds like a perfect fit for
Sounds like a perfect fit for Webform module.
Webform enabled content types will allow you to attach a form to your content. After user complete and submit the form, you can then export the results in several different formats, e.g. csv.
Reggie W
Misprint / Typo
In the section "How the data will be input and displayed" the word "display" is used twice:
"The widget and display display options can be changed after you have created the field."
If that gets fixed, this comment may be deleted. :)
Can edit but not delete comments
I fixed the the text. Thanks for pointing it out.
--
OpenConcept | Twitter @mgifford
Performance - Reusing Field
I'm wondering if there is a difference in term of performance between reusing fields and not. I believe (I'm not sure of that though) that on Drupal 6 the performance was better if we didn't use "existing field". Even if that sounds stupid and that I can't find the source of that it's what I've read. So I was wondering which is the best in term of performance for Drupal 7. Re-use fields or creating a new one ?
I am also wondering what's
I am also wondering what's the difference in term of performance.
For example my web site is using the same "body" field type in several node types. I dont know what would be the better way:
- either using the same "body" field everywhere ( result is one single heavy table in the data base)
- or create a "nodetype_body" field for each node type( result is multiple lighter tables)
in term of database management and backup I guess the second way is better
In term of field configuration (size, display,...) the second way will also provide better flexibility
in term of performance I have no idea.
Impact from JOIN required for shared field
Impact is from JOIN required for shared field
I also read about this in Merlin's book too. Drupal's Building Blocks: Quickly Building Websites with CCK, Views and Panels. By: Earl Miles, Lynette Miles
Some info below from: http://www.webinit.org/2010/01/01/building-drupal-with-reusable-fields/
- Learn best practices in Acquia's Drupal training http://training.acquia.com/
- Tips on Giving effective feedback in the forums
It's been a while but thanks
It's been a while but thanks for your answer heather. So, from the link you sent, in a performance standpoint, it seems better to re-use fields, which makes complete sense to me. Glad to finally get an answer on that.
Adding a "block of fields"
I was wondering if it's possible to add a "block of fields" to a content type... What I mean is for example, I want to put certain specific contents in the main page and these fields would neet to have some special fields like the order they apear, the heading, etc... It's possible to define these fields, "group them" and later add this group to any other content type ?
Thanks in advance !!! :-)
Cardinality for a "block of fields"
I am also interested in this. I would like to be able to reuse the "block of fields" and have the ability to add one or more "blocks of fields" to a custom node type.
I've looked at field_goup but there doesn't seem to be any way to control cardinality for that the way you can for say a text field. Is it best to create a whole new data type and just use a node reference? That seems to add some complexity that might confuse some users.
It would be simpler to define a field type that can store say a picture and text about it. Is this possible? What would be the best way to do it?
Should I create a custom entity (Drupal 7) and use it to group the fields?
DruHosting.com
Check out Field Collection Module
http://drupal.org/project/field_collection
Mark Sutton
www.openupmarketing.com