After years of building my personal site with Jekyll and YAML files, I made the move to WordPress. It wasn’t a gradual decision or a careful evaluation of CMS options. It was more sudden than that.
The breaking point
The decision to leave Jekyll wasn’t really a decision at all. I had attended a conference organized by my employer and wanted to track it on my site properly. Not just “I went to this event,” but the full picture: what I learned, who I met, who hosted it, and the structured data needed to tell search engines about my attendance.
The problem? My employer already existed in my YAML files as part of my resume data. I wanted to reuse that organization node, not duplicate it. But I didn’t want my entire resume showing up on event pages. Managing these relationships across handwritten YAML files, visual templates, and schema.org markup meant yet another tedious iteration across all three layers.
I wasn’t going down that road again. It was time to grab the power tools.
That event is YoastCon 2022.
The migration
Moving from Jekyll to WordPress was refreshingly straightforward. I copy-pasted my content into WordPress. Since I hadn’t been publishing actively, I could afford to freeze the Jekyll site while building out the WordPress version. Once ready, I did a hard switch.
The real technical challenge wasn’t the migration itself, but rebuilding the visual elements I had created. I wanted to understand Full Site Editing themes, so I built my own theme from scratch. The GitHub-style breadcrumbs and tree-like directory navigation I’d created for my blog became dynamic blocks inside the theme.
This raised interesting architectural questions. Where should these elements live? In the theme or in a plugin? What’s the right way to translate my Jekyll data-driven templates into blocks? Working through FSE architecture gave a much deeper understanding of how WordPress themes actually work.
I chose managed hosting to get full control without too much hassle, giving me the flexibility I needed while avoiding server management headaches.
For more detail on where I came from, check How I built my YAML-powered Jekyll site.
What WordPress unlocked
Starting with Yoast SEO and The Events Calendar (TEC) gave me the foundation I needed. But I quickly realized TEC was built for event organizers, not event attendees. So I built my own plugin on top of it: The Event Attendee.
Right now it handles attendance roles aligned with schema.org specifications. Eventually I’ll add features around highlighting specific aspects like talks I attended. But the real win was creating fine-grained data blocks. Instead of monolithic event displays, I can now drop in several individual pieces like the organizer name, the venue url, and the event date. Each piece of data becomes a flexible block I can arrange freely in both the page and site editors.
This is exactly what I was struggling to achieve with YAML files. WordPress makes it natural.
I’ve also added a downloads section using Easy Digital Downloads. That’s where The Event Attendee lives for now. What catches my eye next? More schema integrations, naturally. More content types, more ways to layer information on the site.
Find the plugin and its latest features at The Event Attendee.
Joining the +40%
I’ve officially joined the +40% of websites running on WordPress, and I finally understand its popularity from the inside. It’s not just about ease of use for non-technical users. It’s about having the right abstractions for content management.
Jekyll was perfect when my site was a resume that only got an annual update. But once I wanted dynamic relationships between content, reusable data nodes, and complex structured data without hand-coding everything? WordPress gives you the tools to build that without reinventing the wheel.
The plugin ecosystem is powerful. Need events? There’s a plugin. Need downloads? There’s a plugin. Need something specific? Build your own plugin and integrate it seamlessly. That extensibility through WordPress-powered plugins and integrations is what has my attention now.
What’s next?
For now, WordPress is the right tool. I’m not looking to pivot again anytime soon. I’m still that puppy at heart, and WordPress itself offers plenty of balls to chase. New content types to explore, more schema integrations to build, deeper understanding of the platform to gain.
The difference now is that I’m chasing balls within an ecosystem designed for exactly this kind of exploration. WordPress doesn’t fight you when you want to extend it. It invites you to.
And that’s exactly where I want to be.