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