A few years ago, I built a super fancy headless WordPress site for my personal site. It was way overbuilt, and over-complicated for the needs of a personal brand website, and I knew that even at the time, but I really wanted to mess with Next.js, and I had some time on my hands at the time. (What a concept).

It hadn’t been that big of a problem to maintain. It generally ran without issue, and when it did deploying the fix wasn’t so bad. But there were a few issues that put me on the fence about switch back to non-headless for a few months

And then I left my job at GoDaddy. and started to look for freelance work. I wanted to build some better-designed pages that were optimized for certain services I wanted to offer, but the headless approach was very limiting in this regard. I recently launched Siren, and really fell in love with full-site editing, which has come a long way since I built the headless version of my site just a couple of years ago.

Plus, I’ve been thinking a bit about launching some more products through my site, perhaps a course or some other digital thing. I felt that it made sense to do this with my personal brand instead of my business branding, but with the headless build of my site, I knew that I was going to be in for a lot of work to make that happen.

On-top of that, I started noticing that I had some SEO issues that I needed to resolve to make my content more crawl-able. I don’t want to get into the nitty-gritty, but Google was not a fan of how I handled pagination, even though I’m quite certain I did it “the right way”.

Oh, and caching wasn’t working quite right, either, which slowed the site down as my content continued to grow.

And the cherry on-top is that I was paying quite a bit more per month to host this site since I opted to host everything across two servers. (Probably could have gotten by with one, but I really wasn’t comfortable with putting everything on a single DO droplet.

So needless to say, I had an ever-growing list of problems with my headless site, and limitations that I wasn’t happy with. I knew I could fix these problems eventually, but now that I’m working for myself and I’m a lot busier than I was even a few months ago, I knew there was no chance I was going to get this done. This feeling was exacerbated by the utter delight I had in building Siren’s website. WordPress has really come a long way.

No. I needed to turn down the difficulty on this one, and the fact that my site’s technical SEO wasn’t up to snuff, and I was limited on my options for quickly setting up marketing pages were suddenly a lot more important to me.

So fast forward to yesterday.

I went to my site and noticed that it was having a problem with a recent plugin update. I knew that it would likely take an hour or so to fix, but definitely had the potential to consume my entire evening. The site was written well-enough, but the complexity meant there be dragons, and I really wasn’t sure exactly what the issue was.

So, I said “screw it”, and went about my business rebuilding the entire thing on a non-headless site.

Migrating With Rocket

I’m a huge fan of Rocket.net. They’re insanely fast, their hosting interface is not bloated at all, the support team gets back to you quickly, and they’re quick about migrating you to their host.

Building With Ollie

While Rocket was busy setting up my site, I opted to start doing some research on what block kit I was going to use. There’s several out there at this point, so I started poking around. I knew I wanted something that enhances the block editor without necessarily overriding it. I landed on Ollie.

I picked Ollie because it basically set up all of the things I was going to set up if I built the theme from scratch. The color scheme, various block attributes, and the pre-built templates, not to mention a generally great head start on any CSS Customizations that may be necessary.

I remember the amount of time I spent setting all of this up in my scratch-made FSE theme I built for Siren, and I gotta say, after using Ollie for this, I don’t see me ever building a theme from scratch again. This saved me so much time, and the end result was better than what I built myself, without any compromises. The days of building themes are truly dead.

I worked on the archive pages, set up the header and footer, and well…that was basically it for starters. My site was very much a traditional blog, using categories and tags to the fullest extent of their capabilities, and as a result setting up the actual theme to get all of the content back in-place was not much of a process. But now…now I can start building them better. Yay!

Plugins

And that was the first step in my process, here. I reached out and asked them to migrate my site over from my previous host. A quick message to their support channel, 1 admin account, and about an hour later, my site was moved over.

Finally, I had a few inconsistencies in behavior between the headless version and the new non-headless version. All of my content was there, but I needed to add a few tweaks, like changing some permalink structures to custom versions, ensuring the RSS feed URL still works, and a customization to my micropost premalink structure. I slapped pluginception on the site and asked ChatGPT to do the specific little customization I needed. After a few back-and-forths, and a few minor corrections I had all of the customization done in about an hour. 3 single-file plugins tossed into my site – active, and ready to go. Not bad!

Stumbling Blocks (lol)

There is one significant issue I have, however, and I think it’s going to require that I actually build something to solve it. The full site editor does not have a lot of support for post formats. It’s a feature that’s buried in WordPress, only activated if a theme is set to support it. It was largely replaced by custom post types, and as a result is rarely considered when building out new features for WordPress.

The problem, however, is that the WordPress app does not support custom post types at all. So if you want to publish content that is not a default “post” post type, it’s just not going to work. Oddly enough, however, the app does support post formats. Because of this, I opted to use post formats in my site for micro content as well as blog content, literally because it was the only way I could publish content using my phone. (Using the website for this is not an option if you’re seriously going to be posting several times a day with it. Stop calling that an acceptable solution, y’all.)

It’s frustrating that we’ve had the mobile app, and custom post types for over a decade at this point and something that’s so fundamental to WordPress still hasn’t been added to the WordPress app. If the app supported custom post types, I’d migrate my content to use that in a heartbeat, and none of this would be an issue. But as it is, I’m forced to use the ill-supported post formats because it’s literally the only path I have.

On the flip-side, I’d really like to see post formats supported in the block editor. It would be so helpful to be able to show different post templates within a query based on the format, not to mention how great it would be to actually customize pages with different post formats. There’s a couple GitHub issues related to this experience, and talks about improving it overall, but it’s tough to say how long it’ll be before those features actually see the light of day.

Although, there is hope – since there’s an open pull request that would solve half of this problem for me…!

In the meantime, I might be forced to build a solution that will solve my problem. Perhaps I can report my findings and solution to the Gutenberg team so they can use it to figure out how to build a solution that works for the general public. I guess that’s the beauty of open source, right? If something isn’t good enough for you, you can fix it, and maybe even fix it for others.

So, until I get this figured out, my archives look a little funny. It’s driving me insane so I’ll probably fix it pretty soon.

Conclusions

All of this happened in an evening. From the time I started to the time the site was done, about 6 hours passed. I had fully migrated the site, learned about Ollie, built the customization to accommodate my site’s special needs, and even spent a fair bit of time just trying to figure out a workaround for my post format woes. Not bad, all things considered! Especially since the Siren site took me weeks to build, and I honestly don’t think it came out as good as this site.

And don’t even think about asking me the time I spent on the headless site. Eek…

Now I can use WordPress plugins again without doing any special accommodations, and can also use Ollie to build out the pages on the site. I’ll chip-away at them over time, improving them as time goes on. Heck, I already put together two landing pages for my services, and re-did my resume page.

This is well-timed too, with WCUS right around the corner.