Guide To Having PhpStorm Use Windows Subsystem For Linux’s Git

I’m one of the rare Windows users at Automattic but thanks to the introduction of Windows Subsystem for Linux, my life is way easier. I can now run pretty much any Bash script without having to spin up a virtual machine like I used to have to. While it’s possible to build Node.js-powered projects natively under Windows thanks to the Windows-Build-Tools package, it’s a lot easier to just do everything within Linux. This is largely because building in one environment means that you can’t run the tools in the other environment.

The main time that this bites you is when the project you’re working on has a pre-commit hook in Git. If you build your project in Linux but attempt to commit from Windows, it won’t work. IDEs such as PhpStorm do all of their Git operations from Windows. This blog post will explain how to get it to use the copy of Git within Linux.

  1. Install Pageant from PuTTY or if you’re signing your commits, then Gpg4win (its gpg-connect-agent can be set to be PuTTY compatible). Have it start with Windows in order to load your SSH keys.
  2. Verify that the agent is working by using PuTTY to connect to github.com with the username git. GitHub won’t let you open a shell but it’ll let you know that you have successfully authenticated. Note that command line ssh won’t work because it’s not Pageant-compatible.
  3. Install weasel-pageant to allow you to use SSH keys from within Linux.
  4. Verify that the agent is working by running ssh-add -l in Linux. Your key(s) should be listed.
  5. Verify SSH is working by running ssh [email protected]. If it doesn’t work, append -vvv to the end of the command to enable debug output to see what’s wrong.

Now that you have Git authentication working within Linux, it’s time to get PhpStorm (or whatever IDE you use) to use Linux’s Git.

The trick here is instead of having PhpStorm use git.exe, you need to point it at a batch script. This Stack Overflow question helped me a ton, but I needed to modify it a little bit.

For whatever reason, my .bashrc file wasn’t being loaded when calling bash.exe -c which meant that agent wasn’t being loaded. So as a part of my batch script, I’m manually loading my personal file that contains my shell customizations. Here’s my full batch file:

@echo off
setlocal enabledelayedexpansion
set command=%*
set find=C:\Users\%USERNAME%\AppData\Local\Temp\git-commit-msg-.txt
set replace=/mnt/c/Users/%USERNAME%/AppData/Local/Temp/git-commit-msg-.txt
call set command=%%command:!find!=!replace!%%
If %PROCESSOR_ARCHITECTURE% == x86 (
    C:\Windows\sysnative\bash.exe -c 'source ~/.viper-common; git %command%'
) Else (
    bash.exe -c 'source ~/.viper-common; git %command%'
)

In PhpStorm, go to File → Settings (or Default Settings) → Version Control → Git and set the “Path to Git executable” to point at the batch file. Verify that it works by clicking the Test button.

With that, everything should work now!

Questions? Problems? Leave a comment below.

Ideal WordPress Plugin Development Using PhpStorm 8

The upcoming PhpStorm 8 features built-in WordPress support, as explained in this support document. However what’s the best way to set up your WordPress install in order to write plugins? Here’s my personal answer — feel free to suggest alternatives in the comments section.

When working on a WordPress plugin, you don’t want functions, classes, variables, etc. from other plugins to leak into your current plugin through auto-complete or other types of automation. For this reason, I suggest avoiding opening a whole WordPress checkout with all of your plugins inside of it using PhpStorm. At the same time, you don’t want to have a separate copy of WordPress for each plugin that you work on. This is redundant and makes keeping WordPress up to date harder.

So instead do a single checkout of WordPress to its own folder and then define WP_PLUGIN_DIR and WP_PLUGIN_URL, as described on the Codex, so that your plugins folder will live outside of your WordPress folder. This way you can open and index the WordPress folder without getting all of your plugins along with it.

Now create a new project for each individual plugin. When doing so, you’ll want to add the WordPress folder as an include path in PhpStorm, as described in their documentation.

All of this will result in only your individual plugin’s folder showing up in PhpStorm but with WordPress showing up under the “External Libraries” list. This one WordPress install can be used in your browser to test all of your plugins but the plugin codes won’t overlap.

Portable PhpStorm

I use PhpStorm to write all of my code for my job at Automattic. It’s an amazing IDE and has made me so much more productive.

However I am an outlier at my company in that I use two different computers rather than only a laptop — my powerful desktop with a big screen at home and my super portable ultrabook laptop when on the go. In order to keep my working environment identical on both machines, I install all of my work applications in portable mode. That is they store their configuration options in files alongside themselves rather than in my user directory or in the computer’s registry. This allows me to keep the applications stored on Dropbox which in turn keeps them synced between my two machines.

PhpStorm by default stores your configuration settings in files inside of your user directory. This is ideal for multi-user machines where each user should have separate settings. This however doesn’t apply to me. So how do you get PhpStorm to store those settings somewhere else?

After installing PhpStorm inside of your Dropbox directory (I have a “Programs” folder for these kinds of things), you need to go into the bin folder inside of PhpStorm’s directory and then open up the idea.properties configuration file in your favorite basic text editor such as Sublime Text or even just Notepad.

EDIT: You don’t even have to install it. If you take the direct download link and swap out .exe for .zip, you’ll get a ZIP file containing all of PhpStorm. You can then extract it to your Dropbox. I’m sure the process is something similar for Mac users.

At the top of the file you’ll find some commented out that have values with ${user.home}/.WebIde/ in them. You need to uncomment these lines and then replace ${user.home}/.WebIde/ with something like ${idea.home}/prefs/ which will instead store things inside of a “prefs” folder inside of your PhpStorm folder.

Lastly you should probably copy the contents of your old .WebIde folder (instructions to locate it can be found here) into the new location so that you don’t lose your existing settings.

Enjoy!