Having eventually got my new VM up and running, I ended up down another rabbit hole for a little while. It took me longer than it should have done to figure out that configuration can be included in an installation profile. Having seen an issue on drupal.org, I got the idea into my head that I needed to mess about with the config directory, or use the Configuration installer profile. Thankfully the reality was much simpler.
As is so often the case, the way I figured it out was by looking at the source code of something that did work - in this instance the standard installation profile in core revealed that all the config files should be in the config/install directory. If I find any other confusing or unintuitive things like this, I’ll try to update the documentation on drupal.org, as well as making some notes here.
It feels like a common problem with a lot of code that the documentation isn’t in sync with the code. It’s not just an issue with open source, but given that a lot of developers are reluctant to write documentation when they’re getting paid for it, it’s hardly surprising that there’s a real need for more people to contribute to documentation.
Once that was out of the way I was able to start poking about with the actual migration. I’ve had a little bit of experience with migration in Drupal 6 and 7, although not as much as some of my old colleagues, and the migrate_example module was again helpful for figuring out how it all fits together.
It’s tricky because a lot of the migrations depend on other migrations, and I want to manipulate the data on the way in so that it works with slightly different field names. The tutorial by Cheppers is the most helpful article I’ve found. Here’s the basic workflow that I’ve been using so far:
- Edit settings.php to include the old database connection
- Run migrate-upgrade to get the migrations
- Export the site configuration
- Put the exported migration definitions in to the config/install directory of your custom module
- Tweak the migration definitions:
- Define a migration group:
migration_group: gallthat defines the database source - remove
database_state_key: migrate_upgrade_6from the migrations - Re-install the site using the installation profile
- Check the migration status
drush ms - Run the migrations:
drush mi --all- for The Gallery Guide this takes a long time - Try changing the prepareRow function in the migration class
- Re-run individual migrations to test :
drush mi d6_node__gallery --update
At the moment one of the migrations is choking on a problem in core/lib/Drupal/Core/Utility/LinkGenerator.php:
Error: Unsupported operand types in /var/www/drupalvm/drupal/core/lib/Drupal/Core/Utility/LinkGenerator.php, line 152
<div data-quickedit-field-id="node/511/field_exhib_website/und/search_index" class="field field--name-field-exhib-website field--type-link field--label-hidden field__item">It’s a puzzling one, but at least I’ve got some idea of where to start digging.
This process has reminded me once again of how useful Drush is, and more generally, the value of using the command line, especially for complex or repetitive tasks. I remember when I first started as a developer, being slightly intimidated by the terminal. A bit like the old text adventure games, it can be difficult to know where to start. None of the functionality is made obvious to the beginner.
But once you have a vague idea what you’re doing, you can save so much time. Because the interface doesn’t need to bother making things look pretty, it’s much quicker. You can chain commands and set up shortcuts. All kinds of power is available if you know where to look.