LocalByFlywheel + XDebug + VSCode

Hello,

I’m trying to setup XDebug with VSCode and LocalByFlywheel.

I was wondering if anyone else here has done it and if they could point me to a tutorial on how to do it.

I followed this tutorial and all of my settings are the settings that are in the tutorial but whenever I set a breakpoint in VSCode while the debugger is running, my site doesn’t stop on the breakpoint.

This is what gets logged whenever I navigate to my site while XDebug and the debugger in VS Code is running.

new connection 7
<- threadEvent
ThreadEvent {
  seq: 0,
  type: 'event',
  event: 'thread',
  body: { reason: 'started', threadId: 7 } }
<- initializedEvent
InitializedEvent { seq: 0, type: 'event', event: 'initialized' }
-> setBreakpointsRequest
{ command: 'setBreakpoints',
  arguments:
   { source:
      { name: 'header.php',
        path:
         'c:\\Users\\Rich Kastl\\Local Sites\\trenchless-clone\\app\\public\\wp-content\\themes\\trenchlesstechnology\\header.php' },
     lines: [ 16 ],
     breakpoints: [ { line: 16 } ],
     sourceModified: false },
  type: 'request',
  seq: 39 }
<- setBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 39,
  command: 'setBreakpoints',
  success: true,
  body: { breakpoints: [ { verified: true, line: 16 } ] } }
-> setFunctionBreakpointsRequest
{ command: 'setFunctionBreakpoints',
  arguments: { breakpoints: [] },
  type: 'request',
  seq: 40 }
<- setFunctionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 40,
  command: 'setFunctionBreakpoints',
  success: true,
  body: { breakpoints: [] } }
-> setExceptionBreakpointsRequest
{ command: 'setExceptionBreakpoints',
  arguments: { filters: [ '*' ] },
  type: 'request',
  seq: 41 }
<- setExceptionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 41,
  command: 'setExceptionBreakpoints',
  success: true }
-> configurationDoneRequest
{ command: 'configurationDone', type: 'request', seq: 42 }
-> threadsRequest
{ command: 'threads', type: 'request', seq: 43 }
<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 43,
  command: 'threads',
  success: true,
  body:
   { threads: [ Thread { id: 7, name: 'Request 7 (4:38:02 PM)' } ] } }
<- configurationDoneResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 42,
  command: 'configurationDone',
  success: true }
<- threadEvent
ThreadEvent {
  seq: 0,
  type: 'event',
  event: 'thread',
  body: { reason: 'exited', threadId: 7 } }
-> threadsRequest
{ command: 'threads', type: 'request', seq: 44 }
<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 44,
  command: 'threads',
  success: true,
  body: { threads: [] } }
new connection 8
<- threadEvent
ThreadEvent {
  seq: 0,
  type: 'event',
  event: 'thread',
  body: { reason: 'started', threadId: 8 } }
<- initializedEvent
InitializedEvent { seq: 0, type: 'event', event: 'initialized' }
-> setBreakpointsRequest
{ command: 'setBreakpoints',
  arguments:
   { source:
      { name: 'header.php',
        path:
         'c:\\Users\\Rich Kastl\\Local Sites\\trenchless-clone\\app\\public\\wp-content\\themes\\trenchlesstechnology\\header.php' },
     lines: [ 16 ],
     breakpoints: [ { line: 16 } ],
     sourceModified: false },
  type: 'request',
  seq: 45 }
<- setBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 45,
  command: 'setBreakpoints',
  success: true,
  body: { breakpoints: [ { verified: true, line: 16 } ] } }
-> setFunctionBreakpointsRequest
{ command: 'setFunctionBreakpoints',
  arguments: { breakpoints: [] },
  type: 'request',
  seq: 46 }
<- setFunctionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 46,
  command: 'setFunctionBreakpoints',
  success: true,
  body: { breakpoints: [] } }
-> setExceptionBreakpointsRequest
{ command: 'setExceptionBreakpoints',
  arguments: { filters: [ '*' ] },
  type: 'request',
  seq: 47 }
<- setExceptionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 47,
  command: 'setExceptionBreakpoints',
  success: true }
-> configurationDoneRequest
{ command: 'configurationDone', type: 'request', seq: 48 }
-> threadsRequest
{ command: 'threads', type: 'request', seq: 49 }
<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 49,
  command: 'threads',
  success: true,
  body:
   { threads: [ Thread { id: 8, name: 'Request 8 (4:38:04 PM)' } ] } }
<- configurationDoneResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 48,
  command: 'configurationDone',
  success: true }
<- threadEvent
ThreadEvent {
  seq: 0,
  type: 'event',
  event: 'thread',
  body: { reason: 'exited', threadId: 8 } }
-> threadsRequest
{ command: 'threads', type: 'request', seq: 50 }
<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 50,
  command: 'threads',
  success: true,
  body: { threads: [] } }

We released an add-on for Local yesterday that is a on-click configuration for XDebug and VSCode. If you’re still looking for a solution, give this one a try,

6 Likes

Thanks Brandon, this seems to be exactly what I need.
However, I don’t understand what “yarn” is and exactly what I need to do.
After I copy the folder in AppData, then what?

@Illya, I just published the compiled version that you can download and drop into your AppData folder. You can grab it here - https://github.com/pixeljar/local-addon-xdebug-vscode/releases/tag/1.0.0

3 Likes

Showed up for me in Local Beta. Installed and looking forward to trying it out! Thanks Brandon!

2 Likes

Let me know if you have any feedback @jb510!

Hi Brandon,

I have installed the add-on, but debugging still doesn’t work. I don’t get any errors. I get the small debug control panel. But the debugger doesn’t actually run anything, leaving the various step… options grayed out in the control panel.

Any ideas?

Wayne

(P.S. I’m relatively new to PHP, so it’s entirely possible that I’ve configured something incorrectly.)

I’m going to be recording a video showing how to use the add-on, but here’s the basic steps.

SETUP

  1. Install the add-on
  2. Enable the add-on & Relaunch Local
  3. Go to the site you want to debug in Local
  4. Start the site
  5. Click on the Utilities tab
  6. Click the “Add Run Configuration to VS Code” link - this will create an xdebug/vscode configuration file inside the app/public folder

Debugging

  1. Open the app/public folder in vscode
  2. Start debugging (command/control + shift + p and then type “debug” then click “Debug: Start Debugging”
  3. Load the site in your browser

Note: By default the debugger will only activate on errors, but you can add breakpoints to specific code by clicking to the left of the line numbers in the editor before starting the debugging session.

I hope that helps!

1 Like

Hi Brandon,

I appreciate the speedy response, thanks.

However, I have performed all of the recommended steps, and while the debugger appears to start, it completely ignores the code and any breakpoints that I’ve set. I’ve attached a screenshot .

Because I’ve made multiple attempts at this, following the advice of others prior to seeing your instructions, perhaps I’ve messed up the environment. I’m happy to rip it all out and start over. Any hidden configuration settings that I need to worry about?

Wayne

@wwilliams, it’s certainly possible that you have a configuration issue, but it’s also possible that this breakpoint just isn’t being run on the request in the browser. Are you sure that this template is being used on the current request? When I’m trying to debug stuff like this, I like to put something like die( 'definitely this file' ); right after the opening PHP tag in the file to make sure the template is actually being loaded. Can you give that a try?

Tried that and did confirm that it is the file being used (as indicated by Query Monitor, as well).

Should I go the nuclear option or do you have any other suggestions?

Again, thanks for your help!

Wayne

@brandondove,

Oh, in case you’re wondering, here are the contents of my launch.json file:

{

"version": "0.2.0",

"configurations": [



    {

        "name": "Listen for Xdebug (Local)",

        "type": "php",

        "request": "launch",

        "port": 9000,

        "pathMappings": {

            "/app/public": "${workspaceRoot}",

        },

    },

    {

        "name": "Launch currently open script",

        "type": "php",

        "request": "launch",

        "program": "${file}",

        "cwd": "${fileDirname}",

        "port": 9000

    }

]

}

@wwilliams I think it’s because you have your breakpoint on a conditional. Try putting the breakpoint on line 25 and see if that fixes it.

No, but we may have gotten a little hint there. I had accidentally stopped my site somehow, and when I restarted it, data did temporarily show up in the Call Stack in debug mode. I then repeated the whole process with the site running and we’re in the same boat. Caveat: I have used VS Code for multiple c# and Javascript environments before, so it’s not as if we’re starting with a pristine environment.

Can you try the following -

  1. Stop your site
  2. Remove the .vscode folder and its contents from the site root
  3. Start your site
  4. Add the configuration file back to your site
  5. Start the debugger in vscode
  6. Pull up the site in your browser.

1 small clarification here. in Step 4, do you mean add the configuration file back to my site via the Local Utilities interface?

Actually, no need to answer that question. I used the utilities interface and now everything is working. I can’t thank you enough for your speedy and effective assistance!!!

1 Like

Oh, one last thing. I’m new to this forum. Do I acknowledge or reward your response in some way?

Wayne

Glad you got it working! No need to reward anything. Just here to help.