Table of Content
This is the tale of our journey to and from Wordpress as a blogging and content management platform.
You could say we were married to Wordpress. It is the CMS so many others were and still are using—even sites with boatloads more content traffic than we generate. Therefore, it was the one for us, through thick and thin.
What’s not to love? Writers and editors are familiar with Wordpress from other publishers or from their own personal blogs. Managers can tinker with optimization settings or add social sharing buttons without the need for developers thanks to myriad plugins. New themes can be developed externally then simply uploaded and enabled.
Everything seemed so right in the beginning between us and Wordpress, and the relationship was solid for many years. The match just felt easy, because it genuinely was. Was it a loveless marriage? Perhaps. None of us felt passionately enthralled with Wordpress, but it was undeniably easy and convenient. With ease and convenience came detachment and when taken for granted, the relationship withered.
We convinced ourselves that we had to stay together, that there was no other choice. Our “kids,” or rather, our precious content and permalinks, were well-indexed in Google and getting steady traffic. However, we neglected to plan for our content’s long term future, and were heavily reliant on outside help from plugins or theme developers that we could not completely trust.
We tried to make it work, but far too often (and typically on a weekend, no less) it seemed like there was a new issue, an exploit to patch, an update to apply, or some problem for which we didn’t have the requisite team members to task with fully owning and fixing. We could patch things up, but knew that the end was near. Wordpress remained the first-call choice for so many content sites, so we doubted our instincts to leave it, but something had to give.
We made as clean a break as possible. The move to a new content platform, however, naturally came with a learning curve. Not everything that we took for granted in Wordpress was available by default with other CMS platforms. Searching for analogs to features and coming up empty-handed, only to eventually learn new ways of doing the same old things, was challenging. Yet learning is part of growing, and we’re really learning to love Hugo.
The Rebound
We did not make this decision lightly, as our marriage to Wordpress was one of great convenience and it served us well for many years. This tale is also not a call-out post or meant to denigrate the continued hard work of Wordpress or open-source developers. It’s just a tale of growing up and growing apart.
And so begins our relationship with Hugo—and the end to this uncomfortable marriage/divorce metaphor.
Hugo is a static site generator, which in its most simple form, takes a bunch of content in Markdown format (usually, but not exclusively), HTML templates (along with a template syntax via Go Templates) and assets (CSS, images, Javascript) on a filesystem. It then generates static HTML files that can be uploaded to a host, deployed to a production server or pushed to cloud storage.
Those static HTML files can be generated locally for development purposes, on a staging server, or on an external service, so long as it supports your flavor of static site generator and has access to the source files.
There are static site generators to suit most language tastes and library fancies, but we chose Go-based Hugo for its speed and language familiarity.
So, why did we choose a static site generator rather than a similarly abled database-driven CMS?
Security
Wordpress is the most widely used open source CMS as of December 2019. It contributes heavily to the continued popularity of the PHP programming language.
Wordpress is also a huge target for exploitation. Since it powers millions of sites and has done so for so long, there are countless outdated and vulnerable installations ripe for abuse.
A fresh, vanilla Wordpress install is lacking in some of the most necessary security measures, such as multi-factor authentication, HTTPS restriction, reCAPTCHA support and enforcement of strong passwords.
We have many writers, editors, project managers, and developers who all required accounts on each of our Wordpress blogs, across multiple domains. With a lack of any good multi-factor authentication, we were unsatisfied with the level of security that was available (at the end of the day, we deem security of paramount importance). Relying on yet another plugin for managing MFA or SSO access was the eventual reality we would face if we stuck with Wordpress.
Speaking of plugins, another issue we ran into was having to lock down plugin install permissions in production, not only to prevent non-vetted plugins from being used but also because of how our production environment is architected. We ran Wordpress in a clustered environment with CI/CD, so any changes to the filesystem that a plugin made in production on a pod volume would not persist when instances scaled out. Plugins would need to be installed in the development environment connected to the production database, then committed to version control and deployed to production. It made what was a signature feature of Wordpress—easily installed plugins—cumbersome and fragile.
Scalability
Wordpress is tied inextricably to the MySQL or MariaDB (or PostgreSQL, apparently) databases, so without a well-designed caching scheme in place, a site’s throughput would be limited by the database. While this is a common and surmountable hurdle, it would be lovely to eliminate it altogether if we could, and a statically generated site does this by its nature.
One of the nicest features of Wordpress is its image asset resizing and cropping, right from the Media interface. Our distributed production environment required the use of a plugin to store Wordpress image assets on Amazon S3—not ideal but also not that big of a deal. With our switch to Hugo, we needed a way to dynamically resize article image assets how Wordpress would for thumbnails, hero sections, etc.
Hugo provides image processing but at even the small-to-medium scale of our largest blog, a full rebuild could take 8-10 minutes after processing thousands of images. Imagine waiting 8-10 minutes to see a typo fixed in production.
The solution comes in the form of a dynamic image manipulation CDN, either from Amazon AWS and their Serverless Image Handler template, or from Cloudinary. Now, we resize images by changing URL parameters in the HTML templates or in the Markdown content, rather than relying on pre-processed, duplicate image assets.
Customizability
Searching for the right Wordpress plugin to add a needed feature is always a crapshoot, and increasingly one where you wind up paying for each plugin to get a full set of features or to ensure future support. Since piecing together a feature set with dozens of plugins—from security to layout to SEO—made by disparate developers is far from ideal, the switch to a static site generator was one we were comfortable making. We develop our other search engine optimized sites from scratch, and having a similar level of control without being beholden to third party plugins was tantalizing.
Maintainability
We did not employ a dedicated Wordpress developer in-house, and with few volunteers stepping forward to become that expert, we realized moving away from the platform wouldn’t lose us any friends. Internally, the enthusiasm gap for working on PHP projects is already palpable, even though we heavily use the language and fully appreciate PHP’s continually awesome development. Combining that with a project like Wordpress was a recipe for, well, ennui.
Hugo is being enthusiastically adopted and improved on. Go’s honeymoon period has yet to wear off as it is a relatively new language. We also use Go extensively in our data engineering projects, so we have internal resources to lean on. And Hugo is fast—very fast, compared to similar projects like Jekyll. All of this made Hugo a safe choice for our static site generation needs.
Accountability
The revision history feature in Wordpress is handy, but it doesn’t hold a candle to storing content in a tried-and-true version control system like Git.
Wordpress is not designed to be used with any external version control system. While that did not stop us from committing all Wordpress templates and configuration files to Git, it left the content revision history up to the database.
With Hugo, all content, as well as templates, CSS and Javascript, and configuration is kept in a Git repository, and pulled down for local development. You can see exactly what production content will look like and how it will behave locally, with no need for a staging environment or development database.
Git with Hugo allows a level of development flexibility and familiarity, fault tolerance, transparency and accountability that isn’t easily achievable with Wordpress.
And with that, we parted ways with Wordpress and have not looked back. That does not mean we will forget all the good content we shared with Wordpress—it was migrated to Hugo. 😁
To see what Hugo is capable of, please browse our safety and security articles at BeenVerified, personal tips at PeopleLooker, community advice at NeighborWho, or home buying and selling knowledge at Ownerly. For more posts about coding, visit our Engineering blog, also built with Hugo!
Be sure to check out the follow-up post, focused on how we manage all that content and make Hugo work for us.
While you’re at it, check out our careers page and reach out. We would love to chat!
Top comments (0)