{"id":33671,"date":"2025-05-26T11:22:56","date_gmt":"2025-05-26T14:22:56","guid":{"rendered":"https:\/\/deliciousbrains.com\/?p=33671"},"modified":"2025-05-26T13:01:50","modified_gmt":"2025-05-26T16:01:50","slug":"vs-code-wordpress","status":"publish","type":"post","link":"https:\/\/deliciousbrains.com\/vs-code-wordpress\/","title":{"rendered":"Set Up Visual Studio Code and xDebug as the Ultimate Editor for WordPress Development"},"content":{"rendered":"

Visual Studio Code<\/a> is a free, open source code editor that is lightweight like Sublime Text<\/a>, but offers many of the same features as bigger IDEs like PhpStorm<\/a> or WebStorm<\/a>.<\/p>\n\n

In this article, I’ll review some features of VS Code that I love, and show you how to make the most out of it for WordPress dev.<\/p>\n\n

Basic Setup for WordPress Development<\/h2>\n\n

Most of the time when coding in WordPress, you’re working on a plugin or a theme. One way to do this might be to open that plugin or theme in your IDE and start coding away. There is a better way though, with the help of VS Code “Workspaces”.<\/p>\n\n

You can think of a Workspace in VS Code as a container for your project – it not only includes your project, but it can include files that your project relies on (your WordPress installation), and any extensions or settings specific to that project.<\/p>\n\n

I like Workspaces because you can create one of them for each project and change any setting or extension in VS Code at the Workspace level. For example, you may not want to use the WordPress Coding Standards on all of your projects, or maybe you work with a team of developers that can\u2019t agree on tabs vs. spaces.<\/p>\n\n

In my case, the vast majority of my time is spent on plugin development<\/a>. So I’ll have a Projects<\/code> folder that has all of the plugins I work on, and a Sites<\/code> folder that contains all of my sites. I’ll then symlink the plugin I’m working on into a fresh WordPress website in the Sites folder.<\/p>\n\n

In Visual Studio Code, I’ll first open the plugin itself, and then I’ll add the WordPress site by selecting File<\/code> -> Add Folder to Workspace<\/code>. That sets up a new Workspace where I can edit the plugin and the WordPress installation at the same time.<\/p>\n\n

This is handy for quick edits to the wp-config.php<\/code> file, and keeping an eye on the debug.log<\/code> file while I’m developing.<\/p>\n\n

Next, click File<\/code> -> Save Workspace As<\/code> to save that Workspace. This creates a *.code-workspace<\/code> file (JSON-based) that stores path folders and settings. This allows you to open your Workspace again in the future, and also serves as a config file that will come in handy later. If you\u2019re collaborating, you can version-control this file\u2014just ensure paths like \/Sites\/my-site<\/code> aren\u2019t machine-specific.<\/p>\n\n

Deeper PHP and WordPress Integration<\/h2>\n\n

With that out of the way, let’s take a look at how we can make Visual Studio Code and WordPress play a bit nicer. Out-of-the-box, VS Code doesn’t support WordPress and PHP as well as some other IDEs like PhpStorm<\/a> (Find out how some of our team uses PhpStorm for WordPress Development<\/a>). Luckily, that’s easy to change by installing some extensions.<\/p>\n\n

Since WordPress is still mostly PHP, I use the PHP Intelephense<\/a> extension, which adds PHP auto-completions, symbol navigation support, and a much better way to find references in your workspace.<\/p>\n\n

While that will add auto-completions for PHP core functions and anything that you have defined in your project, it won’t pick up on much from WordPress core. For that, there is the Hooks IntelliSense for WordPress<\/a> extension. It autocompletes WordPress hooks (actions\/filters) and their priority parameters. There\u2019s also PHP Tools for Visual Studio Code<\/a>, which provides advanced IntelliSense<\/a> for WordPress core functions, classes, and constants. It even resolves argument orders for functions like get_posts()<\/code>, so you spend less time checking the Codex.<\/p>\n\n

To enforce WordPress best practices, use the WordPress Coding Standards<\/a> with the PHP Sniffer<\/a> extension. This combination highlights issues like missing sanitization or incorrect file naming in real time. Just install phpcs<\/code> globally and configure the extension to use the WordPress<\/code> standard in your workspace settings.<\/p>\n\n

These tools make it much easier to work with WordPress plugins and themes, and PHP development in general.<\/p>\n\n

Debugging PHP<\/h2>\n\n

Xdebug is an invaluable tool to have for debugging PHP<\/a>, but it can be tricky to set up. Luckily, VS Code makes it easy to configure Xdebug, and in my case it just works<\/em>.<\/p>\n\n

You only need to install the PHP Debug<\/a> extension and reload the editor. You can then go to the “Run” tab and click “create a launch.json file<\/strong>” to create a new PHP debug configuration.<\/p>\n\n

\"Create<\/p>\n\n

You should then see a pop-up towards the top of your editor asking you to select a Workspace folder to create the configuration in:<\/p>\n\n

\"Select<\/p>\n\n

Select “workspace” to insert the new configuration into your *.code-workspace<\/code> file, and then “PHP” to add a PHP configuration. This will add some debug config to that file, including the new “Listen for XDebug” option. You can edit the name of the configuration or change the XDebug port here. Here\u2019s how to adjust the config based on a common MAMP setup:<\/p>\n\n

\n{\n    \"name\": \"Listen for XDebug\",\n    \"type\": \"php\",\n    \"request\": \"launch\",\n    \"port\": 9003, \/\/ Xdebug v3+ uses 9003!\n    \"pathMappings\": {\n        \/\/ Docker example:\n        \"\/var\/www\/html\": \"${workspaceFolder}\/wp\",\n        \/\/ Local example (MAMP\/XAMPP):\n        \"\/Applications\/MAMP\/htdocs\/mysite\": \"${workspaceFolder}\"\n    },\n    \"log\": true \/\/ Enable logging for troubleshooting\n}\n<\/code><\/pre>\n\n
In my case, it also added a “Launch currently open script” config as well. With WordPress, we rarely need to load a PHP file directly, so I just deleted that config.<\/p>\n\n
That’s it! You should be able to start debugging PHP from here. Head over to a PHP file in your WordPress plugin or theme, and click to the left to a line number to add a breakpoint to that line.<\/p>\n\n
\"Setting<\/p>\n\n
When you head back over to the “Run” tab, select “Listen for XDebug” from the dropdown and click the play icon to start listening for requests.  For breakpoints to work, append ?XDEBUG_SESSION=VSCODE<\/code> to your site\u2019s URL, or add a browser extension<\/a>. When your code hits that breakpoint, the runtime should pause and you can see all variables, the call stack, and more. Who knew debugging WordPress in Visual Studio Code could be so easy?<\/p>\n\n
XDebug Ghosting You? Enable Logs<\/h4>\n\n
When your breakpoints mysteriously don\u2019t<\/em> trigger\u2014even though everything seems right\u2014you can add these lines to your php.ini<\/code> to enable logs:<\/p>\n\n
[xdebug]  \nxdebug.log = \/tmp\/xdebug.log  # Simple path that\u2019s always writable  \nxdebug.log_level = 1  # 1=errors, 3=trace (verbose)  \n<\/code><\/pre>\n\n
When to Check the Logs:<\/p>\n\n