For large projects in particular, it is not feasible to wait for all the site
configuration to be completed before content migrations begin. In cases like
this, it is common to have a group of developers building the site’s
configuration. As configuration is added to the site, another group of
developers start working on migrating the content. Communication is key
during this process. If changes are introduced to the content model,
the migrations need to be updated accordingly.
Note: some entities, like users and files, do not allow bundles by default. Contributed modules can change this behavior. For example, the User bundle module allows bundles to be associated with users. For reference, the table below lists some content entities with a subset of their entity properties and lists whether they are fieldable and allow bundles.
drush php:eval
"print_r(array_keys(Drupal::service('entity_field.manager')->getBaseFieldDefinitions('node')));"
Series Overview & ToC | Previous Article | Next Article – coming June 6th
The main reason for this is that each content type has a different set of fields. If multiple bundles of the same entity do not have fields, they can share a migration. For example, all taxonomy terms that belong to vocabularies without fields attached to them can share a migration.
Configuration entities are managed by the
Configuration API. This will become important to understand when we work on
migrating configuration. In a nutshell, Drupal’s active configuration is
stored in the database, namely the config table. For version
control and deployment, configuration is exported to and imported from
YAML files. This can be done via the
administrative interface or using
Drush configuration commands.
Configuration entities are managed by the
Configuration API. This will become important to understand when we work on
migrating configuration. In a nutshell, Drupal’s active configuration is
stored in the database, namely the config table. For version
control and deployment, configuration is exported to and imported from
YAML files. This can be done via the
administrative interface or using
Drush configuration commands.
Configuration Entities
In the contributed modules space we have:
The following Drush command will show the properties for the node entity:
Drupal
10 configuration entities define the site structure. Some configuration
entities included in Drupal core are:
As part of Drupal commerce, some of the available configuration entities are:
As we discussed in the first
article, there are multiple migration strategies. An automated migration of
configuration is optional. If not done automatically using the Migrate API, the
configuration will have to be created manually. This is often the case when the
site structure is going to be significantly different between the Drupal 7 and
Drupal 10 sites.
Entity Table
| Entity type | Entity properties (base field definitions) | Fieldable? | Allows bundles? |
|---|---|---|---|
| Node | nid, vid, langcode, type, status, uid, title, created | Yes | Yes – content type |
| Term | tid, langcode, vid, status, name, description, weight, parent | Yes | Yes – vocabulary |
| Media | mid, vid, langcode, bundle, status, uid, name, thumbnail | Yes | Yes – media type |
| BlockContent | id, langcode, type, status, info | Yes | Yes – custom block type |
| Comment | cid, langcode, comment_type, status, uid, pid, subject, name | Yes | Yes – comment type |
| User | uid, langcode, name, pass, mail, timezone, status, roles | Yes | No, out of the box. Yes, with User bundle module. |
| File | fid, langcode, uid, filename, uri, filemime, filesize, status | No | No |
From a migration standpoint, having a clear understanding of the content model of the source and destination sites is key. We will also observe that a migration project consists of multiple individual migrations. Each migration should only create one type of entity. That is, a single migration should not create nodes and users at the same time. While not strictly necessary, it is common to have a single migration for each entity bundle. For instance, in the case of nodes, we would have one migration for basic pages and a different one for articles.
Each content entity has a set of properties, known as
base field definitions, to hold data. For instance, the node entity has the
nid property to store the node id, vid to store the
revision id, type to store the node type it belongs to,
status to indicate whether the node is published or not,
uid to store a reference to the user who created the node, and
title to store the node’s title. Note that while some property
names might be the same across entities, they can be used to store different
information. For example, in the case of the taxonomy term entity, the
vid property stores the vocabulary the term belongs to. And in the
user entity, the status property indicates whether a user account
is active or blocked.
In the contributed modules space we also have:
Content Entities
Image by Petr from Pixabay
