I have a Drupal 6 site with three custom content types. We have tried using the Migrate Drupal UI module to migrate these to our new Drupal 8 site, but this resulted in all of the plain text fields being imported as long text fields (field type string_long
when they should be string
).
To fix this, I deleted all content of those types, exported the configuration created by the UI module with drush cex
and used drush cim
to re-import the YAML config files after changing all instances of string_long
to string
.
After about 3 hours of fiddling with this, I finally had a working D8 configuration with the same fields, forms and views as the original D6 site. Now it's time to migrate the content data across.
I have spent another ~6 hours researching and experimenting on how to do this, having tried the views_data_export and Feeds modules, as well as reading several resources on creating custom migration modules.
The former solution was tedious to set up and the default form for creating a feed type wouldn't allow me to create nodes with the original node IDs. So I tried to step through the code and figure out how to extend the module by myself, since the API documentation is severely outdated. This got me nowhere but extremely tired, confused and frustrated, and about 2 hours closer to my eventual demise.
I'm not even game to try the latter solution, since that would probably be just as hard. So now I've started investigating the DB structure in the hope of writing my own SQL update script...only to discover that there are not only node
, node_field_data
, node_revision
and node_field_revision
tables to contend with, but also node__<field_machine_name>
and node_revision__<field_machine_name>
tables for every defined field (35 of them in my case)!
This seriously can't be this hard! Surely I must be missing some crucial piece of documentation from my Google search results. So what would be the easiest method to accomplish what I want?