One of the reasons I left the WP community was this commonly adopted theory that everything just works…with a big, excited smiley face. Even early in my development career I knew that not to be true; but it was the way of the world as far as I could see. I remember reassuring myself that any changes I would make to a live site wouldn’t be seen by anyone because the site was so little known. I mean, that was just an assumption; and it was probably always wrong. But it made me feel better when, a whopping six months into my development career, a client would call and say they wanted a plugin added to their site before the weekend. And I, young and stupid, would agree to do it.
Everyone has heard the old adage, or might have seen the t-shirt:
I don’t always test my code. But when I do, I do it in production!
We all laugh, but how many WP and Drupal workflows have us doing exactly that? A lot, unfortunately. And today I discovered that one of the most widely-used plugins in all of WP is super freaking guilty.
When I installed the Jetpack plugin this morning on this simple, humble WP site, I had three goals in mind:
- Blog post subscriptions
- A comments feed
- Single sign on
Naturally, as you would expect, I installed it locally on my dev site, and had plans to work with templates and styles until I got it to a point where I was happy, and would then iterate on the production site theme you’re currently looking at.
Nope. It would turn out that Jetpack, by default, turns these features off if you’re in dev. That’s a problem. It means that any development you do – even simple styling – has to be done in production. That violates every aspect of good development that I know of – from team-based development, to experimental and exploratory coding. They justify it by saying that in order to activate these features, you need to connect to WordPress.com.
I call shenanigans. If Stripe, Couchbase, and Salesforce can offer dev modes, something as simple as a WP plugin can operate in dev too. I figured that somewhere there was a line turning off those features, and you’re damn sure I was going to find it.
File Header Configuration
I’ll be honest, it actually wasn’t hard to find. I did some Googling at first, but ultimately I ended up perusing the plugin files.
First, make sure you install the Jetpack plugin into your dev site. Once you do that, if you navigate to
/wp-content/plugins/jetpack/modules/ you’ll notice a slew of PHP files. Each of those is a plugin manifest that detects feature activation, and then runs whatever import and config functions it needs in order to add its respective plugin in all its glory.
Notice at the top there’s a file header:
* Module Name: Comments
* Module Description: Let readers comment with WordPress.com, Twitter, Facebook, or Google+ accounts.
* First Introduced: 1.4
* Sort Order: 20
* Requires Connection: Yes
* Auto Activate: No
* Module Tags: Social
* Additional Search Queries: comments, comment, facebook, twitter, google+, social
Oh yeah, jackpot. That
Requires Connection field is all you have to change in order to enable these modules in development.
* Requires Connection: No
That’s all it takes. Load up your dev site, activate Jetpack, and the Comments module will be available. Even in dev. So you can start working with it. In dev. Just as it should be.
Oh, and in case you’re wondering, this does indeed mean that a comment feature is coming. I’m a firm believer in iterating, so when I set out to launch a blog, the ability to post stuff came first. The rest would come after. Comments is next, then subscriptions, and whatever else comes to mind.