What WordPress Got Wrong About Plugins (And What We're Trying)

Let's get one thing straight: the idea behind WordPress plugins is brilliant. It's a promise of infinite extensibility, a blank canvas where anyone can add any feature they can dream up. It's the reason WordPress powers something like 43% of the web. But after two decades, we have to admit that this promise has a dark side. The very thing that made WordPress a giant is also its most profound, deeply-rooted architectural flaw.

We've all been there. You get a call from a client—or worse, an automated alert at 3 AM—that their site is down, defaced, or sending out spam. You log in, heart pounding, and start the grim process of elimination. Disable all plugins. Re-enable one by one. It's almost always a plugin. Maybe it was an obscure one the client installed for a blinking-text widget, or maybe it was a popular one with a zero-day vulnerability. The specific culprit doesn't matter as much as the underlying cause.

The original sin of the WordPress ecosystem is that every plugin is just a bundle of PHP files running with the exact same permissions as the WordPress core itself. It's untrusted code, often written by a stranger with unknown skills and motivations, executing in the same process that handles your content, your users, and your database. There is no sandbox. There is no containment. A single poorly-written line in a free SEO plugin can read your wp-config.php file and hand over your database credentials to an attacker. That's not a bug; it's the design.

This technical problem is compounded by a broken economic model. A developer builds a genuinely useful plugin. It gets popular. Suddenly, they're on the hook for support, security patches, and compatibility updates for a user base of thousands, all for free. It's completely unsustainable. So what happens? The developer either burns out and abandons the project (creating a ticking security time bomb for everyone still using it), or they sell it. Often, the buyer is a private equity firm or a large plugin conglomerate that immediately guts the free version, plasters it with aggressive upsells, and slowly lets the code quality slide. The user is left holding the bag every single time.

Look no further than WooCommerce for the perfect case study in this sprawl. It's sold as a simple way to add a store to your site. But to build a functional, modern e-commerce operation, you don't just install WooCommerce. You need a plugin for Stripe payments. Another for advanced shipping calculations. One for subscriptions. Another for abandoned cart emails. One for custom product fields. Before you know it, you're juggling seven, ten, maybe fifteen different plugins from a dozen different vendors, each with its own update cycle, potential conflicts, and security surface area. Your simple store has become a fragile house of cards, and you're the one who has to live in it.

When we started mapping out VeloCMS, we knew we couldn't ignore the need for extensibility. But we also refused to repeat the mistakes of the past. The problem isn't the idea of plugins; it's the lazy, insecure implementation that has become the industry standard. Our approach starts by treating third-party code with the healthy suspicion it deserves.

We're building our plugin architecture around two core principles: isolation and explicit permissions. For isolation, we're designing the system to run third-party code in sandboxed V8 Isolates. Think of it like a secure container. A plugin lives and runs inside this little box, and it can't see or touch anything outside of it unless it's explicitly allowed to. If a plugin has a vulnerability, the damage is contained to its own sandbox, not your entire application. It's the difference between a leaky faucet in one apartment and a flood that brings down the whole building.

The second piece of the puzzle is what we're calling a capability manifest. Before you even install a plugin, it will have to declare exactly what it needs to do. Does it need to read posts? Does it need to write to a specific database table? Does it need to make an external network request to a third-party API? It's all listed in a plain-text file. This is fundamentally about consent. It puts the power back in the hands of the site owner, just like your phone asks for permission before an app can access your camera or contacts. No more silently installing a plugin that turns out to be scraping your user data.

This leads to an open-core model. The essential, high-stakes functionality—the stuff that absolutely needs to be secure and stable—will be built and maintained by our team as first-party features. For everything else, the sandboxed, permission-based plugin system will provide a safe way for the community to extend the platform. This is a core part of how we see ourselves as a serious WordPress alternative.

Now, for a dose of honesty. This secure plugin sandbox is a cornerstone of our v2 architecture. It is not shipped today. Building a truly isolated, high-performance runtime for untrusted code is a massive undertaking, and we're not going to cut corners. But we're not just waving our hands and making promises, either. The groundwork is being laid right now. The capability manifest specification is already part of our core design, shaping how we think about every feature we build. We believe in getting the foundation right first, something that many platforms forget in their rush to add features. You can see the work we're putting into that foundation over on our pages for developers.

Fixing the plugin problem isn't about having more plugins. It's about having better, safer ones. It's about creating an ecosystem where developers can build and distribute extensions without inadvertently putting users at risk, and where users can extend their sites with confidence. It requires a fundamental shift in thinking, moving from a model of implicit trust to one of explicit, verifiable permissions. It's a harder path, but it's the only way to build a CMS that's truly fit for the next decade.