Skip to main content

Content vs. Configuration

In Drupal, content is defined as "Information meant to be displayed on your site, and edited by users: article, basic page, images, files, etc.". Configuration, on the other hand, is defined as "Information about your site that is not content and changes infrequently, such as the name of your site, the content types and views you have defined, etc.".

A simple analogy is that of a contractor building a house. They must raises walls, set windows, and lay floors. Contractor's don't care about the color of those walls, the type of curtains around those windows, or the type of carpeting on the floor.

An example of configuration.

If you create a node type titled Article with these three fields:

  • Image - an image upload
  • Tags - a taxonomy term reference
  • Body - full text field.

Behind the scenes, the following database tables will be created:

  • field_data_body
  • field_data_field_image
  • field_data_field_tags
  • field_revision_body
  • field_revision_field_image
  • field_revision_field_tags

These tables are considered configuration. The information that is stored within these tables is content. We can export configuration into code and save that within git. This makes the site portable, so, another developer working on the same site can checkout the project with git, and have the same structure in their test database, without any content.

How do we classify content vs. configuration?

Reiterating Drupal:

  • Configuration vs. Content:
    • Think site builder vs. site editor. If a "site editor" role on the site would want to edit the information, it is probably content. If only a "site builder" role would want to have the power to edit the information, then it is probably configuration. But this is not an absolute rule.
    • Think about numbers. If you have a huge number of items, probably it is content. If you will only ever have a few, probably it is configuration.
    • Configuration tends to define "types of things", such as content types, taxonomy vocabularies, etc. Then each "thing" within the type is a piece of content: a content node, a taxonomy term, etc.

How do we export configuration within Drupal 7?

This is where the features module comes into play. Features allows us to bundle configuration into a pre-defined module, that we can just enable on any given site. Using the Article example from above, we can use features to build a 'News' feature that would export the following:

  • The Article content type.
  • The Body field.
  • The Image field.
  • The Tags field.
  • The vocabulary that tags are defined within.
  • The view that displays the news.

Once that information is exported, we save the module Features generated and check the code into git.

Items that are exportable within Drupal 7:

(this list is not exhaustive):

  • views
  • node types
  • field types
  • vocabularies
  • rules
  • feed imports
  • panels
  • variables
  • menus
  • paragraphs
  • image styles
  • enabled modules (dependencies)

Items that are not exportable:

  • actual nodes and their fields (node/1, node/2, etc.)
  • taxonomy terms and their fields (taxonomy/term/1, taxonomy/term/2)
  • custom blocks
  • block regions
  • menu links