This guide is for XDebug 3.x only.

For XDebug 2.x clear here.

I see a lot of over complicated guides on XDebug so I'll simplify things real quick for everyone.

Visual Studio Code has debugging support out of the box. Click on the Debug icon in the left bar (OS X: ⇧⌘D, Windows / Linux: CTRL+SHIFT+D) then click on the cog icon which should open your launch.json file or create one if none exists.

You must have the PHP XDebug extension installed of course.

Now add this to your launch.json file you have open:

        {
            "type": "php",
            "request": "launch",
            "name": "Listen For XDebug",
            "port": 9003,
            "pathMappings": {
                "/var/www/": "${workspaceRoot}"
            },
            "xdebugSettings": {
                "max_children": 256,
                "max_data": -1,
                "max_depth": 5
            },
            "ignore": [
                "**/vendor/**/*.php"
            ]
        }

Make sure you change /var/www/ to where your code is on your local server.

Set this in your php.ini

[xdebug]
xdebug.mode = debug
xdebug.start_with_request = yes
xdebug.idekey = VSCODE
xdebug.client_port = 9003
xdebug.client_host = "127.0.0.1"
xdebug.discover_client_host  = 1
xdebug.log="/tmp/xdebug.log"
xdebug.cli_color = 1

You might need to do it twice. Once for CLI and once for PHP-FPM!

Typical locations for your php.ini file:

• Linux: /etc/php/{$version}/php.ini
• macOS (Homebrew): /usr/local/etc/php/{$version}/php.ini

Don't forget to restart php-fpm!

Now start the debugger by hitting the green play button.

I recently moved to Maui, HI and have a Spectrum 960/20 land line hooked up. Cloudflare peers with DrFortress in Honolulu which allows me to ping 1.1.1.1 and get some incredible response times. At least for Hawaii:

    64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=13.7 ms

Awesome right?

Well then I wanted to figure out how to play games on Japanese servers. For American servers I get about 40-60 ms for west coast and 110-130 for east coast. In particular my DigitalOcean VPS in NYC responds in 125 ms.

For my testing I'm using the server IPs for the game FFXIV. In this case one of the servers in the "Mana" Data Center in Japan.

Here's what I get pinging the data center with no VPN.

    ping 124.150.157.49

    64 bytes from 124.150.157.49: icmp_seq=1 ttl=47 time=177 ms

Not ideal. Of course it's because it goes through LA on it's way to Japan. Doing a traceroute confirms that. But I knew going into this that there was a direct line to Japan from Honolulu and it is, in fact, possible to send a network packet directly to Japan from Hawaii. Unfortunately the routing depended on your ISP's routing to make it go directly. So then I started playing with VPNs.

I discovered that Cloudflare actually has a free VPN called Warp and while it doesn't provide the best throughput there's no real issue with using it for low bandwidth game connections and simple web browsing.

Trying it Out

I have a Linux desktop running Gentoo and a Macbook Pro. To test this I went ahead and setup Cloudflare Warp on my Macbook and pinged the same IP. Setting it up on MacOS is as simple as installing the official app.

So let's see what we get on the Macbook.

    64 bytes from 124.150.157.49: icmp_seq=1 ttl=54 time=135.54 ms

A whole 40 ms shaved off the ping. Time to install it on my desktop!

On Linux there's an unofficial CLI utility called wgcf which will build you a Wireguard configuration you can use to connect to the service. I had to recompile my kernel to allow wireguard but no big deal. I ping the same IP on my desktop now. Again same internet but this time a wired ethernet connection instead of wifi.

    64 bytes from 124.150.157.49: icmp_seq=1 ttl=51 time=160 ms

Huh?!? How could this be? I was promised speed!!!!

Well it turns out after visiting https://www.cloudflare.com/cdn-cgi/trace I found out what the issue was.

On my desktop I'm getting assigned to the LA data center. But on my laptop I'm getting assigned to Honolulu. All my research on this topic suggests that the "closest" is chosen via UDP broadcast probing but I wasn't entirely convinced so I went digging.

It turns out if you look at the file wgcf-profile.conf it will have this setting:

    Endpoint = engage.cloudflareclient.com:2408

With IPv6 the IP I get when resolving the above hostname is an IPv6 address which is sending me to the LAX data center. When I resolved the hostname manually with nslookup I got 162.159.192.1 for IPv4 and I was able to disregard the IPv6 address. I changed the endpoint setting to use this IPv4 address instead and now my Wireguard connection goes to the HNL data center.

When you run emerge portage does a series of things to your package in order:

• fetch
• unpack
• prepare
• compile

To set up a patch working environment we're going to go ahead and let it do all of that up to prepare. We will do this with the ebuild command:

ebuild file.ebuild fetch
ebuild file.ebuild unpack
ebuild file.ebuild prepare

Now we copy the work directory to our own directory:

sudo cp -R /var/tmp/portage/www-client/ungoogled-chromium-88.0.4324.150-r2/work ~/Sources/ungoogled-chromium-88.0.4324.150-r2-work
sudo chown -R akujin:users /var/tmp/portage/www-client/ungoogled-chromium-88.0.4324.150-r2/work ~/Sources/ungoogled-chromium-88.0.4324.150-r2-work

Now we have our work directory where we can build our patch. The patch will be applied after prepare is done running so that is why we copied the work directory right after prepare was done running. In our copy of the work directory we need to initialize the folder as a git repo so we go ahead and run:

git init
git add .
git commit

Now we can make the modifications we want to make. After you're done simply stage your changes and run:

sudo sh -c "git diff --staged > /etc/portage/patches/www-client/ungoogled-chromium/macos-hotkeys-on-linux.patch"

You can test your new patch simply by running emerge on your package.