Local Community

Can no longer debug in VS Code after Local update

Hello,
I have been developing WP shortcode plugins using VS Code (with Xdebug+VSCode add-on) and everything was working fine until the end of October. Today I came back to work more on the same plugins and I can no longer debug in VS Code. The only thing that changed in the meantime is Local update.

I read some of the previous conversations in the forum, and tried deleting .vscode folder in the site’s app/public folder, regenerated it and restarted Local but it still doesn’t work. I noticed that the newly generated launch.jason as “Listen for Xdebug 3.0” and “Listen for Xdebug” but neither of them works. When I run php -v from the site shell (launched from Local), it says “with Xdebug v2.9.0, …”. It also says “Unable to load dynamic library 'php_imagick.dll” even though I have no idea if that has anything to do with it.

I am using Local v6.5.2+6204, Xdebug+VSC v1.0.7, PHP 7.4.30, VSC v1.73.1, PHP Debug v1.29.0, all running on Win 10 Home. Before Local 6.5 update, I think PHP version was different, even though I cannot remember what it exactly was. Does that have anything to do with it?

I am very new to WP+Local+PHP+Xdebug so I have little experience. Today I have spent hours reading Xdebug’s documentations but so far things look like what they say they should be. Could this be a Xdebug+VSC add-on issue?

I’d really appreciate any help, information you could give me. I am dead in the water without debugger and am really desperate with work I need to get done.

Thank you,

Issue Summary

I had been developing WP shortcode plug-ins using VS Code until the end of this October and everything was working fine. I just went back to update my program today and I can no longer use the debugger (it doesn’t break on any break point). I believe the only thing that has changed in the meantime is Local was update. Could this have anything to do with the new Local and/or Xdebug+VS Code add-on?

To be really precise, I was working on my original test Local site until the end of October. Then I created a new Local site and ported my plug-ins and made sure everything worked fine. The reason I created a new site had nothing to do with my plugins, but rather I experimented with different themes, and I wanted to go with Gutenberg theme with a clean slate.

Today when I initially tried to debug in the new site, I realized PHP Debug on VS Code was not configured right, because I still hadn’t done “Add Run Configuration to VS Code” for my new site in Local. When I did that, I realized “launch.jason” in “.vscode” folder looks slightly different than the one in my old site. Specifically “Listen for Xdebug 3.0 (Local)” configuration is added to the newer launch.jason. However whether I choose “Listen for Xdebug 3.0 (Local)” or “Listen for Xdebug (Local)”, the debugger in VSC doesn’t work any way.
Also when I go back to my old original test site, which has been left untouched, the debugger doesn’t work anymore either.

The fact that the contents of “launch.jason” are different before and after Local version updated, and also I can no longer use debugger in old site make me wonder something has happened either with the new version of Local or “Xdebug+VS Code” add-on.

I am very new to Local + WP + PHP and I apologize if I am missing easy things, but I am really desperate, and any help/information will be greatly appreciated.

System Details

The current Local version is 6.5.2+6204. I cannot remember what was the previous version where everything was working, but I started using local only about 2 months ago, so whichever the latest version at the time was what I had. Xdebug+VS Code add-on is v1.0.7.

My OS is Windows 10 Home. VS Code is 1.73.1 with PHP Debug v1.29.0.

I greatly appreciate your help.

Hey @kenguiche – let’s see how we can get thing back in order!

From what you describe, I think the issue has to do with the Xdebug version. Basically, for version 2.x, the default port was 9000, while for the 3.x version of Xdebug, the default port is 9003.

I notice you said that you mention using PHP 7.4.30, but that Xdebug is only at 2.9.0. That version of PHP should have the newer 3.x version of Xdebug, which makes me wonder if there was a problem updating the PHP configuration during upgrade.

Can you try:

  1. Take a backup of the site, by right-clicking it and selecting “Export.” This will give you a zip file that you can drag-and-drop onto Local to re-import if anything goes wrong.

  2. Try swapping to a different version of PHP by clicking the “PHP Version” button. This should re-compile the configuration for the site. You can always return to 7.4.30 if you need that exact version

  3. Try doing the debugging within VS Code.

If you still have issues, can you provide a screenshot with the xdebug settings, including the .vscode/launch.json file.

Something like this should give us enough info to keep looking:

1 Like

Ben, thank you very much for your reply,
I’ve tried switching to PHP 5.6.39, 7.3.5 (the ones available in the PHP list on my Local) and back to 7.4.30 again, but so far nothing has worked. I too noticed the port changes, and tried all port combinations but nothing worked either. Also I tried uninstalling Xdebug+VSC add-on (actually deleting the entire program folder and reinstall it), but it didn’t make any difference.

I am totally new to this whole WP+Local+PHP environment, and I don’t know what Xdebug+VSC add-on actually does, but it almost feels like Xdebug is not talking to VSC at all anymore. Am I the only one having this problem with this setup (Local 6.5.2+PHP7.4.3+VSC)? Also if PHP7.4.3 should have Xdebug 3, how could I fix my PHP installation?

I really appreciate your help,

I attach the screenshots of the current Xdebug settings and launch.jason file.



Ben,
Additional info: Today I tried changing PHP to 8.1.9, and when I did that, Xdebug version changed to 3.1.5 as well. However, the debugger still didn’t work in VSC. With PHP 8.1.9 the Xdebug port was 9003, and I chose “Listen for Xdebug 3.0” on VSC with port 9003, but it still didn’t work.
Also incidentally today I noticed PHP 7.4.30 in Local shows “update” sign, so I did that, but it still didn’t make any difference with VSC. By the way, the reason I am with PHP 7.4.30 is when I updated Local to 6.5.1 and I chose PHP 8, an error message came up saying some dll or something was missing (I didn’t write it down or take a screenshot so I cannot remember exactly what it said).

Again, I am a total newbie with this whole thing, but it somehow feels like the problem is not just some simple configuration issue like port number, but rather something is fundamentally broken. That’s why I wonder what exactly Xdebug+VSC add-on does, whether it is just a very thin layer, or it is doing a whole lot more, and once it breaks, PHP itself won’t really know, or something like that.

Again, I really appreciate your help.

@kenguiche do you have one of the browser extensions that toggles the xDebug on your browser of choice?

No, I don’t think so. I use Chrome, but is there a Chrome extension that allows debugging on Chrome?

Often you will need to use something like the above in browsers to set a cookie session for xDebug.

@afragen I’ve never heard of this extension before (even though I am very new to this). The debugging in VSC used to work fine for me, until only a couple weeks ago, but are you saying sometimes you need this extension to make it work for VSC?

Exactly. I’ve been using something similar for years. It has to do with whether or not xDebug is always active for the browser or not. I believe there can be performance issues with xDebug active.

OK, thank you for the info. I will give it a shot.
When you say performance issue, you mean xDebug can negatively affect the performance of browser, so browser might sort of ignore xDebug, thus VSC won’t hear from xDebug or something like that?

Hey,

I ran into exactly this issue - when Local updated recently my xDebug with VSC stopped working

This thread has the solution that worked for me (updating the xdebug settings in php.ini.hbs)

EDIT: Caveat, i could only get it working when downgrading my php version from 7.4.30 to 7.3.5 (which also downgrades the xDebug version)

Will need more testing, but for now that works for me

Hello folks,
An update: Following the advice from @afragen, I installed Xdebug Helper on Chrome (which I use), then voila, VSC debugger started working again. However, it only works when PHP in Local is 7.3.5 or 8.1.9, and not for 7.4.30.

Modifying php.ini.hbs files as suggested didn’t have any effect for me. The launch.jason created by Xdebug+VSC add-on has “Listen for XD 3.0” which listens to 9003, and “Listen for XD” to 9000, so you can choose one accordingly without modifying php.ini. Changing xdebug.start_with_request from “trigger” to “yes” didn’t have any effect either.

On my Local, PHP 7.3.5 and 7.4.30 both say they use Xdebug 2.9.0 unlike @haloant mentioned, but the end result is the same for me, VSC debugger only works for 7.3.5 now. Even though I haven’t experimented, the Xdebug settings in php.ini files for 7.3.5 and 7.4.30 look very different aside from the ports, with different variables set, so maybe that may have something to do with it.

So at this point it looks like it is/was an issue with Xdebug cookie on browser, as suggested by @afragen, although I am not sure of the exact mechanism at this moment.

I will see how it goes. Thank you everybody for all the info. I really appreciate it.

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.

The performance issues are related to how fast PHP works to serve up the pages. Basically, because Xdebug is doing a bit more work to potentially provide you with more information, each WordPress request takes a little longer. In most cases that doesn’t matter, because you want that extra info while doing development. On the other hand, if you aren’t doing advanced dev work, and are only trying to build out content or work directly with WordPress, you can disable Xdebug so that WordPress runs faster and you can get on with building the site.