After understanding the difference between nodes and content types, let’s learn a new concept. Fields are Drupal’s atomic data storage mechanism. They allow you to save discrete pieces of information which can be used for displaying, filtering, and sorting purposes.. Fields can be attached to nodes, users, taxonomy terms, blocks, and other Drupal entities. It is possible to share a field among bundles of the same entity. For example, you can share an image field among different content types (bundles) of the content (node) entity.
There are different types of fields like text, number, email, telephone, references to other pieces of content (nodes, users, taxonomy terms, etc), addresses, files, images, and much more. They are provided by modules so you need to have the proper one enabled for the field type to be available for use. For instance, Drupal core provides a field to store phone numbers, but you need to manually enable the ‘telephone’ module to use it. Other fields, like one to store addresses, are provided by contributed modules. Let’s see some of the benefits of using fields with a use case.
Example use case
Let’s imagine a successful car dealer business with over 1000 vehicles in stock. The marketing plan for next year includes having, for the first time, an online presence. As part of their online strategy, they will create social media profiles and a website. For each car in store they will create a post in their social media accounts with details about the car. For the website they will use Drupal and create a content type called ‘Car’. Throughout the example we will add fields to this content type to store attributes about the vehicles.
Making content easy to find
As you can imagine, it is of utmost important for the business that potential clients find what vehicles are in store. For now, let’s consider a client landing in social media profile looking for a 2010 red Toyota Yaris. Although social media sites provide search capabilities, it would be really hard to find the car even if it existed. The problem is that the content on these platforms lacks structure. The search will return anything containing the keywords used for searching. There is no drill down functionality. Even worse, things that are not cars could be part of the search results. For example, events that were held in 2010 or news about Toyota’s latest technology innovations.
Fields solve this issue by storing specific attributes about the car separately and consistently. That is, you will have one Drupal field for each piece of information that you want to make searchable. In our example, that would be four fields: year, color, make, and model. You can extend this as needed. Other possible fields would be type of fuel, type of transmission, number of doors, etc. When you store data this way, you can use other tools provided by Drupal to make the content searchable. For instance, you can create a view with exposed filters.
When creating fields, it is key to select the proper field type to provide the consistency needed. For example, you can use lists or term references for the color, make, and model fields. This will prevent having two entries that represent the same thing. Think of “light blue” and “sky blue” as representing the same color. Also, you will avoid introducing spelling mistakes like “maseratti” instead of the correct one “maserati”. For the year field, you could follow the same approach or use an integer field instead. The thing to keep in mind is that an integer field can allow inconsistent or invalid data to be entered. A user can enter “20010” or “97” instead of “1997” for the year field. Of course, this could be mitigated by setting minimum and maximum values in the field configuration. Since we do not need to perform mathematical operations on the year value like averages using either lists or term references is valid in this case.
Keeping data consistent
Social media posts and Drupal’s “body” field are like a white canvas. People can write poems, upload images of their later art projects, and generally enter whatever they want. All this freedom is usually accompanied by data inconsistency. When given the option, editors will take shortcuts when creating content. Let’s see a simple example with dates:
- July 2, 2017
- July 2, 17
- 07/02/17
- 07-02-17
- 02-07-17
These and many others are possible values that a content editor can use. Let’s imagine that in the car dealer business we need to keep track of when the cars were added to the inventory to measure how fast they are sold. This key information can become difficult to extract if there are inconsistencies in how the data was entered. The person responsible for generating the report will have to spend more time homogenizing the inconsistencies thus making the process inefficient. Even worse, for a case like 07-02-17, does it refer to July 2 or Fabruary 7? The point is, we need to be more restrictive in the way we collect the information.
Drupal fields shine in preventing inconsistent data. You can enforce a specific format to be used. For example, you can configure the date field to be entered in month/day/4-digit-year format (e.g. 12/31/1999). Additionally, you can provide a pop up calendar making entering process a matter of clicking (to choose the proper date) instead of typing. For a date field, you would configure this in the “Manage form display” tab of the content type configuration.
Technical note: Fields not only enforce visual consistency. They also keep consistency at the data storage (database) level. This is important because it allows performing data processing, filtering, and ordering operations over the data we collect.
Preventing invalid data
In social media or Drupal’s “body” field is virtually impossible to enforce validation rules in the data entered. Let’s see the following examples:
- Age: -10 years old (negative age)
- Price: E10 dollars (wrong currency symbol)
- Date: February 31, 2000
- Email address: almostrealemail.com (missing @ symbol)
- Telephone number: I am beautiful 😀 (not even a number)
Fields make enforcing validation criteria super easy. The first line of defense is selecting the proper field type. By doing this, Drupal will perform some sensible checks like requiring an at sign (@) to be present in an email address. But there is more! Setting a field as required will prevent nodes to be created if the field were left empty. For number fields you can define minimum and maximum like the range from 1970 to 1979 in the year field to allow cars manufactured in the 70s only. For number fields as well you can set prefixes and suffixes like $ and “dollars” for the price field, respectively. Image fields can set restrictions on allowed file extensions, minimum and maximum resolution, and maximum file sizes. Different field types will offer different validation criteria. Make sure to use the right field type for the data you want to collect.
The new marketing plan of the car dealer business includes hosting events in different locations where the luxury cars are exhibited. Phase two of the website project calls for the addition of an interactive map that displays all the locations where future events will be hosted. Drupal fields are so flexible that they allow the information to be collected in different formats. Using the example just described we could have field that permits the event location to be collected in different ways:
- An address. Eg: 123 Cellar St.
- A latitude-longitude pair. Eg: 12.136389, -86.251389
- A map that the user could click on to select the venue.
- A file upload widget that allows KML files (this type of files store geographical information).
Note: there is no single Drupal field that allows these four types of inputs for location data, but it is possible to create it.
Similarly to accepting multiple inputs, a field can also present its data in multiple ways. For example, the content creator can enter the location as an address, but it is presented on a map. In fact, once the data is collected you can aggregate it and present the results. That is, we could have a single map that shows multiple markers, one for each event. A great example of location data aggregation is drupical.com This website collects information about Drupal events happening all over the world and shows then in an interactive map. Note that pointers on the map are color coded. To do that, a color is assigned to the field that stores the event type and this color is later used for the marker. Yes, it is possible to combine data from different fields into a single presentation.
Visibility control
Enforcing visibility controls is another example of fields’ versatility. It is possible to show and hide content from a node on a field basis. Let’s consider the following policy of the car dealer business: “To recognize employees loyalty, anyone who has worked for the organization for at least 3 years will receive a 20% discount.” To accommodate for this, we will create two price fields: “Price” and “Discounted price.” The discounted price should be hidden from everyone except for the employees who match the specified criteria. Therefore, we could set “Discounted price” field hidden by default and show it depending on the role of the user viewing the car. The regular price will follow the reverse logic.
Versatility at your disposal
Fields are the heart of Drupal content modeling system. Use them properly to provide a rich user experience. Content editors can enter valid and consistent data and website visitors can find the information they need.
Did you know that Drupal fields were so versatile, flexible, and powerful? Can you think of other use cases for the information covered? Do you have more tips regarding the use of fields in Drupal you would like to share?
