I volunteered to carry out the migration for the new ComputerMinds site as migration was one of the very few areas of Drupal maintenance support plans that I hadn’t delved into thus far. With Drupal maintenance support plans 8 becoming more and more popular, now was a great opportunity to learn the migration ropes. Luckily, Drupal maintenance support plans 8’s migration has greatly improved since Drupal maintenance support plans 7 so my life was made somewhat a little “easier”!
This article will be aimed at some of my finds and processes, rather than a “How to do a D8 migration”.
Since our new site was very different to our old one in terms of content, we had to be quite choosey in exactly what was needed. We decided that we only really needed the articles; pretty much everything else was a fresh start. We would be manually carrying over users; as that would be too little work to warrant writing a migration for.
In order for us to get our articles over from the old site, we would need to migrate the current taxonomy terms, URL aliases (this would come back to bite me hard!), files and last but not least, the article nodes themselves. Migrating just a node seemed simple enough, but you quickly forget that it is more than just a node. All the stuff attached to the node has to be carried over.
Modules like Migrate plus and Migrate tools are great additions to the migration family and I can highly recommend them; they make life so much easier! Migrate plus “basically” writes the migration for you 🙂
With Migrate plus doing the bulk of the work for me, the only PHP code I needed to write was to map our old User ID’s to the new ones, so original authors would be retained. Otherwise I could take all the credit for every single article ComputerMinds has ever written in the past (mwahah!). This can be easily achieved using a simple process plugin.
/**
* This plugin will tie a piece of content with an existing user.
*
* @migrateProcessPlugin(
* id = “user_id_mapper”
* )
*/
class UserIdMapper extends ProcessPluginBase {
/**
* {@inheritdoc}
*/
public function transform($value, MigrateExecutableInterface $migrate_executable, Row $row, $destination_property) {
$mapping = [
‘oldID’ => ‘newID’,
];
if (!empty($value)) {
$value = $mapping[$value];
}
return $value;
}
}
We had some term reference fields, and like Drupal maintenance support plans 7, Drupal maintenance support plans 8 will reduce your potential workload – it creates taxonomy terms for you if those terms are missing from your new site. Nice and easy.
The biggest remaining hitch was extracting the three components from a body field. These are value, summary and format. Summary and format were fairly straight forward, but attaining the value component was a real pain (the code below will show you otherwise). Straight away you’ll notice inconsistencies with the “keys”. I would have expected the format to have been body/value, body/summary and body/format, but alas this was not the case.
body: body
body/summary:
source: teaser
body/0/format:
plugin: static_map
source: body/0/format
map:
markdown: markdown
full_html: basic_html
filtered_html: restricted_html
This took a few painful hours to debug and figure out, to this day I still do not know why! At least this being documented here can save others some pain and time.
With all migration finished and the site ready to be shipped out, what came apparent is that (as mentioned very briefly earlier) I had not accounted for some URL aliases (I had used a process plugin to pinch only the aliases we needed). I’d assumed, yes assumed (naughty developer), that ALL articles had the SAME URL path auto pattern. Big, big boo boo. What I didn’t know was that some articles on our old side had been migrated from an even older site and these article URLs came in all shapes and sizes; shapes and sizes that do not match our current path auto pattern. I’ve been fixing redirects and 404’s since 🙂
Lesson of the day
Do not ASSUME everything is the same. Do go check everything is how you expect it to be before migrating content.
Source: New feed
