Programming

When the Platform You Built Your Career On Puts You in a Box

A

Admin User

Author

Jul 10, 2026
4 min read
11 views
When the Platform You Built Your Career On Puts You in a Box

I got rejected from the WordPress.org plugin directory once. Not for a bad plugin—for one that worked too well. The reviewer said my code was "doing theme work" and needed to be restructured. I remember staring at that email thinking: I just moved this exact function into a plugin from a theme to comply with guidelines, and now I'm being told it's architecturally wrong in this new location too. That moment made me understand something about WordPress that took me years to articulate: the platform had drawn a line, and I was standing on the wrong side of a line that kept moving.

Reading about another developer getting rejected from the block theme repository brought all of that back. But this time, it's worse. Because it's not just about following rules—it's about watching a brilliant piece of engineering (Gutenberg) get deliberately crippled by the very organization that built it.

The Setup: How We Got Here

Let me be direct about where I stand on this. Ten years ago, when WordPress themes were basically anything a developer could shove into a package, the ecosystem was a mess. Themes bundled page builders, SEO tools, slider plugins—basically everything except a kitchen sink. The decision to separate concerns, to say "themes handle presentation, plugins handle functionality," made architectural sense.

I still think that principle is sound.

The problem isn't the principle. The problem is the execution.

The Modern Block Theme Trap

Here's what's happening in practice: a developer creates a block theme that genuinely improves the user experience. They use custom blocks, dynamic rendering, and intelligent defaults. The WordPress.org review team rejects it because those features "belong in a plugin."

So the developer does exactly that. Same code, different folder structure. Resubmit. Approved.

The end user now has to install three separate packages instead of one. They're dependent on all three remaining compatible. If they disable the companion plugin, their site breaks—exactly like deleting a classic theme in 2015, except the broken pieces are now scattered across their plugins and block library panels.

We didn't solve lock-in. We gave it better paperwork.

What This Reveals About WordPress's Direction

Gutenberg is one of the most technically ambitious projects WordPress has ever attempted. The Block API is genuinely powerful—I've built custom blocks that would have been impossible with classic theme hooks. It's sophisticated tooling.

But here's what hurts to acknowledge: the most advanced blocks, the most creative uses of that API, aren't in the official theme directory. They're in commercial themes outside the repo, in companion plugins, anywhere but where regular WordPress users actually look first.

The rules created a ceiling lower than what's technically possible. Theme developers can see the rocket. We just can't fly it.

My Take: The Uncomfortable Truth

I agree with the direction. Seriously. Long-term, WordPress probably needs cleaner separation between presentation and function. That's solid architecture.

But I also think WordPress.org has created a system that's legally clean and practically confusing. Users didn't ask for this. They voted with their installs—the most popular themes are still classic themes from a decade ago. Astra, GeneratePress, OceanWP. Millions of active installs.

The block era promised simpler, cleaner websites. What users got was another learning curve and more dependencies.

Here's what I'd do differently: create a "theme+" category that's explicitly allowed to include sensible companion functionality. Not everything. Not a page builder bundled into a theme. But thoughtful, integrated features that genuinely improve the theme experience? That should be allowed in the repo with clear documentation about what you're installing.

What This Means for Building

If you're building WordPress themes in 2024, stop pretending the companion plugin approach isn't your future. It is. The tooling is there (probably in Composer), and the path forward is clear, even if it's not satisfying.

But also: the most interesting WordPress work is happening outside the directory. If your theme idea requires bending rules to work well, consider whether staying in the directory serves you. Sometimes it doesn't.

The question I'm sitting with now is whether WordPress's governance is keeping the platform safe or keeping it small. I'm genuinely not sure which it is yet.

Source: This post was inspired by "WordPress Built a Rocket, Then Banned Us From Flying It" by Dev.to. Read the original article

Share this article

Written by Adil Sher

Full stack developer building high-traffic platforms, AI services, and custom web applications. Explore my portfolio, learn about my background, or get in touch.

Related Articles

Code Isn't Engineering Until You Stop Thinking It Is
Programming Jul 17

Code Isn't Engineering Until You Stop Thinking It Is

Someone asked me last week what I actually do for a living. Not in the polite "oh that's nice" way—genuinely curious. I said "I'm a developer" and watched their face go blank. They nodded like I'd said "I work in an office." It hit me that I couldn't explain my job any better tha...

PHP Forms Aren't Broken—Your Expectations Are
Programming Jul 16

PHP Forms Aren't Broken—Your Expectations Are

I spent two hours last week debugging a form that "wasn't working." The client said data wasn't being saved. I pulled up the network tab, saw the POST request going out clean, checked the database, and found... nothing. Then I looked at the form's action attribute. It was pointin...