The ongoing drama between Wordpress v WP Engine continues to cross my reading list, but I have permanently removed WordPress from my website.
I have finally transitioned away from the complex Linux/Apache/MySQL/PHP (LAMP) stack required for self-hosting WordPress on my professional website. Now, I enjoy the flexibility of being able to host my statically generated website on a wide range of platforms, including object storage services.
I was fully aware of the outdated software versions in this stack, including WordPress itself, and the limitations of several plugins. This isn’t my first attempt to overhaul my entire site, which combines HTML, PHP, WordPress, and custom CSS.
While recently working with whatweb , a security tool from Kali Linux , I was struck by the number of concerns it highlighted. It demonstrated just how easily malicious actors can gather a vast amount of information about any accessible website, such as version numbers. This goes beyond overly simplistic hacks, like the recent very public www.yourdomain.com/.env leaked credentials, which led to numerous websites being compromised.
The hack was so straightforward that I was able to replicate it myself. Although none of my websites were affected, the exercise underscored how easily sensitive credentials—such as AWS keys, email credentials, and database access—can be leaked.
WordPress users with some technical knowledge have several options to consider. I decided to migrate my blog to Hugo instead of Eleventy . Since I already use Hugo for several other sites, the learning curve was relatively minimal. Additionally, Hugo is written in Go, which aligns well with my current interests. While I haven’t modified the Hugo source code extensively (though I have made some changes), I actively develop with Go in my free time.
Highlights
- Faster Load Times: My website loads noticeably faster.
- Simple Backups: Backup is now effortless since the site is stored as a Git repository.
- Cost Efficiency: Hosting the site as static files is cheaper—and even free in some cases.
- Smooth Migration: I successfully exported over 1,000 blog posts using a plugin, with relative ease for the post contents.
- Full OpenGraph Support: OpenGraph metadata now works perfectly, solving issues I previously had with WordPress, where embedded links on sites like LinkedIn often failed.
- Reliability: No more worrying about a disk-full event breaking MySQL and halting my site.
- Terminal-Based Workflow: Working in a terminal with vi suits my workflow better than relying on a GUI, so this change feels like a win.
Lowlights
- Messy Migration Syntax: While the bulk migration plugin was helpful, it left behind messy and deprecated template syntax. However, since everything is now in Markdown, I can create my own optimization tool without dealing with PHP.
- Confusing Hugo Documentation: The documentation can be hard to navigate, especially with the choice between TOML, YAML, and JSON formats, which adds unnecessary complexity.
- Generated HTML Issues: The generated HTML contains annoyances like duplicate meta description tags (one with content, one blank) and excessive whitespace. These seem like trivial issues to fix but remain unresolved.
- Unanswered Problems: I faced several minor problems that neither Google searches nor ChatGPT could solve accurately. I resorted to using grep, first in my template site and later in the Hugo source code itself.
- Build Inconsistencies: Hugo’s README instructions for local builds were unclear and not truly local. Moreover, the latest Hugo version was incompatible with the slightly older version I was using. Even using the Git release tag for a specific version generated different output, which was baffling.
Complexities
Hugo has a learning curve, and I still find it inefficient in certain areas.
I aimed to achieve feature parity with my legacy website, but all my non-WordPress pages will need to be manually converted at a later stage. While Markdown simplifies content management, it lacks the flexibility of raw HTML, resulting in a mix of Hugo templating and HTML in my workflow.
The categories displayed on the right side don’t reflect the case formatting I use for my posts. For example, I want to see ‘MySQL’ instead of ‘mysql.’ While this seems like a straightforward issue, it has proven more complicated than expected and remains on my TODO list after a failed attempt to resolve it. Additionally, there was no pre-built history widget (like the one below categories on my old site), but after multiple attempts, ChatGPT provided a decent initial solution. However, it’s still not ideal.
Finally, I permanently deleted my unused WordPress.com account for good measure.
Now the greatest pain is trying to GenAI images for blog posts. The amount of time spent on ChatGPT and Gemini and not getting an ideal image!!!
–
