Liz Denys

Until today, my website was fragmented across a number of static pages and two WordPress instances. To simplify my life, I decided to unify them into one content management system instead of keeping that somewhat unwieldly mess around.

I had never really put a lot of thought into picking platforms before, hence the mess. For many years, my "homepage" was a single static page, which was easy enough since I've been writing HTML and CSS for about fifteen years. It later grew to five pages, but with some extremely simple scripting, it was just as easy to maintain my five static pages instead of just the one. My (modern) blog had always been a WordPress instance. I separated my food blog posts from my other posts for probably imprudent reasons a couple years ago, and I didn't think to do anything besides split it into two WordPress instances.

Eight years ago, I picked WordPress for a few reasons:

• WordPress is a relatively simple system to operate.
• Lots of people use WordPress, so you can usually find the answers to your questions with some quick internet searches. (Sadly, their own docs are, or at least were, kind of sad.)
• The themes are highly customizable with HTML and CSS, and WordPress theme syntax isn't too hard to pick up.
• I was hosting it on SIPB's scripts.mit.edu and installing WordPress was a breeze and free. As a SIPB member, I knew the maintainers well, so I felt like I could safely host my site there with less machine maintenance.
• I wanted some fancy plugins at the time, and WordPress had them. (I don't use them anymore.)

But WordPress has a lot of drawbacks, too:

• It's written primarily in PHP. (No amount of homebrew server-side include scripting done in high school to make your first self-hosted blog can make writing PHP exciting.)
• It requires a database.
• You create the site through an online system. I hate web interfaces. I hate clicking to create things.
• You need to constantly update WordPress itself (and its plugins) to keep up with security issues.
• Dynamic websites don't load quickly. I barely used the dynamic features: an unnecessary Twitter module and comments I never really wanted aren't enough to justify that cost.

Since I wasn't really using any WordPress specific features or any dynamic features, I decided to move to a static website system instead. I could still have good control over my theming through HTML and CSS, eliminate a source of security vulnerabilities, improve loading speed, and stop using PHP and MySQL. There were a lot of additional upsides for me, too:

• It's easy to keep my website under version control - both the files to generate the site and the generated site.
• It's easy to move my website around different hosting options.
• Comment integration is significantly more complicated, so the completely misguided temptation to allow comments is basically removed.

There are many static site generators around; I chose Pelican. Some specific reasons include:

• It's in Python, and I like writing Python.
• It's fairly well documented.
• It has an active and growing community.
• While I can continue to directly use HTML like I have for years, I could opt to learn and use the simpler Markdown later.
• I can organize my raw content conveniently - files can be put in whatever folder or subfolder I want, and it can generate my website's hierarchy according to other rules.
• People have already written some convenient plugins, specifically the neighbors plugin I use to add chronological navigation between articles.
• My best friend already uses Pelican for his site. (This was probably about 80% of my reasoning.)

But I can't say that Pelican is without flaws; I encountered some pretty big ones in my switch:

• The Pelican dev team made a big mistake in choosing the AGPL for the project's license. Themes by the dev team may also fall under Pelican's AGPL, and if that's the case, sites generated with those themes - and thus their content - may also be covered by the AGPL. I learned a bunch of Jinja because I had to create this theme without looking at any existing Pelican themes so that my site would avoid these licensing issues. I am working on a less personalized Pelican theme to release under the MIT license so that others can also have a simple theme to use without having to worry that the Pelican dev team might enforce the AGPL over their content.
• Pelican doesn't believe in multiple categories. I converted all of my categories to tags, but it doesn't feel quite right. At some point, I'm going to break down and fork the project to add this functionality.
• Putting double quotes in article titles doesn't work. Even if you use " instead of ", Pelican will convert them to plain "s when inserted into link titles. This generates invalid HTML. I'll probably patch this when I get some time, but for now, I've just changed all the double quotes in my article titles to single quotes.
• The WordPress importer didn't work so well for me. Maybe this had something to do with my having multiple categories for many of my posts? Honestly, I don't know because I wrote a hacky shell script instead of digging into it.

So yeah! My site's in Pelican now, so I'm slowly making progress to finishing my website revamp! :)