Fix type for console docblocks

02.txt

@@ -76,10 +76,10 @@ The repository, which will be used for many examples throughout the book, can be
 
 Let's use Drush to run the migrations with the commands provided by [Migrate Run](https://www.drupal.org/project/migrate_run). Open a terminal, switch directories to Drupal's webroot, and execute the following commands.
 
-```yaml
+```console
-- $ drush pm:enable -y migrate migrate_run ud_migrations_first
+$ drush pm:enable -y migrate migrate_run ud_migrations_first
-- $ drush migrate:status
+$ drush migrate:status
-- $ drush migrate:import udm_first
+$ drush migrate:import udm_first
 ```
 
 **Note**: It is assumed that the Migrate Run module has been downloaded via composer or otherwise.

06.txt

@@ -6,7 +6,7 @@ We have presented several examples so far. They started very simple and have bee
 
 When working on a migration project, it is common to write many migration definition files. Even if you were to have only one, it is very likely that your destination will require many field mappings. Running an _import_ operation to get the data into Drupal is the first step. With so many moving parts, it is easy not to get the expected results on the first try. When that happens, you can run a _rollback_ operation. This instructs the system to revert anything that was introduced when then migration was initially imported. After rolling back, you can make changes to the migration definition file and rebuild Drupal's cache for the system to pick up your changes. Finally, you can do another _import_ operation. Repeat this process until you get the results you expect. The following code snippet shows a basic Drupal migration workflow:
 
-```yaml
+```console
 # 1) Run the migration.
 $ drush migrate:import udm_subfields
 
@@ -34,7 +34,7 @@ Sometimes, you do not get the expected results due to an oversight in setting a
 
 You can check the state of any migration by running the `drush migrate:status` command. Ideally, you want them in `Idle` state. When something fails during import or rollback you would get the `Importing` or `Rolling back` states. To get the migration back to `Idle` you stop the migration and reset its status. The following snippet shows how to do it:
 
-```yaml
+```console
 # 1) Run the migration.
 $ drush migrate:import udm_process_intro
 

08.txt

@@ -89,12 +89,12 @@ The `migration_dependencies` key goes at the root level of the YAML definition f
 
 Now that the dependency among migrations has been explicitly established you have two options. Either import each migration manually in the expected order. Or, import the parent migration using the `--execute-dependencies` flag. When you do that, the system will take care of determining the order in which all migrations need to be imported. The following two snippets will produce the same result for the demo module:
 
-```yaml
+```console
 $ drush migrate:import udm_dependencies_intro_image
 $ drush migrate:import udm_dependencies_intro_node
 ```
 
-```yaml
+```console
 $ drush migrate:import udm_dependencies_intro_node --execute-dependencies
 ```
 
@@ -110,7 +110,7 @@ migration_tags:
   - UD Example
 ```
 
-```yaml
+```console
 $ drush migrate:import --tag='UD Articles,UD Example'
 $ drush migrate:rollback --tag='UD Articles,UD Example'
 ```

21.txt

@@ -38,7 +38,7 @@ When using configuration entities, a single migration is identified by two diffe
 
 If you do not have a UUID in advance for your migration, you can try one of these commands to generate it:
 
-```bash
+```console
 # Use Drupal's UUID service.
 $ drush php:eval "echo \Drupal::service('uuid')->generate() . PHP_EOL;"