Frequently, there may be parts of a migration configuration which shouldn’t be hard-coded into your YAML file - some configuration may need to be changed periodically, some may vary according to environment (for example, a dev environment may access a dev or test API endpoint, while prod needs to access a production endpoint), or you may need a password or other credentials to access a secure endpoint (or for a database source which you can’t put into settings.php). You may also need to upload a data file for input into your migration.
Return to action
Those of you with an interest in Drupal migration may have noticed my absence in the last several months. A confluence of things led me to take a break from the Drupal community: a bout of physical exhaustion (initially diagnosed as Lyme disease, and then ¯\_(ツ)_/¯); professional exhaustion managing the D8 migration core initiative and maintaining a few contrib modules on top of paid contracts; and emotional exhaustion from the community drama of early last year.
I did make one comment on Dries’ blog in the immediate aftermath of learning about the situation which is roiling the Drupal community, but since then have taken some time to listen and ponder. The community is in deep pain now, and many of us are reacting to that pain with anger. Trust is in short supply. Healing seems nearly impossible.
MidCamp is imminent, and I'm proud to announce that Virtuoso Performance (i.e., me!) is sponsoring a "Drupal Expert Is In" session Saturday April 1 at 1pm. I'll be in the main room (120) to answer your Drupal 8 migration questions, help you get through any tricky plugin issues, and demonstrate how to approach migration problems.
I’m running a bit behind, but I want to make it a practice to blog about each migration project I’m involved with (with each client’s permission, of course). Constructed examples are all well and good, but there’s nothing like real-world scenarios to give the flavor of using the migration framework in practice.
So, last week the next arena for me to work on came up as XML/JSON source plugins (see my companion piece for more on that). My intention had been to hold off tackling wordpress_migrate until "nailing down" the XML parser plugin it depends on, but I decided that at least trying to prototype a WordPress migration would be a good test of the XML plugin.
As I wrote in my last blog post, I'd like to try doing regular sprint days for Drupal 8 migration. These will be a bit more informal than than a conference sprint - basically, a day when anyone interested in helping move the migration system from its experimental status to a fully supported subsystem of Drupal core can show up in #drupal-migrate, or just pick a relevant issue and start working on it.