Post

Welcome from the Jekyll version of my blog

I was thinking about moving away from WordPress as blogging platform for quite some time but hesitated mainly because of the amount of work this would cause I was afraid of. The recent chaos on the WordPress ecosystem and the nearing renewal of my hosting contract let me have another, more serious look into moving away. This post is for one to inform you that this blog is no longer running on WordPress, but also for me as a documentation of all the bits that helped me to move my blog to Jekyll.

Exporting blog posts from WordPress

This was one of the easiest steps. I just installed the Plugin ‘Jekyll Exporter’, went to the Tools menu in WordPress end let the Plugin do its work. With my about 230 blog posts it didn’t have that much work, and I got a .zip file with all of my blog posts converted to Markdown files, including their image assets in a separate folder structure.

Preparing my Mac

Before you want to commit the whole blog to GitHub, you should run your blog locally. As I am doing all of this stuff on my MacBook Pro, I had to first install quite a bunch of software. I followed the instructions found on these sites:

This way, I was able to get a working Jekyll site up and running in under half an hour. The next thing I wanted to do is selecting a theme (let’s be honest, the default theme is boring).

Choosing a theme

I tried to follow the instructions found on the Jekyll website for changing the theme and also the ones found in the GitHub Pages docs, but neither of them changed my local theme.

So I did some web research and found the new theme of my blog: Chirpy. I followed the maintainer’s recommendation and started over from the starter template. The starter template did all the heavy lifting on the GitHub site of things and deployed the blank template in just a few clicks. So the new base was ready to be cloned on my computer to work on it.

I did exactly that - and as I had Jekyll already running before, I was just running

1
bundle exec jekyll s

away from getting a local copy to run in my browser.

Copying stuff from the export

Now that everything was working as I expected it, I started to copy the data from my WordPress export I created earlier, starting with the posts folder. After that, I had to create the img folder inside the assets folder and copy over also all the images.

I then ran the site locally again - and saw all the mess created by the several WordPress plugins I used during the years since 2011. Even worse - the images of all of the blog posts were still pointing to my blog’s address. No way I was able to publish my blog this way!

Cleaning up my old posts

Luckily I have Visual Studio Code installed. I was able to replace all the absolute image urls with relative ones within minutes. Then I deleted all the duplicate images WordPress created for other sizes from the image folder. Of course, I needed to update all blog posts again, so I went through all of my blog posts again.

I recommend to install the Doc Writer Profile in Visual Studio Code to help during that process.

While correcting the image urls, I already saw that the code snippets weren’t highlighted correctly. This meant another round of going through my posts to set the language of the code snippets.

But that wasn’t even enough. I still needed to strip out some garbage leftovers from Bitly, the SEO Plugin I used and some other messy HTML code. After a week and several rants on my social media (doing all of this in my spare time), I finally had everything cleaned up.

Releasing it into the wild

Now the time had come to publish the blog out into the wild. But the GitHub Action still found some errors I needed to address (zipped source code I linked in the first days of my blogging career for example). But these were easy fixes, as the build process outlined the files I needed to touch. After another hour or so, I finally had my blog running on GitHub.

Getting comments back into my blog

Before I made the final cut to the WordPress wires, I needed to get the comments over to my new Jekyll site. I decided to go with Disqus, as they can easily import the comments from a WordPress xml-Export. So I used the default export option of WordPress and downloaded a full xml backup of my blog as well.

Do not connect your Disqus site with your WordPress site, otherwise you will have to repeat the whole process to get it working on your Jekyll site!

Once I had that export, I just needed to get to the Disqus Importer site, upload my xml export, and wait for the comments to be imported. After that, I just had to activate the Disqus section and add my site name within the template to make the comments show up on my blog again.

Domain mapping

GitHub makes it pretty easy to use your own, custom domain for GitHub Pages. Verifying is as easy as adding a TXT record in the DNS settings of your hosting provider (just follow the docs here).

Once the verification was done (in my case it took only a minute or so), I started to create the A (IPv4) and AAAA (IPv6) records to my DNS settings as described in the docs. Last but not least I set up a redirect for the www subdomain to be redirected to to my apex domain.

Be patient here. Some hosting providers need longer than others to propagate DNS changes than others. Wildly adding and removing DNS entries does not help in this case!

Get my RSS Feed back to work

Now that everything was set up correctly and my blog was running on GitHub with my custom domain, I let the site run for some days. I then noticed that my RSS feed is no longer working under the old feed address.

My theme uses /feed.xml as the feed url, while my WordPress site used /feed/. So I needed a way to change that. After a quick GitHub discussion with the maintainer of the Chirpy theme, I had a solution. I needed to copy the feed generating file over to my assets folder and just adjust the permalink. Because Jekyll looks first in the assets folder for overrides, this worked as intended (see the docs here). In theory, that should have been all.

However, I display the RSS feed icon in the sidebar. As the blog is now rendered statically, all posts, tags, and category pages still had the old path, because the theme code does some magic adding the relative url based on the contact.yml file. So I ended up hardcoding the feed url for the moment and using feed as type for the icon instead of the default rss. Once the theme supports the /feed/ path itself, I can change that back to the auto generated relative url it used to be.

Conclusion

WordPress has evolved from just a blogging platform to a big, overblown and heavy CMS platform. I was not even using half of all the features it offers. It also became more and more expensive to just run my personal blog on WordPress. The recent chaos in their ecosystem gave me the last kick in the b*** I needed to finally do the work of moving away. I took some effort, but I would do it again if I needed to. I like the result and I am looking forward to extend my blog and learn some Ruby alongside it. There are some small things like favicons that I still need to fix, but the main portion of my blog is where I want it to be.

Until the next post, happy coding, everyone!


Title Image generated with Bing

This post is licensed under CC BY 4.0 by the author.

Comments powered by Disqus.