Overview configuration (comparing with other types of information)

Drupal 8 includes several types of information:

• Content

Information intended for display on your site and editable by users: articles, basic pages, images, files, etc.

• Session

Information about individual user interactions with the site, such as their current filter selection in views. This is ephemeral and personalized to one user.

• State

Information that may frequently change and/or without user intervention. Examples: time of the last cron run, whether node access permissions need to be rebuilt, etc.

• Configuration

Information about your site that is not content and doesn't change often, such as your site name, content types, and views that you've defined.

• Cache

Information about your site that is also stored elsewhere. Caches exist only to speed up data retrieval. They never store canonical data.

• Settings

Read-only information for your site, hardcoded in the settings.php file.

Deciding How to Classify Your Information

It's not always clear whether some information your module stores should be classified as content, state, or configuration. Here are some guidelines:

• Configuration vs. State: If your information should be deployed from your development server to your production server, it's probably configuration, not state.
• Configuration vs. Content: Think site builder vs. site editor. If the “site editor” role would want to edit the information, it's probably content. If only the “site builder” role would edit it, it's likely configuration. But this is not an absolute rule.
• Configuration vs. Content: Think about volume. If you will have a large number of items, it's probably content. If you'll only have a few, it may be configuration.
• Configuration vs. Content: Configuration tends to define “types of things,” like content types, taxonomy vocabularies, etc. Each “thing” within a type is then content—like a content node, taxonomy term, etc.

Simple Configuration vs. Configuration Entities

One of the first decisions you'll make when using the configuration system is which type of configuration you'll store.

Simple configuration is slightly easier to implement and is ideal for basic settings like booleans, integers, or plain text strings. A good example is enabling/disabling a module feature or setting the site name. Simple config should include any settings necessary for your module to function correctly. For example, JavaScript aggregation must be either on or off. If it doesn't exist, the system module can't decide what to do. Simple configuration can only depend on the module that provides it. For example, system.site depends only on the System module.

Configuration entities store lists of things that users can create and delete; your code should work whether there are 0 or 100+. Examples: image styles, views, etc. Config entities come with full CRUD hooks, just like other entities in Drupal, making them ideal for configuration that other modules may depend on or react to. For example, Views uses config entities to allow other modules to provide views during runtime. Config entities can have dynamic dependencies. Like simple config, they depend on the module that provides them. For example, views.view.frontpage depends on the Views module, but since it lists nodes, it also depends on the Node module. If later it’s updated to only show Article nodes, it will also depend on the Article config entity (node.type.article), and so on.