Yesterday, I shared this whole little mini-rant about all of the various IDEs I’ve tried (like Coda, Atom, and Visual Studio Code) over the past few years.

You can click through to read the whole thing, but this gist of it is that I’ve tried PhpStorm off and on for years, but it was never at a point that I enjoyed using it until the latest release (being 2017.1).

Using PhpStorm for WordPress Development: PhpStorm 2017.1

I think it’s important that if you’re going to be living in an IDE for a long project, let alone the majority of your day, it’s important that…

  • you’re comfortable,
  • that you enjoy it,
  • that it stays out of your way,
  • and that it helps you get stuff done well.

But if it’s slow and it’s in your way, and the interface is no good, and it’s generally all of the above things are not, then what’s the point of using it? So yes, I’ve been willing to sacrifice some of its power for lighter editors because I didn’t like how it handled certain things.

But that’s not the case anymore.

And originally, this post was going to be about how to achieve something within the context of PhpStorm. But I thought it might be worth doing some type of introductory post as to why I’ve finally started using PhpStorm for WordPress development in my day-to-day, why I’m [finally] enjoying it, and some other resources you may find useful.

Then I’ll get back to my usual “here’s how to do stuff using it” or “here’s how to do something in WordPress” type of posts.

Using PhpStorm for WordPress Development

First, I’m the last to be dogmatic about what editor you use. Obviously, I’m the one who’s tried about 14 of them before settling on this one. (And who knows how long I’ll stick with it. Kidding, this is likely the one for the foreseeable future.)

Secondly, each editor has their pros and cons, but one thing that’s prevalent in our industry is that the terms editor and IDE are often used interchangeably. I’ve been guilty of this.

Most of our modern editors can become a type of IDE given the right set of add-ons or packages, but it’s also important to recognize some of the features that powerful IDEs offer than many editors do not.

These include things like:

  • automatic refactoring tools,
  • the ability to go to a definition of a function even if it’s coming outside of your work (like in WordPress core),
  • the ability to detect if a namespace, variable, reference, etc. is defined somewhere in the code or not and whether or not you should delete it,
  • the ability to work with inspections, version control, TODOs, terminal, event logs, and so on all within one window,
  • and so on.

Again, packages for other tools can do this. I’m not making a case against that. I’m just sharing what I consider to be part of the core of an IDE if you’re looking for an IDE or for a baseline editor to customize to your liking.

Why I Use It

With all of that said, I need to mention that I have a few friends who have been laying down the peer pressure thick for years. (Admittedly, some thicker than others.) And that’s fine because I’ve always been one more to use the things I like and that contribute to my productivity.

Some, but certainly not all, of these friends include:

Anyway, I just so happen to revisit (for the third time, no less) PhpStorm a few weeks ago. And, surprisingly, it’s all I’ve used for the past few weeks without ever looking back or wishing I was using something else.

PhpStorm for WordPress Development: Toggle Admin Notices

Granted, the vanilla color scheme leaves something to be desired – for some of us, at least – but I’ll do another post about ways to change that later.

If anything, I’m migrating everything over to it. And, on top of that, I’m using the command-line – again, as in as I did back in college with CVS – since it’s just right there in the available terminal. (But this doesn’t diminish my love for Tower.)

Why I Enjoy It

I don’t plan to go down an exhaustive list of all the reasons I like it thus far, but here’s a bulleted list (maybe with a sentence or two thrown in there to explain my take on things) and why you may enjoy it, too.

In no particular order, here are some of the things I enjoy:

  • Assuming you have PHP CodeSniffer setup along with your WordPress rules, you can easily incorporate them into your IDE.
  • The integrated terminal, event log, inspections, and scopes are all nice. Yes, many editors have similar things, but having these all together in a single area of the IDE is nice to be able to get a quick view of things that are going on with the app.
  • Being able to go to a method declaration in the WordPress core code when using one of the available classes or functions is nice because it saves time from going through the Codex or the Developer Portal.
  • Setting a default level or project level version of PHP as well as its CLI is a plus.
  • Integrated Composer support.
  • Easily incorporating linting (or hinting) for JavaScript.
  • The ability to bring in external libraries so that the functions in your work are recognized as part of one of the dependencies it will use.
  • Support for Behat (which I owe a nod towards Toby for implementing that in a recent project).
  • It’s integration with Xdebug (of course).

So yeah, there’s more, but hopefully, this is enough to get you familiar with the things I’ve found useful over the past few weeks of using it.

Naturally, that’s just some of it. There’s more, and you know I’ll likely blog about it; however, if you’re on the fence about trying something new or you’re in a place where you have the ability to try using a new IDE for a new project, then I say 2017.1 is worth a try.

Resources

Finally, here’s a set of resources I recommend at least bookmarking so you can check just in case you get stuck with something in the IDE.

If you’ve got additional resources, link them up in the comments; otherwise, you can assume I’ll have future posts about this, as well.

Category:
Articles
Tags:
,

Join the conversation! 5 Comments

  1. I’ve been using PHPStorm for WordPress development for more than 2 years now and I don’t see myself switching to anything else. It’s a fully featured beast that at first can be very intimidating especially when you come from a text editor like Sublime.

    • Years ago, I remember using Eclipse (before it was Aptana) and then I used Visual Studio .NET. They were both great IDEs. When it comes to WordPress, I couldn’t find something that I was completely happy with (though a few came close) so I’ve tried a few.

      I tried PhpStorm a few times but it was also too slow – but times and software changes. And I’m really happy with it right now.

  2. Hey Tom,

    welcome back, (Php)Storm Trooper! :D

    I am using PhpStorm since I joined Inpsyde—which was in March, 2013. The first months I was using the EAP (because it had WordPress support, and the current stable version 7 did not)—but not even half a year later I bought the license, and used the stable version ever since.

    You made great points, and, obviously, several things are more a matter of personal taste, but I would like to comment on some things, and also add some information.

    You mentioned that an IDE has to be fast—and I very much agree. But then you also mention you are using PHP_CodeSniffer right in your IDE. Is that right? Doesn’t make (things like) that your IDE rather slow?

    I keep static analysis tools in general to a minimum. I’m a big fan of ESLint, for example, but I don’t have it turned on in my IDE. This is something for a build or (pre-)commit task and/or CI, in my opinion.

    Fira Code—yes! I made the switch like five months ago or so, and I so love it now. At first, I really wasn’t sure I could ever adapt to the new ligatures, and also to the (suggested, and thus set) bigger font size. But on the very next day (no kidding!) I didn’t even remember I changed something—until four hours in or so.

    This is how code in my IDE looks like:

    It’s an adapted variant of the Darcula color scheme, with Fira Code at 16px/1.5.

    One thing I learned to love when working on WP REST Starter is the built-in configurable REST client (Tools → Test RESTful Web Service). It’s so fun.

    Another thing you will so worship when you need it is the Local History (VCS → Local History). It is a local Git repository in case you really screw up stuff. Or if you just want to undo some (more) things.

    Looking forward to reading more PhpStorm posts. (Maybe I should also write one or another in my blog… :) )

    Cheers,

    Thorsten

  3. Based in large part on your love for VSC I tried… and tired.. but never could get it setup so it felt “right”, so I stuck with ST3. I started with Coda (1) and moved to ST after not loving Coda 2. I tired Atom, NetBeans and PHPStorm over the years, but ST3 just worked.

    But like you I feel the “peer pressure” of so many loving the latest PHPStorm. I’ll give it another go soon.

    I’m curious how well it handles JS (Gulp/WebPack, ES6 linting, Babel, etc…). I seem to think I’ve read it handles them just fine, at least as well at ST3 does with a few key packages installed.

    • Based in large part on your love for VSC I tried… and tired.. but never could get it setup so it felt “right”, so I stuck with ST3. I started with Coda (1) and moved to ST after not loving Coda 2. I tired Atom, NetBeans and PHPStorm over the years, but ST3 just worked.

      I don’t think you’re alone. I know a handful of people who still swear by ST3. And you know me well enough to know that I’m willing to evaluate as much stuff as possible and then settle on a stack that I really thinks grants as much productivity as possible.

      Sometimes I stick with a thing for a very long time; other times, I end not sticking with it as long as you’d think. It probably looks like I change some software as much as I change my clothes but that’s not necessarily the case.

      I tend to document it all here, though, just in case someone else stumbles across it and is looking for some help :).

Leave a Reply