Attaching to container from VS.code for debugging

I have just installed WSL2 on my dev machine over the weekend. I am now trying to set myself up to debug WordPress plugins from VS.Code.

I have the two containers set up (WordPress and DB) and it’s all running just fine. However, I am unclear on how to attach to a container, so I can debug.

I have the Docker and Remote WSL extensions run. I can see the containers from VS.Code and can use “Attach Visual Studio Code” (context menu on the WP container). I launch that and see a new instance of VS.Code running. But the Explorer view has just the following:


It is unclear to me how / where I can find my actual WordPress folders so I can browse, set breakpoints, etc.

Any pointers would be appreciated.

And…having looked at this for quite some time, posting here is the trigger for me to move on a little :slight_smile:
It turns out that when I launch with “Attach Visual Studio Code” I am taking to the /root folder within the container. I don’t really understand why that would be the default folder to open, but I can just open the / folder (manually) and I can now see my full file system within the container. Step by step…

My next issue that when I navigate to /var/www/html/… I can see my plugins, etc but I can’t set breakpoints. So, that’s my next challenge to understand.

This is a good fun though!

The WSL extension allows you to open and edit files in Linux directories. If you’re launching containers, you could also use the Remote - Containers extension to view files within them. I wouldn’t recommend that unless you have persistent storage or don’t care that changes will be lost.

Are you trying to debug WP theme and/or plugin code? If so, bind-mounting a Windows folder or wsl$ directory means you don’t need either extension!

Getting this set-up can be complex, there are gotchas, some options to consider, and awful online tutorials which lead down blind alleys.

Are you sure you don’t want to re-consider my course?! :wink:

Thank you, @craigbuckler. First off, let me say I am super appreciative of your help here. Thank you.

As to your course, it looks impressive and very well structured. However, on a personal note, I tend to prefer to figure things out from myself over time and enjoy that aspect (I am not, technically, a professional programmer, per se). It’s a little bit more than a hobby for me but I am generally enjoy and am prepared to figure things out via trial and error and posting questions in forums, such as here.

I have used Docker and VS.Code for quite some time in my own way :slight_smile: and it’s worked well. But for those who need or want a pretty detailed guide to setting this up then your course does look very impressive and I wish you well with it.

That said, I’d be interested to know if your course, right now, is up to date with the latest technologies, particularly WSL2, which obviously has a pretty direct impact on things. There may perhaps be some value for me in taking a closer look if it’s already current for all we’ve been discussing here.

As it stands, the reference to \wsl$ was helpful (thank you) and I’m now opening files directly from vs.code. I have some issues setting breakpoints but I am researching that at the moment.

Thank you again.

Thanks @markwill890 . mentions WSL2 and I’ll be publishing some articles about it too. But WSL2 doesn’t really affect how you use Docker – other than making it a faster and more seamless experience.

If you’re debugging client-side code, Docker shouldn’t affect anything - just use DevTools or connect via VS Code.

If you’re debugging Node.js or Deno, you run it with --inspect= and expose port 9229. You can then connect using DevTools or VS Code.

If you’re debugging PHP, you should be able to add XDebug to your WP container and expose port 9000 (I think). There are VS Code extensions which can connect to that.

Everything’s great once it’s set-up – it’s just as easy and faster as developing locally. But getting there can take time.