I am unable to determine the proper PHP executable path (i.e., ‘php.validate.executablePath’) for the VS Code PHP linter. Another post in this forum advised that Local compiles the PHP executable in the form of Linux binaries. Unfortunately, that post is now closed, which is why I started this new post. Also, I assume this is only the case for the previous VM Local versions. Now that Local Lightning runs directly under Windows, would it not require a separate PHP executable to be installed on my system?
I have no issue running Local Lightning, just recently have migrated from the previous VM Local version. Up until a short while ago, I used Atom for my development IDE, but I switched over to VS Code since it seems to be more code development friendly in terms of Intellisense and debugging, for instance.
I installed Xdebug and, thus far, there are no issues with it. Next, I am trying to integrate Xdebug with VS Code’s PHP linter (see: https://code.visualstudio.com/docs/languages/php). As noted earlier, I need to establish a PHP installation path in order to run this linter.
Questions:
If Local Lightning embeds PHP into its executable , then how can I establish a PHP executable path for the VS Code PHP linter without having to separately install the same or closest executable version of PHP that is running under Local?
If I have no alternative but to install a separate PHP executable, then how can I ensure that the VS Code PHP linter results align with the PHP embedded within Local? If the separate PHP executable slightly differs in its PHP syntax and semantics as compared to the Local embedded PHP, then will this not produce misleading debugging results?
I am running the latest version of Local Lightning under Windows 10 Pro.
You don’t mention it explicitly, but if you’re eventually wanting to use Xdebug’s step debugger, you might be interested in installing the Xdebug + VS Code Local addon.
To your specific question of where the PHP binary lives.
You’re correct that in Local Classic (<3.3.x) PHP was a linux binary within a Docker container, that was within a VM
Under Local lightning, there’s no virtual machine, but each site does have its own configuration for the various pieces of server software. I’m not 100% sure what the VS Code linter needs, but the easiest way to get a peek at the environment of a site is to right-click on the site and select “Open Site Shell.” From there, you can examine the shell script that was run to configure that environment. Here’s a screenshot of one of those shell scripts for one of my Local sites:
Ben, thank you for the response. I had seen the ‘Xdebug + VS Code’ addon, but, strangely at the time, I did not think to add that extension. A few questions if I may:
If I were to do this now, would this overwrite my current externally installed Xdebug?
Will it install a DLL named ‘php_xdebug.dll’? If not, I will need to change the ‘php.ini’ [xdebug] ‘zend_extension’ assignment to whatever name is given to the DLL.
When running Xdebug in VS Code it asks for a debugging environment (probably not the precise phrase). I selected ‘PHP’. I do not recall if this was available as a VS Code option at the outset or if I first needed to install a PHP linter. In any event when I attempt to run the Xdebug debugger, VS Code responds with a “cannot validate” error message, claiming the path I specified for the PHP linter is invalid. Recall, in my previous post within this thread, I had to change the backsplash path notation to a forward slash (UNIX-like) path notation in order to be able to save the PHP linter’s JSON configuration file, where I assigned the this path as a value for ‘php.validate.executablePath’.
I’d say give that Local addon a try and see how it goes with a new, plain WordPress site in Local.
Xdebug comes installed for all WordPress sites, so you shouldn’t need to manually configure anything within PHP’s settings.
As far as the VS Code side – that’s what the Add-on does, you click the link under the “Utilities” tab in Local and configuration settings will be set for project that VS Code has.
Thanks for the follow-up reply, Ben. I added the ‘Xdebug + VS Code’ extension to my Local Lightning app and then ran ‘ADD RUN CONFIGURATION TO VS CODE’, which closed & restarted Local Lightning. Next, I opened VS Code and the same error message appeared. Here is a screenshot for both the VS Code error message and the JSON configuration file in question. I confirmed the JSON config file’s ‘php.validate.executablePath’ path value exists on my system.
Do you know why I continue to receive this error message? Also, how does this ‘Xdebug + VS Code’ Local Lightning extension integrate with VS Code’s PHP linter? Basically, not only do I want to be able to debug my PHP code, but I also want a code assist capability (e.g., syntax checking, function parameter requirements, automatic code fill) as I develop PHP code.
“C:/Users/…/bin/win64” is indeed not a valid php executable, but I bet that if you look at “C:/Users/…/bin/win64”, you will find a file php.exe. If so, “C:/Users/…/bin/win64/php.exe” is a valid php executable and clicking the Open Settings button in the error message and then adding php.exe to the path should at least solve this aspect of the puzzle (not sure about the rest :-))
Thanks for the reply, afragen. “VS Code uses the official php linter (php -l) for PHP language diagnositcs.” (see https://code.visualstudio.com/docs/languages/php#:~:text=VS%20Code%20uses%20the%20official,current%20with%20PHP%20linter%20improvements.. As I understand it, PHPCS (PHP Code Sniffer) is itself a linter. What is the advantage of using PHPCS over VS Code’s native/built-in PHP linter? By the way, it turns out that the JSON configuration file that I posted has three settings associated with the VS Code PHP linter, one of which is ‘php.validate.executablePath’.
I noticed after looking at the screenshot, that those are forward slashes, but since you are on Windows, you might need to use backslashes as well as escape those slashes. Something similar to this Stackoverflow answer (though Local’s php executable is at a different location than this answer):
I’m always looking for helpful extensions – do you have the name of the one you use?
This is working. By the way, it corresponds with the use of single forward slashes for Windows in the “PHP in Visual Studio Code” document that @aspsa referred to.
I tested what happens if I replace the single forward slashes in this path by “\” and that seems to be all right as well.
Thanks, Ben. The forward slash path notation works. The issue, as pointed out by HankB in this thread, was that I overlooked typing in the full path, which includes ‘php.exe’. I misunderstood the setting, thinking I need the path to the directory containing ‘php.exe’.
You write that you use VS Code with the extension PHP Debug by tiansin. Is there any technical reason why you prefer this extension above PHP Debug by Felix Becker, also in the VS Code “marketplace”?
Comparing (for what it’s worth): Felix Becker’s is rated 4 stars instead of 3. It has 4.5M installs instead of 14k. The text of the respective VS Code Extensions page is strikingly similar, except that tiansin’s looks like it’s about an earlier version that does not yet include Xdebug 3.
I found some issue with the other extension, I think with xDebug 3.0 and PHP 8. I don’t really recall. It may have been that there was some issue with my M1 Mac.
