Migrating to a Static Site: Three Approaches

Published 2019-04-25

In this post I explain how I converted three sites from PHP/MySQL into statically served sites. Each of these sites was converted using a different approach.

Intro

I recently got interested in statically generated sites after hearing about Hugo. I started with moving this blog over from WordPress. Once I got that done and felt more comfortable with the idea, I decided two more of my sites would also be better run statically.

In total I ended up converting three PHP/MySQL sites into simple statically served sites. Interestingly, I used a different method to convert each of these sites. In the following sections I will explain these approaches and the reasoning behind them.

Content-Only Migration

My personal blog was running on WordPress for several years and was the first site I wanted to convert. I wrote more about that decision here. My blog is very small and simple and I was attracted to the idea of writing posts using Markdown in VSCode and managing my content in Git.

In this case, I was only interested in preserving the content. I had no problem moving to a completely new theme. I found my Hugo theme and manually copied over my blog content. It’s been over a month now since I converted the site and I’m very pleased with this new setup.

Migrating Themes and Content

The next site I migrated was MSCE Connect. It was a small Yii-framework based site with a simple bootstrap theme and only a handful of pages. The site is for an alumni organization. The community is mainly active on Facebook and the site content hasn’t changed in years.

I stuck with Hugo for this site as well, but created my own theme from scratch. I copied over all the CSS files, web page template, images and other resources needed. I then copied over the page contents into Hugo HTML pages. All of this was done in a few hours.

Brute Force Scraping

The final site was also using the Yii framework. It was an old project that was no longer under development, but I still needed to keep the site up and running. I started out attempting to implement a Hugo-based site, but quickly realized the site had a much more complex theme that would be very hard to port.

I gave up on the idea of converting the site at first, but a day later I remembered that there are tools that can download an entire site’s content and save it to disk. There are ways to do this with wget from the command line, but I ended up using HTTrack. The tool downloaded all the pages of the site locally and converted all links to relative paths so they could be served from any location.

The process was not perfect unfortuantely. A few URLs and some of the resources did not get copied for some reason. I had to test the downloaded site, manually fetch the missing resources and fix some invalid URLs. It was not a fun task, but replace-all in VSCode helped me get through it fairly quickly. The manual fixes took an hour of time, but that was after quite a bit of time wasted trying to get HTTrack to do everything perfectly automatically. I think the lesson I learned here is that sometimes it’s better to just do things the “stupid way”.

Conclusion

And there you have it, three different ways to create a static site from a dynamic setup. The main questions that helped determine which approach to use were:

  • Is it important to preserve the site’s current style?
  • How complex is the site’s theme?
  • How many pages of content are there?
  • Will you want to change the content in the future?

I chose to convert these three sites specifically because they were the only ones I had that require a MySQL database. By making these sites static I was able to shut that MySQL server down. Migrating a database is one of the most annoying parts of moving websites from one server/cluster to another, so this change makes my life much easier.

comments powered by Disqus