My WordPress Development Setup in 2026: VS Code, AI, and Local Tools

Why I’m Sharing My Setup

Every few months, someone asks me what my development environment looks like. And every time, I realize my answer has changed dramatically since the last time I was asked. The tools I use today barely resemble what I was using two years ago, and that’s not because I chase shiny objects. It’s because the landscape of WordPress development has genuinely transformed.

I’ve been building WordPress plugins and themes for over a decade. I’ve gone through every phase, from editing files directly on production servers (don’t judge, we all did it) to elaborate Docker setups with CI/CD pipelines. And now, in 2026, my setup is simultaneously simpler and more powerful than anything I’ve used before.

This isn’t a “use exactly what I use” prescription. Your setup should match your workflow, your projects, and your brain. But I’ve found that sharing setups openly leads to those “oh, I didn’t know you could do that” moments that save people hours of frustration. So here’s everything, warts and all.

The Core: VS Code as Command Center

I know this isn’t a controversial choice. VS Code has become the de facto standard for a reason, it’s fast, extensible, and free. But the way I use it has changed significantly since I started incorporating AI tools into my workflow.

The Extensions That Actually Matter

I’ve gone through cycles of having 40+ extensions installed and then stripping back to essentials. Currently, I’m running about 15, and I can tell you exactly what each one does and why it’s there:

PHP Intelephense remains the backbone. If you’re doing any WordPress development without proper PHP intelligence, you’re working with a handicap. The premium version is worth every penny for the rename symbol, find implementations, and code generation features. I’ve tried PHP Language Server and others, nothing comes close.

WordPress Hooks IntelliSense is something I can’t live without. Auto-completing action and filter names, showing you the parameters each hook passes, and linking to documentation directly, it probably saves me twenty minutes a day just in not having to look up hook signatures.

ESLint + Prettier for the JavaScript side. With WordPress moving deeper into block development, having consistent JS formatting is no longer optional. I use the WordPress ESLint configuration as my base and layer project-specific rules on top.

GitLens for understanding code history. When you’re working across multiple plugins, knowing who changed what and why is invaluable. The inline blame and commit graph features have replaced my need for standalone Git GUIs.

Claude Code extension, and this is where things get interesting. I’ve written in detail about how I optimized my Claude Code workflow for WordPress, but having the AI assistant directly in my editor, with full context of my codebase, has fundamentally changed how I work.

VS Code Settings That Make a Difference

Beyond extensions, my settings.json has evolved over the years. The changes that made the biggest impact on my daily work:

Auto-save with a 1-second delay. I used to manually save obsessively. Now VS Code saves after every pause in typing. Combined with Local WP’s file watching, my changes are reflected in the browser almost instantly. The feedback loop went from “save → switch → refresh” to just “switch and look.”

Multi-root workspaces. Each project gets a workspace file that includes the plugin directory, the theme directory (if relevant), and a shared snippets folder. This means search and replace operations can span related codebases, and I can navigate between a plugin’s PHP and a theme’s block templates seamlessly.

Custom terminal profiles. I have terminal profiles preset for each local site, so when I open a terminal, it’s already in the right directory with the right PHP version. Small time savings that compound across hundreds of terminal sessions per week.

Local Development: Local WP + Docker Hybrids

For the past three years, Local by Flywheel (now Local WP) has been my primary local environment. It’s opinionated, it’s sometimes quirky, and I occasionally wish it gave me more control. But the truth is, it just works for 90% of what I need.

Why Not Full Docker?

I’ve used Docker-based setups extensively, wp-env, custom docker-compose configurations, even built my own WordPress Docker images. And for CI/CD pipelines, Docker is still my choice. But for daily development, the overhead of managing containers, dealing with volume mounting performance issues on macOS, and debugging Docker networking problems was eating time that should have been spent writing code.

Local WP gives me one-click site creation, easy PHP version switching, SSL with trusted certificates, and integration with WP-CLI. For quick testing, “does this plugin work with PHP 8.3?”, I can spin up a site in thirty seconds. Try doing that with a Docker setup.

When I Do Use Docker

Docker comes out for specific scenarios: multisite testing, replicating production configurations, running automated test suites, and any situation where I need exact environment parity. I maintain a library of docker-compose files for common WordPress hosting configurations, Nginx + PHP-FPM, Apache + mod_php, LiteSpeed, so I can quickly replicate a client’s environment when debugging hosting-specific issues.

I’ve also started using Docker for database management. Running MySQL 8.0 and MariaDB 10.6 simultaneously in containers, pointing different test sites at different engines, has caught compatibility issues before they hit production. This was a lesson learned the hard way after a migration from MySQL 5.7 to 8.0 broke several queries that used implicit GROUP BY behavior.

WP-CLI: The Unsung Hero

If I had to give up every tool except one, I’d keep WP-CLI. It’s not glamorous, but it’s the single most productivity-enhancing tool in the WordPress ecosystem.

Some of the WP-CLI workflows that save me the most time:

Scaffolding: wp scaffold plugin gives me a properly structured plugin directory in seconds. I’ve customized the templates to include my preferred boilerplate, autoloading, admin menu registration, activation/deactivation hooks, so new plugins start with the foundation already laid.

Database operations: wp search-replace for URL changes during migrations, wp db export/import for quick backups, wp transient delete --all when caching is behaving strangely. These operations would take minutes through phpMyAdmin and take seconds through CLI.

Bulk content management: Need to change the author of 500 posts? Update post meta across a custom post type? Regenerate thumbnails after changing image sizes? WP-CLI handles all of this in single commands.

Testing scenarios: wp user create with various roles, wp post generate for content density testing, wp option update for toggling settings without navigating admin screens. When you’re testing a plugin across different configurations, CLI automation is the difference between a five-minute test and a thirty-minute test.

AI in My Workflow: Not What You’d Expect

This is the section people are most curious about, so let me be honest about what AI actually does in my day-to-day development work and what it doesn’t do.

Where AI Genuinely Helps

Code exploration and understanding. When I’m diving into unfamiliar code, a new plugin, a WordPress core subsystem I haven’t worked with, or someone else’s custom theme, AI is like having a senior developer sitting next to me who’s already read all the code. I can ask “what does this function do in the context of this class?” and get an accurate answer in seconds instead of tracing through files for fifteen minutes.

Boilerplate and repetitive patterns. WordPress development involves a lot of structural code, registering post types, creating meta boxes, building REST API endpoints, writing admin settings pages. The patterns are well-established, and AI generates them accurately and quickly. What used to take twenty minutes of referencing documentation now takes two minutes of describing what I need.

Test generation. Writing unit tests for WordPress plugins is tedious. Not hard, tedious. AI excels at generating test cases, especially edge cases I might not think of. I describe the function’s purpose and constraints, and I get a comprehensive test suite that I then review and adjust. My test coverage has roughly doubled since incorporating AI into this workflow.

Documentation. Inline documentation, README files, hook documentation, AI generates first drafts that are 80% of the way there. I edit for accuracy, tone, and project-specific context. The result is that I actually write documentation now, whereas before I’d perpetually postpone it.

Debugging assistance. When I’m staring at a PHP error and can’t figure out the root cause, having AI analyze the error message, the relevant code, and the WordPress execution flow has saved me hours. It doesn’t always get the answer right on the first try, but it narrows down the problem space dramatically.

Where AI Falls Short

I want to be honest about this because the AI hype cycle tends to paint an unrealistically optimistic picture:

Architecture decisions. AI can implement an architecture you’ve designed, but it’s not great at choosing between architectural approaches. “Should this plugin use custom tables or post meta?” requires understanding of the specific project’s scale, query patterns, and future plans that AI doesn’t have. These decisions still need human judgment informed by experience.

WordPress-specific edge cases. WordPress has decades of backwards compatibility decisions baked into its codebase. AI sometimes suggests approaches that work in theory but break in practice because of some legacy behavior. A classic example: AI will suggest using wp_insert_post() with certain parameters that technically should work but don’t because of filters that popular plugins hook into. You need experience to know these traps.

Performance optimization. AI can tell you that a query is slow, but understanding why it’s slow in the context of a specific WordPress installation, with its unique combination of plugins, data volume, and hosting configuration, requires diagnostic skills that AI is getting better at but hasn’t mastered.

Security review. AI catches obvious security issues, unsanitized inputs, missing nonce checks, direct database queries without preparation. But WordPress security is nuanced. Understanding capability checks in the context of multisite, properly escaping output in blocks vs. classic themes, and handling file uploads securely requires deep WordPress-specific knowledge that AI sometimes gets wrong.

My AI Workflow

Here’s how AI actually fits into my daily routine:

I’ve also shared how MCP servers transformed my WordPress development workflow, they’re a key part of this setup.

Morning: Review yesterday’s code with AI context. If I was deep in a complex feature, AI helps me rebuild my mental model of where I left off. This alone saves twenty to thirty minutes of “what was I doing?” time.

During development: AI handles the mechanical parts, generating boilerplate, writing standard WordPress patterns, creating test cases. I handle the creative parts, architecture decisions, user experience flow, performance optimization.

Code review: Before committing, I run my changes through AI review. It catches things like missing text domain in translations, inconsistent naming conventions, and potential hook conflicts. It’s not a replacement for human code review, but it catches the easy stuff so human reviewers can focus on higher-level concerns.

Debugging: When something breaks, AI is my first sounding board. I paste the error, the relevant code, and any context about what I changed. Eight times out of ten, it identifies the issue or narrows it down to two or three possibilities.

As I wrote about in my piece on running product, strategy, and execution with AI, the key insight is that AI is a multiplier, not a replacement. It multiplies the output of a skilled developer. But if you don’t have the underlying skills, understanding WordPress internals, debugging methodology, architecture principles, AI will multiply zero. The developers who get the most value from AI are the ones who could do the work without it but use it to do that work faster and with fewer errors.

Version Control and Collaboration

Git is non-negotiable. But how you use Git in WordPress development has nuances that general Git guides don’t cover.

Branch Strategy for Plugin Development

I use a modified Git Flow approach for plugins:

• main: Always matches what’s on the WordPress.org SVN repository or the latest release on GitHub. This branch is sacred.
• develop: Integration branch for the next release. Features merge here first.
• feature/*: Individual features or enhancements. Named descriptively, feature/rest-api-members-endpoint, not feature/new-stuff.
• hotfix/*: For critical fixes that need to go to production before the next planned release.
• release/*: Short-lived branches for version preparation, updating readme.txt, bumping version numbers, final testing.

What I’ve added to this standard approach is environment branches for plugins that run on multiple client sites with different configurations. This lets me maintain site-specific customizations without forking the entire plugin.

Commit Messages That Help Future You

I follow a convention that’s served me well for years. Each commit message starts with a category:

• feat:, new functionality
• fix:, bug fix
• refactor:, code restructuring without changing behavior
• docs:, documentation changes only
• test:, adding or modifying tests
• chore:, build process, dependency updates, tooling changes

The body of the commit message includes the “why”, not just what changed, but the reasoning behind the change. “Changed query to use WP_Query instead of direct SQL” is less useful than “Changed to WP_Query to respect object cache and plugin filters that modify post queries.”

Pre-Commit Hooks: Automated Quality Gates

Every plugin repository I maintain has pre-commit hooks that run automatically:

1. PHP syntax check (php -l), catches syntax errors before they enter the repository
2. PHPCS with WordPress coding standards, enforces consistent code style and catches common WordPress anti-patterns
3. PHPStan at level 5, catches type errors, undefined methods, and unreachable code
4. JavaScript ESLint, ensures block editor and admin JS follow WordPress conventions

These hooks reject the commit if any check fails. It feels strict, but it means every commit in the repository meets a minimum quality bar. No more “fix linting” commits cluttering the history.

Testing: What I Actually Test and What I Don’t

Let me be honest: I don’t have 100% test coverage on any of my plugins. And I don’t think that’s a reasonable goal for WordPress plugin development. Here’s my testing philosophy and what it looks like in practice.

What Gets Comprehensive Tests

Data operations. Any function that creates, modifies, or deletes data gets thorough testing. This includes custom database queries, post meta operations, options CRUD, and user meta management. Data bugs are the most damaging and the hardest to reverse, so this is where testing investment pays off the most.

REST API endpoints. Every endpoint gets tests for authentication, authorization, valid input handling, invalid input handling, and error responses. REST APIs are public interfaces, they need to be bulletproof.

Security-critical paths. Nonce verification, capability checks, input sanitization, output escaping, anything that’s part of the security surface gets tested. I use PHPUnit for unit tests and integration tests that verify the full WordPress request lifecycle.

What Gets Lighter Testing

Admin UI rendering. I verify that admin pages render without errors, but I don’t test every visual detail. Browser testing tools handle the visual verification, and the cost-to-value ratio of automated UI tests in WordPress admin is unfavorable.

WordPress integration points. I test that my hooks fire correctly, but I don’t test that WordPress itself handles them properly. That’s WordPress’s job. I test the interface, not the framework.

What I Skip

Trivial getters and setters. If a function just returns a value with no logic, testing it adds maintenance cost without catching bugs.

Third-party plugin interactions. I can’t reasonably test my plugin against every possible plugin combination. Instead, I use defensive coding practices and handle failures gracefully when expected data or hooks aren’t available.

Deployment and Release Management

For WordPress.org plugins, deployment still involves SVN. I’ve automated this with a GitHub Action that triggers on tagged releases, it runs the full test suite, builds assets, and pushes to SVN automatically. The entire release process from “tag the release” to “live on WordPress.org” takes about four minutes with zero manual intervention.

For premium plugins distributed through custom channels, I use a combination of GitHub Releases and a custom update server. The update server implements the WordPress Plugin Update API, so premium plugins check for updates through the standard WordPress mechanism. Users see the update in their dashboard just like any WordPress.org plugin.

Version Numbering That Communicates

I strictly follow semantic versioning. Major versions (2.0, 3.0) indicate breaking changes or major features. Minor versions (2.1, 2.2) add functionality backwards-compatibly. Patch versions (2.1.1, 2.1.2) fix bugs.

This communicates expectations to users. They know a patch update is safe to apply immediately. A minor update might need a settings check. A major update warrants reading the changelog before updating.

Performance Monitoring and Debugging Tools

Beyond the development tools themselves, I maintain a toolkit for performance analysis and debugging that runs alongside my development environment.

Query Monitor is installed on every local site. There’s simply no better tool for understanding what WordPress is doing during a page load, queries, hooks, HTTP requests, template parts, conditional checks. I check Query Monitor reflexively after any significant code change.

Xdebug with step debugging through VS Code. I know some developers prefer var_dump debugging, but once you’ve traced a complex WordPress hook sequence in a step debugger, you never go back. The integration with VS Code through the PHP Debug extension is seamless, set a breakpoint, refresh the page, and you’re walking through execution line by line.

Error logging with a custom mu-plugin that formats debug.log entries with timestamps, stack traces, and request context. The default WordPress error logging is minimal, my custom logger adds enough context that I can usually understand the error without reproducing it.

The Setup I’d Recommend for New WordPress Developers

If you’re just starting out, my full setup would be overwhelming. Here’s the minimum viable development environment I’d recommend:

1. VS Code with PHP Intelephense, WordPress Hooks IntelliSense, and ESLint
2. Local WP for running WordPress locally
3. Git with a GitHub account for version control
4. WP-CLI for command-line WordPress management
5. Query Monitor for understanding what your code is actually doing

That’s five tools. Everything else is optimization. Master these five first, understand why each one matters, and then gradually add tools as you encounter problems they solve. Adding tools to solve problems you don’t have yet is how you end up with a setup that’s more complex than your actual code.

Frequently Asked Questions

Why VS Code and not PhpStorm?

I’ve used both extensively. PhpStorm is objectively more powerful for PHP development, better refactoring tools, deeper code analysis, more sophisticated debugging integration. But VS Code with the right extensions gets to about 85% of PhpStorm’s capability at zero cost and with significantly better AI tool integration. For WordPress-specific development, that last 15% rarely matters enough to justify the cost and the heavier resource usage. If you’re doing heavy PHP work beyond WordPress, Laravel, Symfony, custom frameworks, PhpStorm is worth considering.

How do you handle WordPress multisite locally?

Local WP supports multisite out of the box, you can convert any site to multisite with a few clicks. For testing subdomain multisite (which is more common in production), I use Local WP’s SSL feature combined with custom hosts file entries. For automated testing against multisite, I maintain a Docker configuration specifically for multisite scenarios since Local WP’s multisite support doesn’t cover every edge case.

What about using AI to write entire plugins?

I’ve experimented with this extensively. AI can generate a functional plugin from a description, but “functional” and “production-ready” are very different things. The generated code typically works for the happy path but misses edge cases, has inconsistent error handling, and doesn’t follow WordPress coding standards perfectly. My approach is to use AI for individual components, a specific class, a particular admin page, a REST endpoint, and assemble them with human oversight. The architecture and integration decisions stay human; the implementation of defined components can be AI-assisted.

How do you keep your tools updated without breaking your workflow?

I have a monthly “tool maintenance” routine. First Monday of each month, I update VS Code extensions, check for Local WP updates, update npm global packages, and review my WP-CLI packages. I do this on a designated test site first, never on a site with active development. If an update breaks something, I roll back and check the changelog for migration notes. The key is never updating tools mid-project. Finish your current sprint or milestone, then update.

What about Cursor, Windsurf, or other AI-first editors?

I’ve tested them. They’re interesting but not yet WordPress-optimized. The AI features are impressive for general development, but they lack WordPress-specific context, hook knowledge, coding standards awareness, and understanding of the WordPress execution lifecycle. VS Code with Claude Code extension gives me AI assistance that actually understands WordPress conventions. I revisit these alternatives every few months, and the gap is closing, but for now VS Code remains my choice for WordPress-specific work.