WordPress Jetpack gets a lot of grief, and for an understandable reason. From some perspectives, it does everything we hate about plugins. But there are reasons and methods behind the madness. I’m going to hit them from my perspective as best I can, without ever considering the ‘Automattic sucks!’ arguments I’ve heard. I’m reasonably sure Automatic is neither trying to be a dick nor are they evil (egotistical maybe, but not evil). If you go in assuming there has to be a reason for all this, even if you don’t like it, you can understand it a little better.
Why one big plugin and not 20+ separate ones?
Actually I’m going to come back to this one, but there’s a reason, so hang on.
Why do I have to connect to WordPress.com?
This is a better place to start. You have to connect to WordPress.com because they’re providing a service. Not everything runs on your server, so in order for the modules to work, you have to let your server talk to WordPress.com. That one makes sense to just about everyone, I hope.
Less obvious is exactly how this benefits you. I’ll give you a real annoying example: Twitter’s API. You may not know, but Twitter throttles API usage based on IP address. So if you’re on a shared server, and everyone uses Twitter on their blogs, you may get your API cut off and no Twitter updates show on your site. Bummer! On the other hand, WordPress.com has a gimmie from Twitter, letting them post as much as they want.(Probably not unlimited, but enough for us.) This is also true of Highlander (aka the comments plugin), which transmits data between multiple hosts instead of you having to set up OAuth, which if you’ve tried, you’ll see why Jetpack Comments are way easier.
But why do I have to connect to use any of the modules?
This usually comes up when someone only wants to use one feature, let’s pick the contact form, which doesn’t need to communicate with WordPress.com to run. The best reason I had is ‘It’ll make it easier if you later decide to turn on the other features later.’ I tossed this around for a while, considering the users I work with every day, and I’ve finally agreed that for the common user, it’s better to have to do one setup, once, and be done.
After years of free support, and now doing this for a living, the common user doesn’t have the experience to understand that while I may need to connect to WordPress.com for the stats, why do I need it for a mobile theme? The problem comes up when the user wants to start with the items they don’t need to connect. Springing it on them later is an uphill battle I wish I didn’t have to make. So yes, it’s sensible for the average user. As Helen said, Jetpack is for users, not developers.
Anyway, if you know for sure you (or your client) will never want to connect to .com, then you can use the new development mode (as of version 2.2.1) and add
define( 'JETPACK_DEV_DEBUG', true); to your wp-config.php file. Done.
If the .org repository doesn’t let people host marketplace plugins, what’s up with VaultPress?
VaultPress is selling a service, not a plugin. It’s hairsplitting, but look at Akismet (which also could be a pay-to-use product). It’s ‘free’ but you’re encouraged to pay. If they went pay-only, which I could easily see them doing if they started over, they would be a perfect candidate for Jetpack. Where VaultPress rubs the ‘Hey wait…’ button is when you remember that there is a separate plugin for it. So this is like if they let you signup for Akismet within Jetpack… Oh, wait, Akismet’s links are in the Jetpack menu now. Still, of all the questionable things Jetpack does, this is actually the only one that really makes me Spock the Eyebrow(Yes, that is what the favicon is.) because it’s just a little off.
Why the auto-activate?
Users won’t know otherwise. If you don’t turn things on, they’ll never see it. I don’t like it, especially when I’m using a plugin that got folded in (see CSS editor or Grunion), but they learned the Grunion lesson! When the CSS editor joined Jetpack and I upgraded, it turned off the old editor. That was smart, and takes away my User-Ipstenu complaint of auto activation. Remember! This is a user plugin. Not a developer one. Calm yourself.
Why is it one big plugin?
This needs some history.
A few years ago, the concept of ‘Canonical Plugins’ (or Core Plugins depending on if you asked a core contributor or anyone else) came up, and it was an idea for stuff that is (or used to be) in core, but wasn’t used all the time. Examples of this would be the content importer plugins which are used once or twice in a site’s lifetime. To quote the original poll and announcement:
Canonical plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution.
That was 2009, and here it’s 2013 and we don’t really have any yet. Jetpack certainly isn’t one, though in many ways it hits those ‘popular functionality’ feelers dead center. In a way it is a canonical plugin, but it also clearly illustrates why some of the most popular plugins would be very difficult to pull off without the infrastructure that Automattic already has. So while I wouldn’t call Jetpack a ‘Core Plugin’ (it’s not community developed), it’s sort of a great example of what a core plugin suite would look like and the issues with it.
Now, why is it a ton of plugins in one? Well why not? A lot of people hate installing six or seven plugins because “it makes their site slower” (not really), and the way Jetpack does it is remarkably elegant, in that you can turn off the parts you don’t use. The problem I have with Jetpack is it’s size. It’s big. It’s almost the size of WordPress and at 4.2 megs, it’s slow to install. I find that it’s way easier for me to run via wp-cli and upgrade, but not everyone has that option.(That said, I don’t have a problem upgrading on my smaller sites when they don’t get a ton of traffic. Upgrading on my busiest site while it’s busy is always stupid and I know it.) The size problem is also a hassle because WordPress doesn’t (yet?) do incremental updates for Plugins. When you have a series of upgrades then security fixes on a large plugin, it’s annoying.
More likely is the idea that these plugins can share APIs and features if you lump them together, making one big plugin smaller than twenty-odd separate ones.
What is this dev mode of which you speak?
Oh it’s neat. Put
define( 'JETPACK_DEV_DEBUG', true); into your wp-config.php file and here’s what happens:
- Everything defaults to OFF
- You can only activate the following:
- Gravatar Hovercards
- Contact Form
- Custom CSS
- Mobile Theme
- Extra Sidebar Widgets
- Infinite Scroll
The only ones missing that surprised me was LaTeX (I guess it phones home to parse…) and the new Tiled Galleries. Why is that cool? Well now you don’t need to connect to WordPress.com to run those things!
Are you drinking the kool-aid?
Oh. Probably. I honestly like Jetpack. I hate having to set it up for clients (I end up in an Incognito Window, creating a new WP.com account for them, and that whole hassle), but once it’s done, it’s really worthwhile. It does everything I need and while there are parts I don’t need, I’ll live with it. That said, having it set up for people like my father means there’s less I have to worry about with finding plugins for him. Most of what he needs is right there in Jetpack.
I hate Jetpack, I’m never going to use it!
Okay. Don’t use it.
I’m not defending it’s uses for all cases. If Jetpack doesn’t fit what you need, don’t use it! That’s totally fine. I just hate reinventing wheels. There are always alternatives to what Jetpack’s got (Contact Form 7, Google Analytics, and so on), so you can use any tool you like. There are pros and cons with everything, and it’s up to you to decide where your own break point is.