What are configuration entities used for?

Question

I’m trying to wrap my head around D8 Configuration Entities (CFE). The concept of a Content Entity (CTE) seems easy – if you want an application that keeps the information for a CD music collection you can build a content entity that creates a table and stores the fields of your CDs (e.g. Artist and Title).

What is a CFE is used for? When the CFE example in the “examples” module is installed the result is a link to a page that shows a table that contains one default “robot” (Marvin) and a button to "Add A Robot". How is this different from creating a robot entity via a CTE?

I do appreciate that there is a structural database difference. The data for each robot gets stored in the config table.

Answer 1

I would like to add some additional general thoughts on the differences…

Content entities are generally external facing, meaning your site viewers will interact with your content – ie. they will read your pages & articles; they will look at your images, they will browse thru your product catalog, they will post comments and reviews, etc.

Config entities are generally internal facing, normally only site administrators & content editors interact with a config entity such as setting up a new view or adding a block to a page.

There are many, many, instances of content entities – think of a news website and how many hundreds or thousands of articles there are, but there are only a few instances of config entities – with the article, there may just be one content type (content types are config entities) needed for all those articles.

Content entities generally store data in their own database tables and fields though you don’t have to use hook_schema to create them, they are more often instantiated in the class annotations, with yaml files or by using the UI. Config entities can have database fields, but by default they do not. That is not to say they don’t have fields, they do have fields. The content type entity has fields, such as name and description (you just won’t find them in the database as such).

Answer 2

The configuration entity is used to create configuration items. Entities allow you to store more complex configuration structures, which can be listed, edited, deleted, etc., but, above all, can be instantiated multiple times.

Examples of configuration entities include date formats, vocabularies, image styles, roles, menus, views, Pathauto URL patterns, and text formats. All have in common that you can create multiple such elements, and perform other common operations like edit and delete. They also have in common that they are entities that are only managed from the configuration or administration of the site, without exposing them to the end user.

Configuration entities are translatable and can provide default values ​​that will be taken into account during installation. Configuration entities can not have fields.

Content Entity. Content entities are used to create content items. They differ mainly because they have fields. The Manage fields, Manage presentation, etc. options are common in content entities. They are also translatable and, optionally, may have revisions.

Examples of content entities are nodes, comments, taxonomy terms, users, files, custom block types, etc.

A fundamental difference between the two variants is that the configuration entities use the configuration system to store the information, instead of the database, which is the storage used by the content entities.

Answer 3

Configuration entities are useing the entity API in order to keep configuration in the database, not content.

Differences compared to Content Entity

1. Integrates with CMI API for exportability (yml files)
2. No fields
3. Schema file (Content Entity uses hook_schema())

If you create a module that needs to store some configuration per "whatever" (i.e. role), use config entities.

More about this on Drupal.org

Answer 4

Another way to ask and answer this question is "why".

If you look at some contributed modules in Drupal 7, and particularly if you look at their uninstall code, you'll see some pretty ugly stuff getting jammed into the variables table, because this was the easy and default way to store "user" configuration from a module (if you want a random example, try "fivestar").

So if you start thinking about how to handle these "dynamic" kinds of configuration, and you've got this nice "entity" abstraction sitting around, you'll appreciate that it's a great fit - you get stuff like CRUD and listings sort of for free which is typically what you want for this kind of configuration-type thingy.

The hardest part (IMHO) is updating your brain to separate entities from content, which is what entities are often used for. The real key is to understand "user configuration with multiple entries" - that's the thing that is such a nice match to entities and why configuration entities were developed.