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

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 832808) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Drew Marshall Posted on Apr 28 I Stopped Fighting WordPress… So I Rebuilt How I Use It #wordpress #opensource #javascript #webdev 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 (1) Subscribe Personal Trusted User Create template Templates…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.