In today’s article we are going to provide a reference of all configuration options that can be set in migration definition files. Additional configuration options available for migrations defined as configuration will also be listed. Finally, we present the configuration options for migrations groups.
In the previous article we provided a reference of available configuration options for migrate source plugins. In today’s article we are doing something similar for destination plugins. We will present a reference of available configuration options for migrate destination plugins provided by Drupal core and some contributed modules. Knowing which options are available might require some Drupal development knowledge. By providing this reference it should make the process of writing migrations easier.
In a previous article we explained the syntax used to write Drupal migration. We also provided references of subfields and content entities’ properties including those provided by the Commerce module. This time we are going to list the configuration options of many migrate source plugins. For example, when importing from a JSON file you need to specify which data fetcher and parser to use. In the case of CSV migrations, the source plugin configuration changes depending on the presence of a headers row. Finding out which options are available might require some Drupal development knowledge. To make the process easier, in today’s article we are presenting a reference of available configuration options for migrate source plugins provided by Drupal core and some contributed modules.
In a previous article we presented a list of properties per content entity in Drupal core and some contributed modules. This time we will provide a similar list for Drupal Commerce. When migrating into content entities, these define several properties that can be included in the `process` section to populate their values. For example, when importing Drupal Commerce product variations you can specify the SKU, price, list price, etc. In the case of promotions, you can set the start and end dates. Finding out which properties are available for an entity might require some Drupal development knowledge. To make the process easier, in today’s article we are presenting a reference of properties available in content entities provided by Drupal Commerce and some related contributed modules.
In a previous article we explained the syntax used to write Drupal migrations. When migrating into content entities, these define several properties that can be included in the `process` section to populate their values. For example, when importing nodes you can specify the title, publication status, creation date, etc. In the case of users, you can set the username, password, timezone, etc. Finding out which properties are available for an entity might require some Drupal development knowledge. To make the process easier, in today’s article we are presenting a reference of properties available in content entities provided by Drupal core and some contributed modules.
In the previous article we explained the syntax used to write Drupal migrations. As part of the field mapping explanation, we talked about how to set subfields. This is a topic we have covered early in the 31 days of Drupal migrations series. On both occasions, we mentioned that finding out which subfields are available for a field type might require some Drupal development knowledge. To make the process easier, in today’s article we are presenting a reference of subfields provided by core and contributed modules.
es we explained different aspects of the syntax used by the Migrate API. In today’s article, we are going to dive deeper to understand how the API interprets our migration definition files. We will explain how to configure process plugins and set subfields and deltas for multi-value field migrations. We will also talk about process plugin chains, source constants, pseudofields, and the process pipeline. After reading this article, you will better comprehend existing migration definition files and improve your own. Let’s get started.
In Drupal, a view is a listing of information. It can a list of nodes, users, comments, taxonomy terms, files, etc. A view scans your website using any criteria you specify and presents the results in the format of your choice. Example formats include a HTML table, a RSS feed, a PDF document, a CSV document, an interactive map, an image slideshow, or a JSON representation to be used as a REST endpoint. The same content can be presented in multiple formats at the same time. For instance, you can present a table of user information and on the same page a link to download the data in CSV format.
We have already talked about nodes, content types, and fields. In Drupal, they often comprise the main content of a page. Very likely you will want to display extra information along the page. This can be accomplished using containers called blocks. For example, the main content of a page can be a news article and a block can be used to display a list of other articles written by the same author. You could also use a block to show a search box or copyright text. Let’s explore what Drupal blocks have to offer.
After understanding the difference between nodes and content types, let’s learn a new concept. Fields are Drupal’s atomic data storage mechanism. They allow you to save discrete pieces of information which can be used for displaying, filtering, and sorting purposes.. Fields can be attached to nodes, users, taxonomy terms, blocks, and other Drupal entities. It is possible to share a field among bundles of the same entity. For example, you can share an image field among different content types (bundles) of the content (node) entity.
