I didn't put up an update or made any releases for a while, but that doesn't mean nothing was going on. Here is the current release cycle cover GitHub issue. But the most important change was the migration of the extension.
Just when the year turned to 2022, I wanted to make a small release since I had prepared a PR. However what I saw was that the Personal Access Token (PAT) used to deploy the extension was expired. It felt that this was a good excuse to try to solve one outstanding issue that was left after the code was migrated from Felix Becker's GitHub account to Xdebug.
The extension still used
felixfbecker publisher ID, that I did not have access to. I could not look at the stats under Marketplace, nor answer Reviews.
The weeks long effort was coordinated by VS Code PM - Isidor Nikolić - and at the very end, both php-debug and php-pack extensions were moved under Xdebug marketplace publisher.
I want to say again, what a great codebase Felix left and what a good learning experience this was for me.
One other unrelated thing is that I took over the PHP IntelliSense extension, also from Felix. The extension was delisted from the Marketplace and I have re-published it under my own publisher after fixing some basic problems that came with more recent PHP versions.
I will take time and write about it some time later, but let's say it is a very interesting piece of code. The Language Server is written in PHP and the functions are exposed via Language Server Protocol (LSP) to the extension.
While this brings some benefits it also has downsides. I intend to make it more stable, improve caching of language data and make it more compatible with latest PHP. One thing I'd really like to do is make the extension aware of different PHP levels. We'll see how it goes.
This was a very interesting one. I was aware of it, but not how it actually affected things. It started with a GH issue where a user complained that
Launch currently open script doesn't work. It can't find his
php binary. I tried to reproduce the issue on my PC and then on my Mac, but couldn't.
As it turns out, I did not have the exact same conditions. The user had his
php binary in a non standard place. But that should be accessible from
The Node.js docs read:
The command lookup is performed using the
options.env.PATHenvironment variable if it is in the
I guessed this means, that if the provided
options.env had the
PATH key it will be used, if not, it will fallback to
However digging through all the code I realized this is actually delegated to the OS via the
execvp system call. And the man states there
that if there is no
PATH in the provided environment it will fall back to some default
/usr/bin:/bin. Since the executable was in that particular path on
my system, I never felt the problem.
This also led me to suggest a documentation change in the Node.JS project.
Set Variable support
This was a very old PR created by Felix. With some updates and minor changes, VS Code PHP Debug now supports changing variables.
If you tried to evaluate variables by hovering over them in the code you will see that they more often than not don't work. The reason for that is that VS Code, by itself, doesn't understand PHP code really well.
Extensions can help by implementing the Evaluatable Expression Provider. This gets triggered when the user hovers over code and tells the debugger what to evaluate.
The proper implementation would be to implement this as part of the language extension. This is because the language extension should “understand” the code, where as the debug extension doesn't have that information.
Nevertheless I decided to implement basic support directly in php-debug, since I don't know how many people have both installed.
Luckily, PHP isn't that complex and looking at the documentation, one can relatively simply extract variable names from text.
Parts of the auto configuration logic were updated. First the existing
php.executablePath setting was renamed to
php.debug.executablePath because if conflicted with the one from PHP IntelliSense.
This setting is used when you run a script and don't define explicitly what
runtimeExecutable to use. If this setting is not set, the extension falls back on the PATH. If even that fails, you get a message and link to settings.
DBGP Proxy Support
One feature that was pending for a long time is the DBGP Proxy Support. If you are running the DBGP proxy you can instruct the extension to register with it when you start debugging. Here is the default configuration.
The only thing that needs to be set is the
enabled key. The
key setting is, by default, retrieved from
php.debug.ideKey VS Code settings.
Ping me on Twitter or GitHub issues if you have problems or questions. The configuration of the extension is very flexible and can adapt to all sorts of strange environments. I'm planning to create a set of documentation pages that explain more in detail how it can be used in different setups. I'm always happy about feedback and would always like to know how to make debugging experience better. I'm currently focusing on Xdebug Cloud support.
Also if you use the extension and it makes your life easier consider donating via GitHub Sponsors.