After many, many years of running on various static site platforms, I've relaunched my blog on Drupal 8.
After returning home from vacation in the Virgin Islands, I noticed my site had an old email address in the metadata of the site. For 5 years I never noticed this. It was really annoying to see and even harder to find where it was coming from. So I decided to make the switch.
For a long time, Jekyll + GitHub Pages worked well enough. But, having to use Vim to edit files, editing by hand, not having the ability to create/work 301 redirects, and general lack of overall control of my site wore me down. In fact, one of the reasons I liked being on GitHub Pages for a static blog was to give me practice learning and putting Vim into practice for text editing - it was a great teaching tool and I still use Vim when ssh'd into servers. But when you want to get down and just write some content, it really gets in the way.
Why Drupal instead of (platform/static)?
Nothing else really suits me. I know the platform, I have total control, I can structure things the way I want and experiment with techniques or features and incorporate them into my projects and vice versa.
How did you migrate?
I employed the use of the Migrate API of Drupal, created 3 migrations (articles, tags, redirects) and pointed all of them at my old websites atom.xml feed. The XML file gave me the entire site, and the XML parser of the Migrate module made the move effortless.
Here is the migration for articles, very simple:
id: article label: Articles from my Jekyll based blog. migration_group: content source: plugin: url data_fetcher_plugin: http data_parser_plugin: simple_xml urls: http://kevinquillen.com/atom.xml namespaces: atom: http://www.w3.org/2005/Atom item_selector: //atom:entry fields: - name: id label: 'ID' selector: atom:id - name: title label: 'Title' selector: atom:title - name: published label: 'Published' selector: atom:updated - name: content label: 'Content' selector: atom:content - name: tags label: 'Tags' selector: atom:categories/atom:category ids: id: type: string destination: plugin: entity:node process: type: plugin: default_value default_value: article title: title created: plugin: format_date from_format: 'Y-m-d\TH:i:sP' to_format: 'U' source: published changed: plugin: format_date from_format: 'Y-m-d\TH:i:sP' to_format: 'U' source: published 'body/value': content 'body/format': plugin: default_value default_value: full_html field_tags: - plugin: deepen source: tags - plugin: sub_process process: target_id: plugin: migration_lookup migration: tags source: value
How are you hosting it?
I am using a small Amazon EC2 server and Amazon RDS MySQL database. PHP 7.2 and Memcache. I set the instance up myself. Due to my experiences running all our projects and experiments in Docker containers and general knowledge of Linux, this was not hard to do. I did not go to Acquia, Pantheon or similar managed hosts - the costs are too high for this (~$100-150 a month vs $10), and I wanted total control of my environment.
I am very satisfied with the result.
This was simple. Just like our projects, I set up a private GitLab repo and took advantage of GitLab CI to build the site, run Composer, and deploy that to my Amazon instance automatically. Every merge into the master branch will create a release and deploy it automatically. I love it.
But you're using the Bartik theme!
Yes, I know. Honestly I spent hours looking for themes in various places and nothing suited. I decided to just launch on Bartik - I knew that if I delayed launching when I was so close to the finish line, I would never get it done. Besides, content is king, as long as I can capture the data, I can theme it any way I want when I am ready to do so. I can make those updates over time, and when I know what I want to do, I can create my own theme easily and go from there.