vscode-php-debug: Stop using enableBreakpointsFor in package.json under debuggers contribution

As a workaround, you can use this setting to enable breakpoints everywhere:

BTW, the suggestion made in https://github.com/felixfbecker/vscode-php-debug/issues/424#issuecomment-743334478 does not have to live in the php-debug debug extension (or a fork of it). Instead a trivial extension could be created that just contributes this:

"breakpoints": [
  {
	"language": "php"
  }
]

You can fix this by doing the following:

1. go to vscode extension directory: e.g. .vscode\extensions\felixfbecker.php-debug-1.13.0
2. Open package.json then remove the following from the file

"enableBreakpointsFor": {
          "languageIds": [
            "php"
          ]
        },

and add the following right above “debuggers”

"breakpoints": [
			{
				"language": "php"
			}
		]

1. Reload vscode

Just so the severity of this is clear: this breaks the extension rendering it almost completely unusable.

@felixfbecker I note that you haven’t done any development on this extension in over a year, if you’ve abandoned it, please make that clear so people’s expectations are set appropriately.

Yup. And by not fixing this before a full release, you’ve just broken the 3.9 million installs this extension has.

@isidorn the issue isn’t necessarily the fix, it’s a completely trivial change to the point that I’m surprised VSC doesn’t have some form of permanent backwards compatibility, the issue is releasing this in Felix’s name, which you can’t do.

Felix hasn’t touched this repo in over a year, and there are two forks with both more active development and packages published in the VSC extension directory:

• https://github.com/tiansin/vscode-php-debug.git
• https://github.com/robberphex/vscode-php-debug.git

@tiansin’s fork has fixed this particular issue and Works For Me as a replacement to this extension.

So if Felix has indeed abandoned this extension, the best path forwards is to make that clear (whatever that means) so people know to migrate to one of these forks.

FWIW, I would be happy to host this on the github.com/xdebug organisation and manage access and Pull Requests, but I do not use this myself, nor am I interested in working on the code, but I am happy to make releases.

We will push a workaround for this on the VS code side in the next stable release - probably in a couple of days.

@derickr thanks for the offer, it’s a great idea to transfer it into the org. I think it would make a lot of sense as the README also contains help on how to set up XDebug and a lot of issues that are filed are often more related to config of XDebug. From the start I’ve always thought of this as a thin adapter for your debugger, which really does the heavy lifting 👏🏻 I personally do not use PHP at all anymore (personally or professionally) so I can’t spend free time on development and triaging the mass of issues, but I’m happy to setup publishing/CI pipeline and dependency upgrade tooling and review & merge a high quality PR.

I haven’t done this process before, but I think the first step needed would need to be for you to add me to the xdebug org so I can transfer the repo and give me enough permissions to setup the GitHub apps for it (e.g. Renovate).

Do note there are two other forks.

http://imgs.xkcd.com/comics/standards.png

😄

We seem to be re-treading a lot of the same ground here.

For those who got here late, please read the comments before commenting.

To summarise:

• @felixfbecker has apparently abandoned this extension, so expecting an update from him is probably unrealistic
• The simplest solution is to enable breakpoints everywhere: https://github.com/felixfbecker/vscode-php-debug/issues/424#issuecomment-743458417
• A “better” solution is to switch to one of the two forks in the VSC repository. I switched to the Tiansin one as the other one (the “Chinese” one) didn’t work for me: https://github.com/tiansin/vscode-php-debug.git

Actions from here are either:

1. @felixfbecker flags this as abandoned and passes the torch to one of the other extensions
2. @felixfbecker passes ownership of this repository to someone else so they can start sorting through the issues and PRs
3. VSC adds a workaround (either compatibility with ancient extensions or detection of ancient extensions and an offer to enable breakpoints everywhere)

Yep, just did. Took too long to find it. For other. VsCode setting/ Features/Debug first setting. Only cost an hour. Cheers.

As another thought, is there a way to get this message front and center for devs that you know will hit this or any other future issue like it? A sticky comment at the beginning of this issue? A bold note or vid in the Release Notes?

As the extension stands:

• latest commit on 6 Mar 2019
• there are 32 opened PRs
• there is almost 50% of open issues

So speaking objectively, looks like this plugin is abandoned for active development. And this is open source, not a paid product so support comes in a form of direct fixes from authors, PRs and self-help.

TL;DR: it sucks that this extension is abandoned given how popular it is but at the same time I think it is unreasonable to demand immediate support from authors when they give their products for free

On a side, I think either active fork should happen or additional members should be added so that they can actively make commits and merge PRs.

Thanks @gentig

Hi @felixfbecker, I have invited you. But I also don’t know how to move a repository. I think you can do that at https://github.com/felixfbecker/vscode-php-debug/settings and transfer ownership.

The latest stable VS Code (1.52.1) has a workaround for the missing adoption of the removed API.

Thanks @gentig Only for whom how me 😃 “breakpoints”: [{ “language”: “php” }], “debuggers”: [{ “type”: “php”, “label”: “PHP”, …

@lwohlhart Thanks for the response. I’m on Windows 10, and I did get updated to 1.52.0 today. No issue on my end setting breakpoints (both with F9 and via the gutter). Was able to set a new breakpoint within a PHP file locally, in a Remote-SSH file, and in a Remote-WSL file. 🤷 (edit: I have “allow breakpoints everywhere” enabled, which is why I didn’t see the issue).