Open Source, PHP and Visual Studio Code

Lately, VS Code has been getting a lot of hype in the dev community. It’s been around since for a few years and TBH is a really sweet editor. Lots of great extensions and community support. It’s also quite fast (for an Electron app 😬) and the peeps and Microsoft seem to be keeping it up to date and iterating quickly.

However, anything you really need to work with PHP is missing by default. I believe this is by design to encourage a vibrant extensions community. Luckily, like most languages, there’s a vibrant open source PHP extension community. There’s a few great extensions for PHP: PHP IntelliSense, PHP Debug (both by the same developer) as well as PHP Intelliphense (#wat?). There’s even a really great intro by Jeffrey Way on Laracasts outlining everything you need to do to get VS Code set up for PHP dev.

Some of the PHP packages work fine and have over a million installs (!!!). Sometimes, however, they don’t work. Like, at all. Just today, the PHP Debug extension completely broke. Luckily the developer was paying attention and rolled out a fix within hours. Pretty awesome support for an open-source product!

However, if you paid for the editor, say something like PHPStorm, you could go and raise an issue on their support channel. You could complain about the product not working, rightly so, as you’ve paid for the right! As a ‘customer’ you have a certain amount of clout with a vendor like Jetbrains. This is NOT the case with open source, and I feel that we developers forget this.

This is where I take issue. I’m all for open source software. I’ve built my career on it. The issue is that the developer for this plugin had to fix the issue himself. There’s an expectation there that he HAS to fix the issue, and do it RIGHT NOW. And if it’s not done immediately people freak out, complain on Twitter, write a blog post about, have a cow 🐮, man.

Open source is just that, open. If you find an issue with a plugin, editor, extension or WHATEVER, see if you can fix it! That’s the whole point. Let’s not throw our hands up and complain, let’s get our hands dirty and fix the damn thing.

That’s what open source is all about. Let’s remember that.

/rant

PHPStorm, MAMP and Xdebug – How to keep (some of) your hair

I’m mostly logging this here for my own benefit, but if the Google gods brought your here, sweet!

Just came across another fun quirk with running Xdebug, MAMP and PHPStorm together. 😅😅😅😅

I’ve talked about this combination causing me issues in the past, but this is a whole new situation that killed a couple hours for me.

So, it appears that for PHPStorm to pick up Xdebug correctly, the xdebug.remote_host variable needs to be set correctly. It normally is, if you copy-pasta some of the tutorials on the internet.

Unfortunately, for some reason, this Monday morning, setting this value to localhost no longer worked. Why? Welp, localhost is pointing to an invalid folder location, according to MAMP. Apparently this was enough for PHPStorm to freak out and just not run Xdebug. Period.

Fun!

So how’d I figure out this was the reason for Xdebug throwing up?

The PHPStorm docs of course! Wayyyyy at the bottom of this page it’s plainly stated:

Remote host is configured as ‘localhost’ despite server host is probably not local

The URL to validation script contains something different from localhost, but the xdebug.remote_host value is not set and so is using the default value of localhost, or is set to localhost or 127.0.0.1.

#themoyouknow