Stack Exchange Blog Ditches WordPress for Jekyll

Last week Stack Exchange announced its new blog, revamped to publish company news and engineering posts. The first post on the blog, written by Jon Chan, Stack Overflow’s developer evangelist, made no small amount of fanfare over migrating from WordPress to Jekyll.

Chan’s explanation of the team’s process cites a few curious reasons for their dissatisfaction with WordPress:

During the original proposal stage for the engineering blog, we also had a conversation about what engine we would use. At the time, all of our blogs were running WordPress…which we weren’t so happy about. It was very buggy, difficult to log in to, not very performant, and has caused our SRE team more than a few headaches. If we were really going to revamp the new company blog, it seemed like a lot of work to try and wrestle with our WordPress installation.

With a little bit of WordPress skill, these seem like easy complaints to resolve, especially given that Chan said the team was inspired by blogs like Code as Craft and OkTrends, both powered by WordPress. However, anti-WordPress sentiments continue to run high within the Stack Overflow community, which recently ranked the software as the third most dreaded technology.

photo credit: StackExchange Blog
photo credit: StackExchange Blog

After a great deal of consideration, the Stack Exchange team opted to use a static engine, eventually landing on Jekyll. Chan outlined the advantages they perceived in the move:

  • Posts are in Markdown, something most of our company was familiar with
  • Jekyll is just static site generation, so it’s much more performant
  • Complete flexibility for front end work, no need to wrestle with templates
  • Open source with a strong community, which we love
  • Not WordPress or PHP

Chan described the migration process, an endeavor that was fraught with obstacles. There is a Jekyll Exporter plugin available to those who want to migrate their blogs over, but Stack Exchange opted to use the exitwp tool to get them most of the way there.

Since Jekyll doesn’t offer native support for comments, one of the biggest challenges in the migration was preserving that content and porting it into a new system. The Stack Exchange team decided to use Disqus for comments but were unable to properly migrate their existing comments and had to craft an alternative solution.

“The worst part of this is how unsupported we were by the Disqus team,” Chan said. “We waited on the order of weeks for support responses and for over a month they went unresolved. Sending in official support tickets, emails, and posts on their Discuss forum went unnoticed.”

Despite their unsatisfactory experience with Disqus and the fact that they have to sacrifice Stack Exchange login capabilities in order to use it, Chan said they will continue with it going forward.

If you’re running a large, high profile blog on WordPress, it requires a certain level of expertise to customize themes and plugins and to ensure a high level of performance. It’s unclear whether or not the Stack Exchange team was lacking in expertise (based on some of the complaints cited) or simply unwilling to continue with WordPress after unsatisfactory experiences. No massive migration from one platform to another is ever going to be easy and bug-free, but Chan’s account offers some valuable insight on how difficult it currently is to move from WordPress to Jekyll while preserving all of your content.

15 Comments


  1. Might be easier for them to use WordPress.com or Weebly if they’re struggling with a self hosted solution!

    Report


  2. They could have asked for help at wordpress.stackexchange.com

    Report


  3. Telling people you use WordPress isn’t cool if you’re in tech. That’s what the unwashed masses use. The change probably had as much to do with the perception of WordPress as with the actual software. The people at SO are going to want to use the lightest-weight, hippest, newest thing out there.

    Report


  4. If they are planning to keep that solely for blogging purposes, it isn’t surprising to have moved this over to jekyll. It’s static, less on resources and simple. WordPress is awesome. But also heavier and no longer just a simple blogging tool.

    Report


  5. I will surprise to find any other mature platform as WordPress out there.
    Their argument about it was buggy and not performant is so lame. They might need really good caching system, which I wonder no other platform would provide in built.
    Anyway good luck stack exchange for that, but I hope they will realise the whole migration process was a big mistake.

    Report


  6. Trashing WordPress and Disqus seems a bit juvenile… They could have just said, WordPress didn’t meet our needs for OUR blog. The fact that MUCH BIGGER blogs and news sites aren’t having any of those problems with WordPress shows their lack of expertise or prejudice going in to the project.

    Report


  7. That’s why their stack sites are running on .Net :) Folks have their biases, but they’ve never been remotely newest-hippest for the sake of it.

    Report


  8. I am all for static when that’s all you need. But as long as you go “oh, and we still want comments” it’s no longer a static site. And state of third party comment system is hot disaster for my taste.

    Report


    1. I thought the article was a really interesting read but I also wondered a little about the comments decision.

      Serving a static site is definitely tempting for the speed, but I’d have thought that the issues with Disqus would have been significant enough to make it a non-starter.

      Report


  9. I wonder what they’ll be using for the authoring experience since Jekyll doesn’t have any concept of browser-based backend for authoring and configuration. I guess removing that completely solves the difficult to log in to issue :)

    Secondly, WordPress is 100% as performant as Jekyll or any other static HTML file if you put it behind a full page caching layer such as FastCGI cache in Nginx or mod_cache in Apache. Plus, you get some sane cache invalidation with plugins such as “Nginx Helper”, “Nginx Cache Controller” and “NGINX Cache Optimizer”.

    Report


    1. On the authoring experience, this quote is from Jon Chan’s article, under the “Open Source” sub-head –

      Our blog was going to be used by people who are not very technical. Having a GUI for our community and marketing teams to create posts and preview Markdown without learning Git was great.

      When I first read this I assumed they had built a GUI for their users because I’ve played around with Jekyll and I don’t recall it having a GUI? Now I’m wondering if the “was great is referring to the WordPress post editor.

      The SO project is available on GitHub, and the authoring process is detailed there, if you’re interested.

      https://github.com/StackExchange/blog

      After reading it I’m guessing that while the developers are all probably quite happy with the new setup, the non-technical staff will most likely be missing WordPress. :-p

      Report


  10. I am a wordpress developer and share some of their concerns, but I am also someone who gets into a HULK SMASH rage every time I see a geek use the useless, non-word ‘performant’. It tends to make me ignore opinions as having come from an idiot.

    Report


  11. Ah yeah. Disqus. They never answer calls, and you can’t have Single Sign On. They offer it, they just don’t respond to your requests. So our clients won’t accept Disqus any more, but there’s a gap in the market now for a commenting engine with good single sign-on handling and syncing to the local install.

    WordPress performance *is* an issue. Out of the box, with some caching, it’s OK. Quick enough to match static sites on posts and pages. But, erm, that’s about it. But the problem starts with the dynamic side when dealing with high traffic, high content sites. You can DoS a large WP site quite easily by simply putting in some awkward, randomised search queries, for example. No amount of caching will help there. If you use Elastic Search or Google CSE or similar, then no problem. But if you don’t? Site’s down. Damn nuisance. And there’s a lot of that in WP along with little motivation to solve the problem because Automattic, who drive the project by and large, have a solution as part of one of their products – VIP Hosting.

    Is this a problem? Dunno. But if you don’t want to buy into Automattic’s VIP service and don’t want to learn and pay for all the workarounds the maybe there are better solutions than WP for certain use cases.

    Report

Comments are closed.