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
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
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_field_revision tables to contend with, but also
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?