Configuration entity fields

Configuration entities have relatively simple fields, due to their storage handling. We can store complex configuration but there is no complex database schema to reflect that. Instead, we have the configuration schema layer that describes configuration entities so the Entity API can understand the types of data they store and represent. We talked about this earlier in the chapter when we looked at the configuration system. But let's examine the NodeType configuration entity type to better understand its fields.

The fields on configuration entities are essentially declared as class properties. So, we can see that NodeType has fields such as $description, $help and others. As I mentioned a bit earlier, the plugin annotation includes a reference to the class properties that are to be persisted and exported. As you can imagine, a class should be allowed to also have some properties that are not actually field values that need to be exported.

The configuration entity class can also have some specific getter and setter methods for its field, but can also rely on the ConfigEntityBase parent class set() and get() methods for setting and accessing field values. Things are relatively simple to understand.

Now, let's check out the NodeType configuration schema found in node.schema.yml and see what that is all about:

node.type.*:
  type: config_entity
  label: 'Content type'
  mapping:
   name:
     type: label
     label: 'Name'
   type:
     type: string
     label: 'Machine-readable name'
   ....
   new_revision:
     type: boolean
     label: 'Whether a new revision should be created by default'
   ...

This is just a sample of the schema definition without some of the fields because we already know how to read those. However, there are some things that are new though.

We can see the wildcard notation that indicates that this schema should apply to all configuration items that start with that prefix. So, essentially, to all entities of a certain type. In this case, the entity type name is type, as denoted in the NodeType annotation config_prefix property. Of course, the namespace is prefixed by the module name.

Next, we see that the type is config_entity, which is the other major complex type besides config_object used to denote simple configuration. These are basically extensions of the mapping type with some extra information. In the case of configuration entities, these are the definitions for the fields that automatically get exported—uuid, langcode, status, dependencies and third_party_settings. That is to say, these fields exist on all configuration entities of any type and are always persisted/exported.

Lastly, we have the schema definitions for each individual field, such as name, type, and more. So, now the system knows that the new_revision field should be treated as a Boolean, or that the name field is translatable (since it is of a type label that extends the simple string type with the translation flag on).

So, as you can see, the field matrix of a configuration entity type is not so complex to understand. Content entities are much more complex and we will talk about those next.