Last updated November 25, 2015. Created on November 30, 2009.
Edited by kakinne, mikenzig, ashish_nirmohi, NewSites. Log in to edit this page.

In Drupal, a Content Type is a pre-defined collection of data types (Fields) which relate to one another by an informational context. In this sense, "context" means "parts that should be considered as a correlated whole."

Content Types define default fields for editors to add content on a Drupal site and are the building blocks for structured authoring and content. Content types often work in conjunction with Views, which is one way you can serve up content to your end users; you can control the content types that appear and the order in which they appear. Developers can also customize the authoring experience in the same way.

One way to think of content types is to visualize the contacts on your mobile phone. If you were to duplicate this on a Drupal site you would create a Content Type. You would name your new Content Type (e.g. Contacts), define the information that you wanted to store about each contact (called Fields in Drupal), and then add those Fields (e.g. First name, last name, and mobile phone number, etc.) to that Content Type. You would then use this "Contacts" Content Type to enter the information for each of the contacts you had in your contacts list. You would use a View (as described above) to display your Contacts in a list similar to that which you see on your mobile phone.

Field terminology:

  • Field. A category of data that can be added to an element, for example: Title, Body, Comment body, Tags, Image.
  • Field type. The data type of a field, for example, text, integer, image.
  • Field instance. A field added to an element.

"Element" above is not Drupal terminology but is used here for convenience. In Drupal terminology, this is either an entity type (such as a node or taxonomy term) or a bundle (such as an article or page).

The illustration of the Field UI below shows the field instances of the content type, Basic page. There are instances of the fields Title and Body.

An element (i.e., an entity type or bundle) can have only one instance of each field. However, a field can have a setting called "Number of values," which determines how many times a field can appear in an element. For example, if an instance of the field Image is added to the content type Basic page with "Number of values" set to 1, 3, or unlimited, then a page is allowed to have, respectively, only one, or up to three, or an unlimited number of images on it.

The primary (but not all) information about fields and field instances is stored in, respectively, the database tables "field_config" and "field_config_instance". The field type of a field is stored in the column "type" of the table "field_config". (Warning: Don't modify the structure or content of those tables (or any Drupal database tables) unless you know what you're doing. The data in those tables are connected to other data elsewhere, so changes need to be handled by the software.)

The Field UI

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.

The Field UI is a form used for managing fields. It comes up when you click on the Manage Fields tab of an editing form, for example, when editing a content type (such as Basic page) (/admin/structure/types/manage/page) or a taxonomy term (such as Tags) (/admin/structure/taxonomy/tags/edit). It can also be brought up by clicking on "manage fields" in the list of content types (/admin/structure/types).

The following image shows the Field UI as it appears for managing the fields of the content type Basic page:

Managing fields with the Field UI

Managing fields with the Field UI


The Field UI has two parts:

  • A list of field instances of the element being edited (e.g. Basic page or Tags). In the above image, the field instances are Title and Body.
  • A pair of subforms for adding new field instances. These subforms are:
    • Add new field. This is used to both create a new field and to add an instance of that field to the element being edited.
    • Add existing field. This is used to add an instance of a field that already exists.

To add images or tags to a page, you use "Add existing field" because when Drupal is first installed, it predefines the fields Image and Tags.


Planning fields

There are several decisions you will need to make before defining 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 entered 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, check boxes, 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 after inputting/entering data, 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.

There is one main reason to not reuse a field: different permissions. For example, you may need different user roles to have different levels of access to a field, depending on the content type to which it has been added. This can be difficult if you reuse a 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.

Remove field

If you need to remove a field completely one would delete it from all existing content types where it exists. The Field UI can tell you what content types a field is being used on before you try and delete the field.

However, some modules create fields automatically and must be uninstalled to have their fields removed. After you disable the module, you'll have to go to the uninstall tab to complete the uninstall process.

The fields you want to delete should be deleted when cron runs, however, some people have reported that multiple cron runs are needed for the field to fully deleted depending on how much data or how many fields are being deleted at one time. Run cron several times, if your field isn't deleted right away.

A better way to do this is run these two functions:

field_purge_batch(); // note: only run this if you need the field deleted immediately!! otherwise it will just be deleted the next time the cron runs

If you manually delete fields from the database, many things can go wrong. For example, hook_field_delete will not be called and one of your modules might fail and crash the site. For this reason, it is best to only use the Field UI for deleting fields if you aren't comfortable in the code or with SQL/databases.


Drupal 7

The Fields module was incorporated into Drupal 7. Unlike 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.

Looking for support? Visit the forums, or join #drupal-support in IRC.


sxs551’s picture

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?

rwilson0429’s picture

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.


sebish’s picture

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 ?

gilbertdelyon’s picture

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.

heather’s picture

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:

Performance Issues

CCK (or Field API in Drupal 7) adds extra complexity to a Drupal system. When creating a new field, the field’s definition is added to the field class table and the field’s configuration is added to the field instance table; meanwhile, a new table is added to the Drupal database to store the field data. Database tables add complexity to the system. In addition, queries of nodes will incur JOIN expressions of tables to field data. Multiple JOINs will impact database performance since MySQL responds poorly to queries with multiple JOINs of tables if not properly configured.

Reuse of fields can reduce the number of tables in the Drupal database. For example, if 10 image fields, field_image_a, field_image_b, …, field_image_j, are added to the system, 10 tables are added to the database. If a single content type only utilizes two image fields, one thumbnail and one image, we can redefine the fields as field_image_thumbnail and field_image. Only two tables are introduced to the database with the latter configuration.

Reuse of fields can also reduce the system’s complexity. Instead of creating and maintaining 10 different fields, Drupal admins maintain only two fields and their documentation. Database administrators only need to improve performance of two extra tables. KISS is always a good principle.

sebish’s picture

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.

XaviGracia’s picture

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 !!! :-)

ntrepid8’s picture

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?

AlanQ’s picture

Fields on content items are defined at the content-type level

Fields on taxonomy terms are defined at the taxonomy vocabulary level

Fields on user accounts are defined on a site-wide basis

Fields on comments are defined at the content-type level

So how do these different levels of definition affect the fields and the entities upon which they are defined?
In other words, what is the relevance of them being defined at the content-type level or at the taxonomy vocabulary level, etc.?

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.

If I use the same field on a content type and on, for example, a taxonomy term, does the same apply?

heather’s picture

For the first step of creating a view, you must select the base table. The base table being nodes (content), users, taxonomy, etc. And you can't change that choice later. Best way is to try it out yourself, and then it will make sense, if my sentence above doesn't clarify.

sk.drupal’s picture

I have a checkbox field and in Manage Display, I have format options of default or key. What is "key"?

afinnarn’s picture

I think you are referring to key/value pairs. The key is essentially the label for the value it contains. For instance you could have an array with [0 => 'one', 1 => 'two', 3 => 'three'] where the ordinal numbers "0,1,2" are the keys and "one, two, three" are the values. For checkboxes, it's asking whether you want to display the label/key to the user or the value. When you define the field, you will put in keys and values separated by the pipe symbol, e.g. "0|one". Selecting default will display "one" beside the checkbox, and selecting key will display "0" next to the checkbox.

999csharp’s picture

Great article; I learn't a lot from it.

However I think the last section/sentence should be re-written especially where it says :-
If you manually start deleting fields from the db, then all sorts of things can go wrong. For example, hook_field_delete will not be called and one of your modules might explode.

I'm new to Drupal and find it very worrying that my modules might stop working because I had deleted a field.

Kind Regards

afinnarn’s picture

I added a sentence to that paragraph in hopes of helping clarify. The original author meant manually going into the database, usually MySQL, and deleting the field tables there. They didn't mean manually deleting them through the Field UI.

Does that clarify things for you? Since this page is marked as novice, I wonder if the code snippet should even be in there as it might be confusing to the target audience.

campbdy’s picture


I have multiple fields in a content type that I would like to populate using a single taxonomy. Is there an issue (performance wise or other) in drawing from the same vocabulary to populate multiple fields?


aswani’s picture

Hi team,
In Dru-pal is there any way to share content to specific users in a particular group.If any one know please tell me.

afinnarn’s picture

You should look at the OG, original gangsta, module: Any further questions you have should be asked on Stackoverflow and properly tagged if they are about how to use, or if you find a bug/issue, then you should file it in the OG drupal issue queue.

Alternatively, you could create different user roles with different permissions per field, but I think OG module is a better more robust solution.

i850’s picture

field_purge_batch(); // note: only run this if you need the field deleted immediately!! otherwise it will just be deleted the next time the cron runs

which file the code should be placed in? thanx

JakeRogers’s picture

Wouldn't it be nice if some developer would simply modify the core Field module to include an attribute specifying whether or not the content of that field had to be "Unique" or not. That's all it takes for ALL the databases I've ever worked with. This should be a much simpler matter than developing all the bug ridden modules we have here to 2 bits!