I’m not the first to write a post like this, nor will I be the last. But Jetpack, the ubiquitous plugin from Automattic, is likely one of the most polarizing collections of code in the WordPress universe. And in recent days it has occupied its own special level of hell for me.
Sharing
Let’s start with Jetpack Sharing, né Sharedaddy. Sharedaddy is but one of many standalone plugins that Jetpack has consumed since its inception. To use it, like the rest Jetpack, you are “required” to connect to WordPress.com, even though there isn’t any functionality about Jetpack Sharing that needs it. (WordPress.com connections are needed to make some other modules work, but Sharing isn’t one of them. And technically, Jetpack has a debugging mode which allows for non-connected use, but that mode isn’t recommended on production environments.) WordPress.com connections are a whole other level of complaint, but not actually related to the problems I’ve been having with Jetpack for this project.
My problems started when I wanted to update the styling for the “Sharing label”. If I used the CSS that was included with Jetpack, specificity problems forced me to use the “!important” flag in my CSS to override it. That’s because Jetpack uses IDs as CSS selectors, a practice that I highly discourage because of the specificity issues. I don’t like using the “!important” flag either (whenever that’s an answer for how to write CSS, it’s the wrong answer), so that ultimately left me with one viable solution: check the “Disable CSS and JS” option, and pull those into my theme manually.
But if only it were so easy. At first, I thought this would be better. I could roll the CSS into my Sass structure, and the JavaScript into my Grunt concatenation and minification tasks, and save some HTTP requests in the process. The CSS worked well enough (despite, sigh, the ID selectors), but moving the JavaScript broke the email sharing, a vital feature for the client. A lot of head-vs-desk later, I finally found in the sharing-service.php the two lines of code that set the translation for the recaptcha_options. Nothing in the “Disable CSS and JS” option warned me about this. Copy those into your functions.php file along with your valid wp_enqueue_script() function call to activate your version of the JavaScript, and you’re in business. But that’s a few hours of my life I won’t get back.
One last problem related to sharing: one of the client requirements for this project is insertion of the “via @twitterhandle” flag in every tweet sent via Jetpack Sharing. I had no clue how this could be accomplished easily, since there was no setting in the preferences to handle this. My fear was I would have to extract Sharing out of Jetpack (fortunately — or not, depending on your point of view — someone else has done this already), hack that to create that option, and save it as a separate plugin so that my efforts would not disappear on the next Jetpack update.
Fortunately, and pretty much accidentally, a little grepping through the code revealed the jetpack_sharing_twitter_via filter. Googling that led me to this article on WPSpeak, a WordPress help site that I had never heard of before. Four lines in my functions.php file, and hours of work saved. I guess it all balances out?
well, if my whole debacle with jetpack on tuesday taught me anything, look for filters that will do what you need! #WordPress
— tracy rotton (@taupecat) January 23, 2014
I’m a fairly seasoned WordPress developer, and even a minor core contributor, and it took serendipity and a knowledge of WordPress filter hooks to find and implement that. How is your average “I just want a simple blog” site owner supposed to? There’s a settings API for a reason.
Infinite Scroll
There’s even more issues I had with Sharing, but even if you’re still reading this, I’m pretty sure you’re probably sick of that topic. So let’s talk Infinite Scroll. Pretty popular tool and while I’m not a particular fan of that paradigm on any site, again we’re talking client requirements. My memory on the problems with this is a little hazy since I worked on this piece before New Year’s, but what I do remember is it just wouldn’t work. Try as I might, following all the tutorials, I simply could not get Infinite Scroll to work as advertised.
As with the sharing issues, I resigned myself to the fact I was going to have to roll my own. I’m not an Ajax guru, so the thought daunted me, until I found this. It’s not great code. It uses query_posts(). The jQuery is a bit sloppy, and it doesn’t take into account custom taxonomies.
But you know what? It worked. Immediately. Yes, I had to spend a few hours dealing with code issues and my client’s requirements, but I got farther with this in half an hour than I did with Jetpack in half a day.
I’ll take crappy code that works over pristine code that doesn’t any day. #webdev
— tracy rotton (@taupecat) December 27, 2013
Because really, when all is said and done, we need things to work.
Conclusion
These are only the specific problems. I have a lot of conceptual problems with Jetpack as well, many of which have been covered ad nauseum elsewhere. How it consumes other solid standalone plugins (I called it a black hole of standalone plugins). How it requires a WordPress.com connection to do things that don’t require WordPress.com. Lack of documentation. Lack of organization in its own special dashboard area. You get the idea.
Jetpack is a victim of its own hunger to be all things to all people. As a result, it gets in its own way, and challenges developers to get their sites working despite it, rather than because of it. I use it because in its modules there are legacy plugins that I need and can no longer be obtained on their own, but I wish that weren’t so often the case.