Losing my (wp) head for Astro

Ok you’ve seen the term headless and it stands out. As a long-time wordpress/shopify/joomla developer, I really have resisted moving headless or over to react. The majority of my work has been long-term, content-driven, multi-user sites that require an integration of content development and approvals—often without my intervention.

WordPress has been the core answer. It’s simple to set up, includes permissions and login built-in, and you can host it anywhere. Got a problem on this host here, move it there, TODAY.

Why would I ever change?

Well I wouldn’t, but wordpress has. As with any good project, it has evolved. Pieces are moving, the ecosystem is changing, and the build-time for a site is no longer as fast as it was. More than anything new blocks are more or less react(ish), but mix and matched with WP rest API and php development.

The entire ecosystem will not be the same, and there is splintering need between older-site content, and the direction of the new platform.

The secondary concern is that WordPress really does not need to be the source of truth on your content. Many business sites need to centralize content management in multiple spaces. WordPress has he capacity to add front-end JS that could effectively work in a similar method to a JS-first env. But if that were an effective solution, why would we look at JS frameworks at all?

We also lose a lot of versioning natively on wordpress. There are distinct advantages to being able to push a staging server from your local device to a staging system, then to live. WordPress can do this, but it does so with splintered content. You don’t use the same database, and you risk forking and overriding your essential updates. (To be fair this is a massive problem on shopify customizer too.)

So what do you look for on headless

This article is mostly about my decision to move my portfolio site from wordpress to Astro, so all notes will match that pathway. React, NextJS, Jeckyll (Really I like Jeckyll, it just never wins on the selection) all have reasons to go with them. Those are good reasons. For me, I like the mixed system from astro that prioritizes less JS to the browser. Most pages are fine in git. Portfolio items, blog posts, shop items, etc. are not.

So I’m looking at speed, and maintenance. My active content is available to post quickly, and my core content is tracked over time, and deployable with a simple merge commit. My site does not render, rerender, cache, and flush. It lives as pure HTML. My active content is mostly managed with a builder (wordpress) where I can write and post images.

My CMS is locked tightly. It’s only accessible through validated sources, and thats before a password is even set. I do not have to worry about hacks or plugin vulnerabilities on a holiday weekend, and my maintenance is low.

An addendum on versioning.

I have my system working on static builds, I can flip a switch and move it to active rest API queries on my fast content, but my edits are not often, nor fast, so I don’t.

The Build

My ecosystem is simple: a github repo, a server hosting my CMS & CRM, and Cloudflare hosting the public site on a worker & my CMS media on an R2 bucket. Cloudflare runs my CMS access, and firewall security. I run a business plan, but this is buildable on a free plan. My exact scenario could be run on a local copy of wordpress as well, or on an internal corporate network.

I have a master branch and working branches, when I dev on a working branch all current, exact content is live-pulled from my CRM, when I merge or custom build astro, that creates a static point on the CRM data that exists the worker build. Meaning a generational change can sit pleasantly out of view until its ready to publish. Minor changes can happen on another branch and be merged later.

Scheduled updates… well I’m not dealing with those right now.

The Results

I’m happy with the build, for me as a freelancer the content delivery method is a lot simpler, my day-to-day requires a lot less work.

The pitfalls:

It was more work than I’d do for a small project. Securing the integration is not as straightforward as you’d want, but i also went DEEP into hard security on this site that most clients would not require. There’s a gap on what wordpress offers in the rest API and what it really generates for itself in CSS. That’s the worst pitfall, CSS is not as deliverable from gutenberg or elementor through the API.

The most notable issue on the quick fix is that wordpress comes with a database and easy integrations into forms that collect responses. You will not get that with any JS first platform. It’s not difficult to add a CRM, but that CRM will not be free. Wordpres and contact form 7 (I do NOT recommend) can do that in an hour for the cost of your hosting.

The wins:

I can pull content form where the content makes sense to hold. My next step is to open up data from my airtable databases on past work and really integrate many of my own project management tools (read JIRA) into the site and improve how I can work with clients on a branded single location. It opens possibilities that would have been plugins I’d need to quit my career to build on wordpress.

Oh and you want to store your info somewhere else, start that today. If you can get an api link, you can get it on here and keep your current data there.

Would I do this again?

If I did, I’d do it different. I would build the Astro site on it’s own first. Then integrate the fast-content as I needed to. Working in git instead of wordpress makes that viable.

Should you do this?

I’m recommending this more and more, but it depends on your project and your site. Most simple marketing sites would benefit from astro over wordpress because most businesses have a core offering with no blog. Astro would be a faster, more stable resource for that. It just wouldn’t allow for a non-technical user to update a few words on demand. Hiring a consultant to make that update is a lot cheaper than regular wordpress maintenance.