A world without WordPress: Payload as an alternative to ACF

I can’t believe it. They actually did it. After over a decade of using Advanced Custom Fields (ACF), I come back to find it replaced with Secure Custom Fields.

All of this over petty drama. Seriously, are we in the Twilight Zone?

But let’s back up for a second.

The writing has been on the wall for WordPress for a while now. Just go to the dashboard and you’ll see it: WordPress events being advertised? Get out of my software. That’s not part of the repo, and it definitely shouldn’t be in open-source software.

So here we are, at a crossroads.

Do I think WordPress is going anywhere? No, probably not. But this feels like an opportunity to step back and really think about what WordPress is doing—and more importantly, what it shouldn’t be doing.

It’s time to start imagining a world where we’re not all relying on WordPress for things it was never really built to handle.

Why we built Payload

To no one's surprise, I’m not the biggest fan of WordPress.

I respect it, sure, but I literally built a company so I’d never have to use it again. It was a lot of work, but now with Payload, I don’t have to worry about any of the nonsense that comes with WordPress—like having plugins stolen or watching your hard work be co-opted.

That’s because Payload, like any sane open-source software, uses third-party package repositories to install dependencies. We use npm, which is owned by Microsoft (and let’s face it, if Microsoft starts stealing plugins, we’ve got bigger problems).

But when we talk about moving on from WordPress, it’s important to acknowledge its strengths. The biggest one? WordPress is open-source, and that’s always been a huge selling point. Clients love it. It means they own their code and can do whatever they want with it.

Now, compare that to third-party SaaS CMS options. You pitch one of those, and clients immediately start asking, “What happens if we want to switch vendors in six months?” or “What if they increase their prices?” or “What if we need a feature they don’t offer and we can’t build it because we don’t own the code?”

With WordPress, that’s not a concern. But outside of that, WordPress’s appeal starts to wear thin—fast.

What's next for developers after WordPress?

So, who uses WordPress? I’d break them into two categories: No-code users and the devs.

1. The no-code crowd is piecing together themes and plugins, crossing their fingers that nothing explodes or they don’t get hacked. If that’s your thing, great, but that’s not what Payload is about.
   
   But if you’re looking for an open-source no-code tool, there are better options out there.
   
2. Then, there are the developers. These are the folks who use WordPress the way I used to—writing custom themes from scratch, installing the classic editor, setting up ACF (Advanced Custom Fields), and building out schemas in code.
   
   If that’s you, then Payload might be the natural next step.

Let’s talk about ACF for a second.

I spun up a project with it recently, and honestly, it was traumatizing. I’ll compare it to Payload to show you why.

So, in WordPress, I set up two post types: directors and movies. But here’s the thing—WordPress treats these as post types, which drives me nuts. They’re not posts. They should be tables in a database, but WordPress just throws everything into the wp_posts table. It’s madness.

And it’s not even truly open-source because ACF, like many WordPress plugins, requires a paid license!

Now, compare that to Payload.

I spun up a fresh Payload project, added collections for directors and movies, and guess what? My database structure actually makes sense. I have a year column, a director ID that’s a foreign key to the directors table, and a poster ID that points to the media table.

Everything works out of the box, with proper relationships and data integrity.

This is a good time to mention that we've released bi-directional relationships in Payload 3.0. You define the relationship on one side, and it automatically shows up on the other side.

Try doing that in ACF. It’s a huge time-saver and makes managing your data a breeze. In WordPress, it’s all just crammed into one table. You’ve got wp_posts, and whether it’s a blog post, a movie, or a director, it’s all thrown together. Want to customize it? Sure, but be ready to pay for the privilege and deal with messy workarounds.

Payload vs WordPress

On top of that, the editing experience in Payload is just better. You’ve got live preview out of the box, real-time editing, and a clean, modern admin UI that’s designed for developers.

Payload works with Postgres, MongoDB, or SQLite, and everything is indexed and optimized from the get-go.

With WordPress, you’re stuck doing things the hard way.

So, if you’re a developer who’s been writing custom themes and building with ACF, and you’re wondering what’s next, I think you’ll find a lot to love in Payload. WordPress is still around, but for those of us who value open-source software and want a more modern, streamlined approach to building apps, Payload is a pretty solid next step.

To recap, we took inspiration from ACF, sure, but we made it better. In Payload, custom fields are just fields—no need for a plugin. We think WordPress should have figured that out a long time ago, but here we are in 2024, still talking about it. It’s time for a change.