Malcolm Peralty

I was at DrupalCon Chicago earlier this year representing Pressable as part of the Automattic for Agencies presence there.

If you don’t know, I spent over two years at Acquia as a Technical Account Manager (eventually becoming a Senior TAM) before moving to Pressable, so DrupalCon felt a bit like visiting a neighbourhood I used to live in. Familiar faces, familiar energy, a few knowing nods from people who remembered the WordPress guy on the Drupal team.

During the event, I had a conversation with an agency leader who runs both Drupal and WordPress projects. We were in a private space that Pressable had set aside, and at some point, the conversation drifted into what frustrates their team about WordPress when they come from the Drupal side of things.

The thing that kept coming up wasn’t performance. It wasn’t the block editor. It wasn’t even plugin quality. It was governance.

I’m paraphrasing here, but they said something along the lines of: “WordPress governance feels like you have to remove things, and if you forget anything, you’ve potentially left things wide open. Even if I do solve governance in WordPress, it’s not portable. With Drupal, I start from nothing and expand from there, making it easier to know what’s available.”

That really stuck with me because it captures a philosophical difference between the two platforms that I don’t think gets talked about enough. WordPress is permissive by default. Everything is on, everything is accessible, and governance means going through and turning things off, hoping you didn’t miss anything.

Drupal approaches it from the other direction. You start locked down and deliberately open up what you need. One is additive. The other is subtractive. And the subtractive approach is harder to get right, harder to audit, and harder to port between sites.

On top of that, so much of WordPress configuration lives in the database. Settings, toggles, options, feature flags, they’re all rows in wp_options that can be changed by anyone with admin access, lost during migrations, or quietly drift between environments without anyone noticing until something breaks. For teams managing fleets of client sites, that’s not just annoying. It’s a real operational problem.

I’ve lived on both sides of this fence. I spent years managing hundreds of WordPress sites before WordPress even had a built-in updater. And then more recently, I spent over two years deep inside the Drupal ecosystem at Acquia, where I got to see how a more structured approach to configuration management works in practice.

That conversation at DrupalCon stuck with me because I’d felt the same friction from both directions and never quite had the words for it.

So I Built Something

After the conference, I started thinking about what a file-based governance layer for WordPress might look like. Not a settings page. Not another plugin that writes its own options to the database. A PHP config file that lives in your codebase, gets tracked in Git, and controls how WordPress behaves across every environment it’s deployed to.

I want to be upfront about how this got built. I didn’t write the PHP myself. I used Claude Code and OpenAI’s Codex to do the actual development. My role was architecture, planning, product direction, and testing. I decided what the plugin should control, how the config file should be structured, what the module system should look like, and how the override logic should work. Then I directed the AI tools to build it, reviewed the output, tested the functionality, and iterated until it worked the way I wanted.

If you’ve read my post about using AI to write a novel, you know I’m pretty honest about where the line is between my contribution and the AI’s. This is similar. The ideas, the structure, the decisions about what matters, those are mine. The code execution was AI-assisted. I’m comfortable with that distinction, especially for a tool like this where the value is in the design decisions, not in whether I personally typed the PHP.

The result is WP Governance, an mu-plugin that lets you define your WordPress site’s operational rules in a single config file.

What It Can Do

Rather than walk through every feature, here’s the general idea. Anything you’d normally toggle in the WordPress admin that affects security, capabilities, uploads, content behaviour, or UI visibility can instead be declared in a PHP file that lives in your repo.

Want to disable XML-RPC, the file editor, and application passwords across every site in your fleet? That’s a few booleans in the config. Want to restrict upload types to only approved MIME types with a size cap? That’s in the config too. Want to strip admin menu items, lock the permalink structure, or inject security headers? Config. Want to deny specific capabilities per role without touching the database? Also config.

The whole point is that the policy lives in code. It goes through code review. It deploys through your pipeline. It doesn’t drift because someone clicked a checkbox in staging that nobody remembered to click in production.

Why I Think This Matters (A Little)

I’m not pretending this is going to change the WordPress ecosystem. It’s a tool I built because a conversation made me realize that I had the perspective to see the problem clearly and the tools to do something about it.

WordPress is incredible at accessibility and ease of use. That’s a feature, not a bug. But for teams managing serious infrastructure, especially agencies juggling dozens or hundreds of sites, the everything-in-the-database approach creates real operational friction. Drupal figured out a version of this years ago. WordPress hasn’t, at least not natively.

WP Governance isn’t trying to replace how WordPress works. It’s just offering a layer on top for teams that need more control over consistency, security, and deployment confidence.

What I’d Love to See Happen

This is on GitHub under GPL-3.0. I’d genuinely love for people who work across both ecosystems to take a look, poke at it, fork it, and evolve it into something better than what I started. Drupal developers who also manage WordPress sites, I’m especially looking at you. The config structure is intentionally straightforward, and the module system is designed to be extended.

I don’t have plans to submit this to the WordPress plugin directory right now. It’s an mu-plugin by design, meant for teams that deploy through Git and CI/CD pipelines. If that’s your world, I think you’ll find it useful.

If you have thoughts, feedback, or want to contribute, I’m easy to find. And if you’re the agency leader who sat across from me at DrupalCon and recognize this conversation, thanks. That chat turned into something real.

Featured image by ChatGPT’s image model.