Ok perhaps 'ancient' is somewhat of an exaggeration, however the first post on this blog was back in 2013 (where did the time go??). Early engagement with Drupal 8 was a mixed blessing, it is hard to maintain energy for such a time, in late 2013 it seemed just around the corner, however although my investigations have been sporadic I have learned a lot during the evolution.
Now it is finally here though I thought starting 2016 with an upgrade to 8.01 was a good start, having a stable set of APIs makes a huge difference, looking forward to 2016 and some more exciting developments.
One thing you quickly discover chasing D8 through the early days is that commits and changes to the core code would break your site on a daily basis ('chasing head' is not viable), also you can't install interesting modules as they come up as on 'your' site they break everything. I found (via painful trial and error) that for me migrating everything via the database with SQL was the best approach to updating the code base.
I can't be the only person who started blogging early on D8, maybe this option is viable for somebody else. At the very least it highlights an important lesson about abstraction I think.
SQL to the rescue
Once I got past the point where cut and paste to a new Drupal 8 site was a pain (even more so with comments etc.). I found that interacting directly with the database was the least painful option to get things working on new code, a lot of the back-story behind that and a few pointers are to be found at http://running-on-drupal8.co.uk/blog/alpha-to-beta-migration. For the transition to 2016 I just had to migrate from a beta code-base to 8.01 which was a bit simpler and more refined.
My basic strategy was to:
- Make a new empty site
- Configure the site as before (slogan etc.)
- Add modules (Honeypot) that I used before
- Add my theme (took some rework, but that is another story).
- Import the original database into another database (called old).
- Get a mysql command line up and start, comparing/investigating/inserting from old database.
It makes things much easier if the the new site is empty and you can use the same node ids etc.
For example the exact SQL I used this time around to go from a late Beta to 8.01
All 'ancient' Drupal 8 sites will be different (depending on the exact point of time they are stuck in). For somebody confident with SQL it may offer the best hope of migrating content to a shiny new Drupal.
This approach requires familiarity with SQL, I guess my next approach would have been to look at the migration code already being built to migrate D6 to D8 and build something around that, however as stated in the previous original post linked to above I was in need of a break from doing to much D7 migration, I suspect also that although it would be more elegant, that would be too much work for a one-off.
I did briefly look at the Head to Head module but it looked like that would require fiddling and hacking to get it to work, whereas I could roughly judge the effort required via SQL, doesn't seem like it offers anything for truly 'ancient' sites either.
One of the reasons given for the Backdrop fork was the increasing layers of abstraction appearing in Drupal, however really abstractions are the only way to meet the increasingly complex requirements of software and digital services. SQL and interfacing with the database directly is abstracted away in modern CMS/frameworks. When I was first making content management systems however, you were more likely to be writing your own and it all started with designing the database structure and implementing in SQL.
That database layer is still there, in fact the lack of complex foreign key constraints (enforcing data integrity, something delegated to a higher level now) makes it easier to build up a data tables from scratch.
Really it is abstractions all the way down but nice to know that ultimately there it always the database to get access to your data......
Do test however ;)