destroytoday.com

Migrating

In preparation for the big switch from the “2020” subdomain to front-and-center as the root domain, leaving the previous version archived as 2016.destroytoday.com for eternity, one of the last to-dos on my list included migrating content. In the last version of the site, I decided it’d be best to migrate only the content that I still found relevant to the new version, while still keeping the rest of the content accessible and properly redirected from the root domain. For this version, I continued this spring cleaning tradition by only migrating the most recent post about burnout, the article about my dad, and the process write-ups from my client gigs. This helped me keep the new site fresh, while also avoiding days of manually migrating the content from Jekyll to Contentful.

Interestingly, almost every one of these posts introduced a pre-requisite for me to build. The FiftyThree Pencil post forced me to add support for looping and auto-playing video. The Carousel website post made me handle centering videos that were narrower than the article width. And, the Casper homepage post led me to allow wider images and videos that extend beyond the width of the body copy. Honestly, I love this method of building a website—build what’s necessary when necessary.

For video support, Contentful’s flexibility makes authoring really easy and intuitive. I created a content model that has a reference field for multiple video assets. This lets me include both .mp4 and .ogv files. Then, in the renderer, I loop through the field, and insert source tags for each one. I also provided toggles for autoplaying and looping, which simply append those attributes to the video tag. Autoplaying required an additional playsinline attribute for mobile—otherwise, each video goes fullscreen all at once, which is at first confusing, then hilarious.

As part of the migration, I decided to simplify the feed by housing all the posts in the /blog path, instead of /journal, or my previous (and incredibly embarrassing attempt at being unique) path... /writings. Since the migrated posts are more substantial “articles” than these short-form process posts, I’ll most likely add tags to differentiate them at some point, but I’m not there yet. With this path change, I needed to set up redirects from /writings/* and /journal/* to /blog/$1. I accomplished this by using the @nuxtjs/redirect-module package. For redirecting carried-over content, I simply used a single regular expression, but for content I wasn’t carrying over, I needed to set up individual mappings to the previous “2016” subdomain. This was actually pretty easy in JavaScript by map’ing through an array of slugs:

{
  redirect: [
    ...[
      '2015-recap',
      'in-2015',
      'washing-the-dishes',
      'gif-workflow',
      'redesigning-with-rules',
      'lessons-learned-in-a-year-on-my-own',
    ].map((slug) => ({ from: `^/writings/${slug}`, to: `http://2016.destroytoday.com/writings/${slug}` })),
  ]
}

Now, with the redirecting behind me, I simply needed to set the DNS to point to Zeit Now. Surprisingly, this wasn’t as seamless as I expected. For one, hosting a root domain required a DNS provider that supported ANAME or ALIAS, which my AWS Route 53 does not. Even if it did, Zeit mentions that their CDN would most likely be disabled by choosing this approach—not great. The recommended approach is to migrate my DNS to Zeit. This wasn’t ideal, but I really like everything else about Zeit, so I bit my tongue and moved my DNS over.

Before spending an hour manually writing out each DNS setting, I googled and found this handy CLI for exporting AWS Route 53 zones to a file that Zeit could import. I simply needed to run cli53 export destroytoday.com > zone.txt, then import it to Zeit with now dns import destroytoday.com zone.txt. In between, I did need to adjust AWS’s seemingly proprietary settings for aliases to standard CNAMEs, but besides that, everything moved over successfully, except for one last gotcha.

Despite creating the domain in Zeit, switching the DNS, and successfully showing a correct configuration, the site temporarily showed an error saying there wasn’t a deploy tied to the domain. Zeit did say that there would be one created in a matter of seconds, but that never happened, so I had to manually trigger another deploy. Not a big deal, but not as seamless as I expected.

So, that’s it. The new site is on the root domain, and the previous site has been archived to 2016.destroytoday.com. At this rate, I’ll have to do this all over again in 2024.