For the past few weeks, I’ve been building a WordPress plugin called Webhole Homepage Manager.

What started as a clean, lightweight solution for maintenance mode and homepage control quickly turned into a deeper journey—one that forced me to make a decision many WordPress developers eventually face.

Do I keep bending to arbitrary review requirements… or do I ship software the way I believe it should be shipped?

The Plugin Was Never the Problem

The plugin worked. It was secure. It was predictable. It did exactly what it claimed to do—no bloat, no dark patterns, no lock-in.

But during submission to WordPress.org, the goalposts kept moving:

“Recommended” features treated like blockers

Architectural nudges toward patterns we didn’t want or need

Time spent justifying decisions instead of improving the product

Eventually, it became clear: This wasn’t about quality. It was about conformity.

Choosing Independence

So we made a call.

Webhole Homepage Manager is now distributed exclusively via GitHub.

That decision gave us:

Full architectural freedom

Faster iteration

No artificial constraints

No compromises on intent

The plugin is lean, readable, and stable — and it stays that way.

What This Means Going Forward

The project is open-source

Releases are versioned and transparent

No telemetry, no nags, no upsells

Built for developers who value control

If you’re a WordPress developer who’s felt friction with the ecosystem lately — you’re not alone.

Sometimes the best way forward… is sideways.

GitHub: https://github.com/cliffordwebhole/webhole-homepage-manager