Page 108 of 427

PhpStorm for WordPress Development: A Few Reasons

June 13, 2017 / Tom / 0 Comments

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.

i think in the last five years, i’ve covered:

• coda
• atom
• visual studio code

..and probably more. i think it’s worth evaluating 1/6

— Tom McFarlin (@tommcfarlin) June 12, 2017

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.

WP_Query Readability Improvements (For Maintenance)

June 12, 2017 / Tom / 0 Comments

Working with WP_Query, especially when you’re doing some custom work outside of the usual “get some posts and display them on a template” can be powerful. This is especially true of some of the advanced arguments (like using WP_Meta_Query, for example).

It’s also kind of nice that setting up the process has a standard way of doing things. Namely:

Define the arguments,
Instantiate WP_Query,
Check if there are posts,
Loop through them,
Finish Them.

But if you get to where you’re doing any advanced work such as working with a custom post type from a third-party solution, having to sideload media, determine if something exists before actually doing any work with it, then it can be a little more complicated to work with, can’t it?

I’ve found that, like with anything in programming, breaking it down into much more readable modules (or functions or pieces or whatever you’d like to call them) can make it much easier to work with.

So here’s one way that I go about working to make WP_Query readability improvements in a variety of the stuff I’ve done lately.

Project Guardrails: Writing To Production

June 9, 2017 / Tom / 0 Comments

In the past few articles, I’ve talked about a couple of things (saved for actually writing to production) that help to run a successful project:

The dangers in “design by committee,”
Considerations for provisioning an environment.

The last thing I want to address the learning I’ve experienced thus far is about maintaining the proverbial keys to the kingdom of writing to production and why that matters.

Project Guardrails: Provisioning Environments

June 8, 2017 / Tom / 0 Comments

This series of brief articles is made up of a few things I’ve learned over the last few years of running projects based in the area in which we (assuming you’re reading this coming from the same part of the industry I do 🙂) work.

If you’re just stumbling across this, the series is covering some factors that are important for a project:

There should be no “design by committee.“
No one else other that the core development team should be able to provision development, staging, and production.
No one should be able to write to production but the development team (and even then, there should be a deployment process).

I don’t really like making hard and fast rules like this namely because things change over time either by necessity or by more experience. This is why I like “guidelines.”

But at the time of this writing, these are the things I see playing out.

Project Guardrails: Design By Committee

June 7, 2017 / Tom / 0 Comments

When you’re contracted to build a solution for others – primarily on the web since that’s the area in which I work – I think that there are a number of factors that are important for a project:

There should be no “design by committee.”
No one else other that the core development team should be able to provision development, staging, and production.
No one should be able to write to production but the development team (and even then, there should be a deployment process).

I’m always hesitant to make statements like this as they come off as dogmatic, but I find that the longer I work in this industry, the more I think these three rules are important.

Or perhaps they are really just guidelines. After all, there are shots called before we actually get stuff done.

Regardless of if they are more suggestions or rules doesn’t really matter. There are reasons that we all arrive at the conclusions that we do, right? And so over the next few posts (rather than one long post), I’ll share the reasons I’ve found these three rules to be important.