Drupal 8 Migration
I have resisted migrating this site to Drupal 8 for years. Every time I looked into it there was some killer feature that D8 couldn’t do. The times I attempted testing out the process it was always a complete disaster. Well, time is running out on Drupal 7. The old system is slated for end-of-life in 2020 and it’s now or never for the “upgrade.”
In this post I am going to recap my experience in migrating a fairly simple Drupal 7 site to Drupal 8. Hopefully, someone facing the same issues as me will come across this post and will find something helpful.
Long story short, the migration process sucks bad. If you don’t have a little experience with directly manipulating a database or troubleshooting software in general, don’t even attempt it.
I am not a command-line guy. This was going to be a drush-free migration.The whole push in Web development towards command-line apps for everything has been one of the worst things to happen to the Internet. It is virtually impossible for a beginner to just jump in and start creating content. Developers have made huge strides in interface usability and yet the tools to create those interfaces are nightmares of horrible UI design puzzle-boxes that exist mostly as job security for entrenched Web devs. Thank Shatner for the few out there like Prepros.io who are at least trying to make new technologies user friendly.
The first hurdle for me was finding a decent local development environment that could handle Drupal 8. My old standby, Xampp, has become garbage in recent versions with no 64-bit support and no interface improvements. I found Wampserver64 and it has turned out to be fantastic. Most importantly, it allows me to run two different local domains, which is required as the migration process works by sucking an old site into a new one rather than overwriting an exiting Drupal 7 install.
After setting up a clean Drupal 8 install with all the migration modules installed I set about creating a plan of attack. Oh, as an aside, whatever you do, do not install the Migration Example modules. It will fill your new site with a bunch of garbage content and fields that don’t get removed when you uninstall the module. My first order of business was to determine which I my D7 modules had D8 versions. A spreadsheet and lots of notes proved helpful. I tried to limit only the most integral modules and skip any ones that are just cosmetic. A lot of popular modules have been added into the core, but in many case they are watered down versions (Menu Block stands out as particularly bad).
Migration Begins
At that point I clicked all the buttons, watched and waited. It looked like most of the content came over but there are big problems with text-filters. If they don’t match with the new D8 filters, the content won’t render. That is really dumb. I had to log in too phpMyAdmin to manually change values. The next big problem was that my post were peppered with strange characters. This had to do with my Sql server not having correct character encoding. This article explains the fix you should do before migrating (I had to search and replace for hours because I failed to do this). Basically, add the following to mysql.ini:
[client]
default-character-set = utf8mb4
[mysql]
default-character-set = utf8mb4
[mysqld]
character_set_server=utf8mb4
collation_server=utf8mb4_unicode_ciComments
The next big problem were comments. Only the most recent comments were rendering and I couldn’t see any difference between those and the bad ones. There appeared to be two tables for comments in the database: comment_field_data and comment__comment_body. Turns out if the langcode column doesn’t match between these two tables, the comments don’t render. More stupidity. Had to manually add “en” to the fields. Thankfully this site doesn’t have that many comments.
Page Caching and Dev Environment
The next step was setting up the local.settings.php to disable caching and render theming helper code. A couple YouTube videos explained this pretty well, although I still am having to flush the cache to see changes half the time.
Views, Oh God Views
Views is a fantastic module. It’s the reason we all use Drupal in the first place. So, why the holy hell aren’t views migrated by default?! So freaking annoying! I had to recreate about 15 custom views manually in order to get many of the site features back. Don’t delete that Drupal 7 site yet. You will definitely need it for reference.
Turning on the Modules
I then started installing and enabling various modules. Like I said earlier, things are different here in Drupal 8. Menu_Block is missing features, Menu_Position is just plain broken (a fix is in the works), Redirect is flaky and throws errors.
Everything to do with CKEditor is horrible. TinyMCE was orders of magnitude better. More robust, more advanced features, better looking, better integration with Drupal… sigh. I have a feeling I am going to be using code view a lot with CKEditor.
Pages of Fun Theme Redux
If there is one area where Drupal 8 is leaps and bounds better than D7 it’s the new Twig-based theming system. The syntax is far less cryptic. A simple {{ content.field_myfield }} renders a field. Perfect. My theme is far simpler than before, yet looks pretty good. Lots of fancy CSS layout tricks here that probably fail in Internet Explorer.
Launching the Site
So, after about two weeks of poking at it, I finally launched the site on December 19th. Within about 30 minutes I got my first spam comment. I do miss Mollum. I’ve tracked down a few anti-spam modules, but it’s going to be tough. I gave up on comments on the Nonagon.us site long ago and this may be a losing battle. Out of my cold dead hands Russian bot farms!
And here we are, a couple days in and things seem to me working okay. I’m sure I will need to upload fixes very soon. There are always sections of the site I miss. And when my first round of analytic come in I may need to start hunting down broken links. In the meantime, click around and enjoy. (And buy my art!)