They lost the comment system and had to move the data to an external provider, which instantly bit them.
They had to write Python scripts to munge the data.
But now they have the performance of static html. I guess just changing two lines in the nginx configuration did not came to mind.
I think this was a very poor investment and will never pay off.
Really... modern WordPress is a very complicated beast and keeping all sorts of details about how you need to optimize it, server, caching, db in you head is just no worth it. Yeah, "changing two lines in the nginx configuration" could have worked, but imho simply the cost of keeping in your head the information about what two lines to change is just too large. As it grows, it simply drives you insane by how many technical trivialities you need to keep in your head to keep it working smoothly, when you could instead use that brainpower so solve the really interesting problems.
An the fact that "their marketing team has to use the Github interface and learn Markdown" is also a hidden benefit, if you think about all the subtle frontend bugs that happen when somebody uses the WYSIWYG editor of WP and they end up with a combination of styles that breaks the layout. For any project above a certain size, the "dumb WIM" (What I Mean) interface of Markdown always trumps the WYSIWYG.
Also, the benefit of mostly NOT HAVING TO THINK ABOUT SECURITY AT ALL is freaking HUGE! Developers can simply say "it's the server guys' problem" now. Forget about having to manually audit the code of 3rd party plugins if you really care about security. And forget about updating and realizing something breaks and you have to fix it.
For any fast growing company, keep this in mind: REDUCE COMPLEXITY. ALWAYS. NO MATTER HOW LARGE THE SHORT TERM COST.
Or, you can slap some ram sticks in the machine, install varnish-cache, write a few rules for it and go play minecraft the other 29 days.
For everything else there's Ansible.
We've taken the approach to not type a single command into a live server's console and use CM tools to document and automate. This, along with well written operating documentation can be invaluable.
God, the hours I've seen co-workers waste, trying to eliminate some errant space in a rich-text-editor-generated hyperlink, by pressing a random sequence of rich-text buttons. A lot of times, they just go straight to the raw HTML to fix things...and if you're already doing that, you're capable of learning Markdown (let's skip the discussion of why editing raw HTML can be even more disastrous).
Kudos to you for being eager to learn new skills...I'm an engineer and a self-taught web dev I wish someone had forced me to learn Markdown much earlier than I had.
Nevertheless, now that it is done, I hope the new system works well for you. Maybe your team gets used to git for version control in other areas of work, too, which would be a huge win and ultimately prove me wrong ;-)
Performance also wasn't the only plus here. Closing major security holes, making more of our content and technology more open, and moving to a platform that our devs liked working in are just some of the other wins.
It's too early to say definitively now, but we think the change is probably a good one.
However, the podcast feed is impossible to find now if you didn't have it before. Previously I think it was on every podcast post as an RSS link. Now the individual tag RSS links all point to the main feed, rather than to a per-tag feed.
e.g. http://blog.stackoverflow.com/category/podcasts/feed/ still works if you know it, but going to https://blog.stackexchange.com/tags/podcasts/ gives you an RSS link to just "/feed/".
This is probably not a good place for bug reports :-S
I imagine the payoff is similar for the stack overflow team as well.
EDIT: I don't understand why they are using disqus for comments, when they have a self hosted comment platform, in my case we don't accept comments.
The Stack Exchange blog was hacked a few years ago, I suspect that was part of the motivation to switch to something they know better.
They spent more than $2M writing their own blogging system, and it still was missing many features that come with Wordpress.
They ditched it and switched back to Wordpress.
Using using an external comment provider promotes some popular users to comment such as Grimlock whom otherwise wouldn't.
There is an argument to be made that a ubiquitous, developer-first system translates into more instant changes. Seeing changes quickly makes it easier to iterate, which is better over time than the initial investment to learn Markdown.
Creation is more fun than selection. And in the same position, I'd ditch Wordpress like a stolen sports car.
Even if they found "a blogging platform that iddn't require custom markdown interfaces" that would not have solved the problems they faced getting data out of wordpress.
However, WordPress is not cool so they went to the tired old "reinvent blogging". No open source contributions, just building castles in their own sandbox.
- Everything in markdown
- Generate the podcasts as an RSS feed
- Generate the list of videos as JSON, filtered inside the AngularJS app
Such an approach is not great for SEO in the short-term, so I won't be surprised if they lose ranking because their posts and comments are missing from the the html until their jQuery code fetches and renders them.
For me, I don't have 700 posts so that's easy to address later once I have content worth indexing, keeping the urls the same of course. :)
I’m thinking about setting up a separate draft and post repo and importing them into the root with git subtree.
That being said, that evaluation was done before we found out how difficult it would be with Disqus.
