How Claude Helped Me Build a WordPress Plugin I Actually Needed
There’s a task that every WordPress developer knows intimately — the weekly ritual of logging into each client site, running updates, taking notes, drafting an email, and sending it off to the client with a summary of what changed. If you manage one site, it’s a minor inconvenience. If you manage ten, fifteen, or twenty, it becomes a significant portion of your week — repetitive, manual, and completely unscalable.
For years I handled it the old way. Log in. Update. Screenshot. Write up. Send. Log out. Repeat. I had looked at services like ManageWP that centralize multi-site WordPress management, but the subscription costs stack up quickly when you’re running a boutique agency, and the tradeoff between cost and control never felt right for how I work.
Then I discovered Claude.
A Different Kind of Coding Partner
I’d been using AI tools in my work for a while — Sumo AI had been part of my workflow for content production — but I’d never applied AI to a WordPress development project. When I started thinking seriously about building my own maintenance plugin, I decided it was the right opportunity to find out what working with Claude on a real, production-grade WordPress plugin actually looked like.
What I found surprised me. Claude wasn’t just a code generator. It was a genuine development partner — one that could explain why a piece of code worked a certain way, catch problems before they became bugs, and push back when I was heading in the wrong direction. When I described what I needed — a plugin that would manage updates, log every action, send branded email reports to clients, and handle spam filtering — Claude didn’t just produce code. It helped me think through the architecture, suggested the right WordPress APIs to use, and flagged patterns that would cause problems later.
For someone who knew enough about WordPress to know what I wanted but not always how to build it at the level of quality I needed, this was transformative.
From Spreadsheet to Software: What the Plugin Does
The core problem Greenskeeper solves is the gap between WordPress’s built-in update screen and what a professional agency actually needs when maintaining client sites.
WordPress’s Updates screen tells you what needs updating and lets you apply those updates. What it doesn’t do is keep a searchable log of everything that happened, build a branded email report for your client, handle SMTP delivery so the email actually arrives, or give you a layered spam filter with a audit trail. You either cobble that together yourself — spreadsheets, email drafts, copy-paste — or you pay for a managed service.
Greenskeeper bridges that gap in a single plugin. It manages Core, plugin, and theme updates in separate sections with per-item checkboxes and a real-time progress bar. Every update is automatically logged to a session history with success and failure details. After running updates, one click builds and sends a branded HTML maintenance report to your client — your agency logo, your company name, the full list of what was updated, any notes you want to include, and a spam activity summary if you’re using the built-in filter.
The spam filter itself is a two-layer system: local rules (honeypot fields, submission timing, link counting, keyword and IP blocklists) backed by optional Akismet cloud filtering. There’s a full Spam Log page showing every blocked attempt with one-click IP blocking. And because agencies run on different server infrastructure, there’s built-in SMTP configuration supporting nine providers — SendGrid, Mailgun, Brevo, Gmail, Microsoft, and more — so you never have to add a separate SMTP plugin.
On multisite networks, the plugin adds a Site Scope Selector across every management page so you can view and manage any single site or the full network from Network Admin.
The Name That Wasn’t Generic Enough
The plugin didn’t start life as Greenskeeper. It started as Site Maintenance Manager.
When I submitted the plugin to the WordPress.org directory for review, the team came back with feedback that the name was too generic — too close to existing tools and not distinctive enough to stand on its own. They were right. “Site Maintenance Manager” described what the plugin did, but it didn’t say anything about who built it or why it was different from anything else.
Claude and I worked through the naming problem together. I wanted something that captured the idea of careful, methodical maintenance — the kind of invisible, expert work that makes everything run smoothly for everyone else. We landed on Greenskeeper.
In golf, the greenskeeper is the professional responsible for maintaining the course — the fairways, the greens, the hazards, every inch of the 9 or 18 holes that players take for granted because they’re always in perfect condition. The greenskeeper works early in the morning before anyone else arrives, fixes what needs fixing, and disappears before the first tee time. Nobody thinks about the greenskeeper when the course is in great shape. That’s exactly the point.
That’s what a good WordPress maintenance workflow should feel like for your clients. They never think about updates because you’re handling it. Everything just works.
The WordPress plugin team accepted the new name, reserved the slug, and the plugin is now in review at wordpress.org/plugins/greenskeeper.
Building in Public: The GitHub Repository
Throughout development, Claude also taught me how to manage the project properly in version control. I hadn’t previously worked with a GitHub repository dedicated to a single WordPress plugin, and setting up the right structure — folder naming, the main plugin file, the readme.txt format that WordPress.org requires, branch management — was all new territory.
The plugin is now maintained in its own public repository at github.com/digitalstrategyworks/greenskeeper, where every version is tracked, documented, and available. The repository includes both a GitHub-formatted README with full feature documentation and a WordPress.org-format readme.txt with installation instructions, FAQs, an external services disclosure, and a complete changelog going back through every release.
Having a properly maintained public repository matters for more than just version control. For a plugin heading toward WordPress.org listing, it signals to potential users and contributors that the project is actively developed and professionally maintained. It’s also where the issues log lives — a useful feedback channel as the plugin moves from internal use toward public availability.
The Problems We Solved Together (And Why They Matter)
Building a production-quality WordPress plugin means navigating a set of requirements that go well beyond “does it work.” The WordPress.org review team maintains strict standards for security, coding practices, and documentation — standards that exist because plugins run on hundreds of millions of websites and a single vulnerability or poorly-written query affects everyone.
Several of the issues we resolved together speak directly to the broader WordPress ecosystem:
Premium plugin deactivation. This was the most critical bug we found. When Greenskeeper attempted to update a premium plugin like Gravity Forms, ACF Pro, or Sucuri, the plugin would sometimes be deactivated after the update ran. The root cause was subtle: premium plugin vendors generate signed, time-limited download URLs that can expire between the moment the update scan runs and the moment the actual upgrade fires. When WordPress’s upgrader receives a 401 or 403 response trying to download from a stale URL, it calls deactivate_plugins() as part of its own error recovery — standard WordPress behaviour, but catastrophic in this context. The fix was to check whether the package URL is still valid before attempting the upgrade, and if it isn’t, force a fresh wp_update_plugins() call to get a new signed URL from the vendor’s server — exactly what WordPress core does before its own upgrade process. Any plugin that triggers WordPress updates programmatically needs to handle this correctly.
$_SERVER variable sanitization. The WordPress.org review team flagged that $_SERVER variables — HTTP_USER_AGENT, HTTP_REFERER, REMOTE_ADDR — were being used without sanitization in the spam filter’s Akismet integration. Although these come from the server environment rather than user form input, they can be manipulated by the sender of the request and must be treated as untrusted input. This is a common oversight in plugin code across the ecosystem and something the review process correctly catches.
Prepared SQL statements. Several database queries were using table name variables in ways that the static analysis tools couldn’t verify as safe, even though the values came exclusively from $wpdb->prefix plus fixed strings. The fix — wrapping table names with esc_sql() at the point of variable assignment — addresses the checker’s concern and is the correct defensive pattern for all custom table queries in WordPress.
External services documentation. The plugin connects to Akismet’s API for optional cloud spam filtering. WordPress.org requires that any external connection be fully documented in the readme: what service it is, what data is sent, when it’s sent, and links to the service’s terms of service and privacy policy. This requirement exists to protect users — they should always know exactly what data their installed plugins are transmitting and to whom. Adding a complete == External Services == section is now part of the plugin’s submission package.
Batch update timeout handling. On shared hosting environments, running updates on multiple plugins in sequence was failing after the first item with a generic “Request failed” error. The cause was a combination of jQuery’s default AJAX timeout (which has no explicit limit and varies by browser) and PHP’s max_execution_time being hit on slower servers. The fixes — switching to $.ajax() with an explicit 120-second timeout, adding an 800ms delay between sequential updates, and calling set_time_limit(300) in the PHP handler — ensure that updates complete reliably on the hosting environments where agency clients actually live.
What’s Next for Greenskeeper
The plugin is currently v1.9.7 and in review at WordPress.org. Once it’s approved and listed in the directory, the next development phase focuses on a Pro tier through Freemius integration.
The first Pro features planned include scheduled automatic updates — so maintenance runs on a cron schedule without anyone needing to log in — and a Performance Reporting module that pulls Google PageSpeed Insights data and includes a performance summary in the client email report. These are capabilities that agencies currently pay for through managed services like ManageWP, and building them into a self-hosted plugin means you own the workflow completely.
There’s also a Plugin Intelligence layer in planning that would manage license status awareness for premium plugins, understand update prerequisites and dependencies, and surface contextual guidance about known update issues before you run them.
What Working With Claude Taught Me
The most important thing I learned from this project wasn’t a specific piece of code or a WordPress API. It was that AI-assisted development works best when you bring your domain expertise and let the AI bring its technical depth — and when you’re willing to push back and ask questions rather than just accepting the first answer.
When Claude made architectural decisions I didn’t understand, I asked why. When a bug turned out to be more subtle than the first fix suggested (the premium plugin deactivation issue went through two rounds before we got the root cause right), we worked through it together until we had an explanation that made sense technically and a solution that would actually hold. When the WordPress.org review team came back with legitimate criticisms, we addressed every one of them and understood the reasoning behind each requirement.
That process — question, understand, fix, understand why — is what produced a plugin I’m confident putting in front of clients.
Greenskeeper is available at github.com/digitalstrategyworks/greenskeeper and will be listed on WordPress.org once the review is complete. If you’re a WordPress developer or agency owner who’s been handling maintenance the manual way, keep an eye on it.
The greenskeeper is almost ready for opening day.
Tony Zeoli is the founder of Digital Strategy Works LLC and Netmix LLC. He has been building on the web since the early days of the internet and currently focuses on WordPress strategy, development, and digital media infrastructure.
Questions or feedback? Reach out at digitalstrategyworks.com.
Tony Zeoli founded Digital Strategy Works to provide small and medium size businesses with end-to-end digital strategy consulting. With over 16+ year of experience working on digital media projects for start-ups, non-profits, institutions, and corporations, Zeoli brings a wealth of experience that cuts across the digital media spectrum.