DEV Community

Cover image for I Stopped Fighting WordPress… So I Rebuilt How I Use It
Drew Marshall
Drew Marshall

Posted on

I Stopped Fighting WordPress… So I Rebuilt How I Use It

I’ve built enough WordPress projects to notice a pattern.

They all start clean.

Then slowly:

  • plugins pile up
  • logic creeps into templates
  • APIs get scattered
  • and “just make it work” becomes the architecture

At some point, you’re not building a system anymore—you’re managing chaos.

And the frustrating part?

It’s not really WordPress’ fault.


The Real Problem

WordPress tries to be everything:

  • CMS
  • backend
  • frontend
  • plugin system
  • templating engine

So naturally, everything ends up mixed together.

Routes know too much.
Templates do too much.
Plugins patch too much.

There’s no clear boundary between:

  • data
  • behavior
  • execution

That’s where things break down.


The Shift That Changed Everything

Instead of treating WordPress like the application…

I started treating it like a data source.

That single shift changes everything.

Now:

  • WordPress manages content
  • My system manages behavior
  • The frontend becomes fully flexible

Introducing KiwiPress

KiwiPress is an application layer on top of WordPress.

It doesn’t replace WordPress.

It organizes how you use it.

The goal is simple:

Separate what WordPress stores from how your app behaves.


How It’s Structured

KiwiPress sits between your app and WordPress and splits responsibilities clearly:

  • Seltzer → handles routes and request lifecycle
  • Nectarine → parses config and API structure
  • KiwiPress → owns WordPress-specific behavior

Inside KiwiPress, everything is broken into focused services:

  • WPCore → handles communication with WordPress
  • WPRead → fetches data
  • WPCreate → creates data
  • WPUpdate → updates data
  • WPDelete → deletes data
  • WPAuth → handles authentication
  • WPSync → handles migration, backup, and syncing

Each part has one job.

Nothing leaks.


What This Looks Like in Practice

Instead of stuffing logic into routes or templates…

You delegate.

const wpread = new WPRead();

const route = {
  method: "GET",
  path: "/users/:email",
  handler: () => wpread.getUserByEmail()
};
Enter fullscreen mode Exit fullscreen mode

The route doesn’t know how WordPress works.

It just asks for data.


Why This Matters

This approach gives you:

1. Clarity

You always know where logic lives.

2. Flexibility

Your frontend can be anything:

  • custom UI
  • SPA
  • static site
  • hybrid

3. Portability

If you ever move away from WordPress, your app doesn’t collapse.

4. Maintainability

No more hunting through plugins and templates to understand behavior.


A Better Way to Use WordPress

I’m not trying to replace WordPress.

I’m trying to use it correctly in modern systems.

WordPress is still great at:

  • content management
  • admin workflows
  • ecosystem

But your application logic shouldn’t live inside it.


Where This Is Going

KiwiPress is part of a larger system I’m building focused on:

  • contract-driven architecture
  • modular app engines
  • vendor-neutral systems

This is just one piece.

But it’s the first one that feels like a real product.


Final Thought

WordPress isn’t broken.

We just keep asking it to do too much.

Split the responsibilities…

…and suddenly everything gets a lot simpler.

Top comments (0)