Ditch the Jetpack

Reading Time: 13 minutes

One of the things that first drew me to WordPress back in 2012 was that it was a lot of small pieces. Once you installed the core content management system, you could extend and enhance it with a huge array of plugins. It is probably one of the reason that so many people and organizations use it. A key plugin for me has been Automattic’s Jetpack. But over time, the plugin has expanded while at the same time injecting monetization of components and enhancements. When I was recently asked to acquire a license for the Jetpacks stats module, I decided I’d had enough.

The thing that Jetpack did really well when I started using it was to provide easy control of some back end and fiddly items. Things like exposing your website’s search meta data to Google and Bing so that they’d recognize your site as being verified. Or enabling just-in-time “lazy” loading of images. Of course, there was also the website statistics. It used to be fun to look at how many words I’d written in a year, or to see how a page had done over many years. A colleague of mine in Canada laughed but she was right that one of my posts about Irish dance stages remained one of my most popular, especially around oireachtas.

Over time, I had a set-and-forget mindset about JetPack. Occasionally it became fiddly and I’d have to disconnect it from WordPress.com and reconnect it. Or completely uninstall and reinstall. Support was tolerable but ineffectual. With Jetpack, you were mostly on your own.

I am comfortable with that mindset with plugins. It is one of the things that I consider when adding a WordPress plugin: who is behind it? Knowing that Automattic, the developer of core WordPress, was keeping it up to date gave me confidence about using it.

Jetpack Grows

Some web developers avoid Jetpack because it’s “bloated” with features that, admittedly, can slow a website down. Jetpack thinks it’s a myth but I dont think it’s that definitive. The reality is that Jetpack relies on a lot of connections to deliver its functionality. There is a content delivery network, there is code inserted into the website’s templates. I could absolutely see some of these slowing a site down if the connected servers are unresponsive or the filesize of the website’s templates becomes large. It will depend on what features you activate and how they are functioning. I did not find that, in general, Jetpack had a performance impact on my site.

One thing I did learn was that I didn’t know how many modules Jetpack had expanded to include and how many of them were turned on by default, without me intentionally activating them. Jetpack has it’s own settings page within the WordPress dashboard and you can toggle items on and off. In some cases, you can turn on functionality there that duplicates another plugin’s functionality and not realize it.

But there’s also the Jetpack modules page. Add the domain name of your WordPress site with Jetpack installed to this link—https://your_domain/wp-admin/admin.php?page=jetpack_modules—to see the list of modules Jetpack offers. You can also activate and deactivate the modules here.

As of today, there are 44 modules.

As you can see in the image above, there are a wide variety of functions. Some are back end (asset content delivery network, brute force password attack protection) and some are front end (custom style sheets, contact forms). I used a half dozen or so of these, which brings me to my first decision point.

If someone uses a lot of the Jetpack functionality, it may make sense for them to keep it. The all-in-one approach is not awful if you do not have, or do not want to exercise, a lot of technical knowhow. Jetpack has made it very simple to activate a whole variety of features. If, like me, you are encouraged by using a plugin from a company like Automattic, then it would make sense to use one that does a lot, rather than sourcing a single plugin for each of those functions from other providers.

I am not a heavy user of the Jetpack modules. So when I was forced to go through an upsell experience, and asked to pay for a license for just the Jetpack stats function, I balked. Jetpack stats are nice but they are shallow and they are soft, in that they do not capture anywhere near as much detail as my Matomo analytics server does. When it suggested that people are paying US$6.30 a month, on average, for the stats, I realized that wherever Jetpack was flying, it was probably in a different direction from me.

I did not have to pay for a license because this is a non-commercial website and there is an exception. But the free license I was granted is good only for one year and Automattic is using dark patterns to try to capture your credit card information. It is not clear that you do not need to provide credit card information as you check out for the free license and they should not prompt you for it if you’re not paying for anything.

I posted my frustration on Mastodon and someone responded who was in a similar boat but without my flexibility. They already paid for JetPack and used one feature heavily, a feature they could not find in any other plugin. That can make moving away from a plugin difficult. In my case, as with most of my technology, I am never that invested in any single tool and its output that I feel captured by it.

I decided to see if I could leave Jetpack. I started by listing the active modules and to see which I could turn off. There were eight and they were:

• Related content (a block that appears below blog posts referring to other blog posts)
• Performance CDN (faster website response using a high speed content delivery system)
• Site verifications (for Google, Bing, Pinterest)
• CSS customization panel (a simple interface for adding custom styles and seeing them applied, although as I’ll note below, I’m not sure)
• Downtime monitoring (a service that lets you know if your website isn’t responsive)
• XML sitemaps (a search engine resource for indexing a site without crawling it)
• Brute force protection (inhibiting repeated login attempts)
• Stats
• Newsletter (email distribution of new posts)

Some of these were extraordinarily easy to rethink and turn off. I don’t need the performance CDN. I already use Uptime Robot for free website uptime monitoring. Related content is a nice-to-have but it’s rarely used by visitors, as I can see in my Matomo (but not my Jetpack) stats. Three modules turned off.

File Edits vs. User Interface

The site verification code is just text. It, and the additional CSS, is something I can paste into a file. I started with those since they were the least technical and required no new software.

There are plugins that will do all of this too. But this seemed exactly the sort of thing that didn’t need a plugin. For one thing, most of the CSS and both of the verification codes are static. I don’t make changes to them. It is easier to just put them where they belong and forget about them.

Make a Child Theme and Paste Your Styles

For this, you will edit two of your theme’s files. Or rather, you won’t. But the CSS goes into a stylesheet file that your theme can read. The verification codes go into your theme’s header.php file. The best way to do this is to create a child version of your main “parent” theme. This means that edits you make to the files will be added to the theme, and future updates to the theme won’t overwrite your changes.

Here is how to create a child theme in WordPress. It’s essentially three steps:

• create a folder under your wp-contentthemes folder called your theme’s name. For example, I have a child theme for the TwentySeventeen theme. The folder is wp-contentthemestwentyseventeen-child.
• You then to add two empty files. One is called functions.php. The other is called style.css.
• Edit your style.css file.

First, adde the 5 lines indicated in the WordPress guide above. This will enable your WordPress dashboard to display your theme, so you can select it. The Template name is the parent theme.

Now you can paste your custom CSS into this file. It wil be incorporated (and will override) the parent theme’s custom styles when your child theme is the active theme. It will not impact your parent theme if the parent theme is the active theme.

Note: when I disable the Jetpack Customize CSS option, the Appearance > Additional CSS is still visible. If I click on Additional CSS, I get intercepted by the Jetpack Customize CSS option. However, if I click on the Customizer on the Appearance menu, and then click Additional CSS, the option is there. I am not convinvced that you need to put your CSS in a child theme, but I won’t know until I completely remove Jetpack.

Add Your Header.php To Your Child Theme

You want to add your verification codes to your header.php file. Again, you do not want to edit the header.php file in your parent theme. When the theme upgrades, it will undo those edits. Instead, go into your parent theme’s theme folder under wp-contentthemes and find the header.php file.

Copy it to your child theme folder, where you just made a functions.php and style.css file. This will mean you have 3 files in there. Now, edit the header.php and place the verification codes in below the <head> HTML tag and above the </head> tag. I tend to put them right near the top. You can see mine below, with the Google site verification one highlighted. This is really the only one you need, because, if you verify it on Google’s Search Console, you can then go to Bing’s Webmaster site and it will recognize that it’s been verified.

Save the file and you’re done. That’s it. Go back to WordPress’ dashboard and switch to your child theme. It should look the same as when you had the JetPack Customize CSS live. You may need to refresh your cache or purge your site cache to see the change.

How do I create folders and create and move files? I would recommend using Filezilla and connecting to your website with it. It will allow you to create the folders. I would create the two files—functions.php and style.css—using Windows Notepad or a similar text file. Then upload them using Filezilla. For header.php, I would download it from the parent theme folder, edit it with Notepad, and then upload it to the child theme folder. If you make a mistake and upload it over the parent theme header, it will still work but it may not last.

You may also ask the question: wouldn’t it be easier to just get a plugin to do this? Sure. But this is also pretty accessible, so if you have any interest at all in growing your skills around WordPress, these are pretty easy first steps.

So, let’s take stock of where we are:

• Related content Ditched functionality, unneeded
• Performance CDN Ditched functionality, already have Cloudflare
• CSS customization panel Child theme style.css
• Site verifications Child theme header.php
• Downtime monitoring Ditched functionality, already have Uptime Robot
• XML sitemaps
• Brute force protection
• Stats
• Newsletter

Plugins for Sitemaps and Security

I have done the things that I think can or should be done manually. Now I need to identify plugins to fill the remaining gaps. Each of the remaining items is functionality I want or need, I just don’t need it from Jetpack.

Sitemaps for Search

XML sitemaps are machine-readable files that you can create to enhance indexing of your website. These are not the “sitemaps” that websites use to create (and may still do, gods help us). These are not navigation maps but provide a listing of the content—pages and posts, on WordPress, or images on sites like Piwigo—that should be indexed.

There are loads of XML sitemap plugins. I have used XML Sitemap Generator for Google and liked it. It’s a great example of a plugin doing one thing really well. If you just want to fill that gap, this is a good tool. Decision points: it has over 1 million installs, it has good reviews, it is current.

I ended up installing Yoast SEO, although I may revert to XML Sitemap Generator. Yoast does a lot more than I want or need but it includes sitemaps and some metadata functionality that is easier if you don’t have to do it manually. There is a risk, though, because Yoast is a freemium product like Jetpack and I may eventually find that even my bread-and-butter needs require licensing or money.

Once I had installed it and it had generated the sitemaps, I had to go to Google Search Console and Bing Webmaster to update the sitemap URLs that they are indexing. In general, they will re-crawl an index within 24 hours.

Brute Force Security

This was my second-biggest concern about leaving Jetpack. I don’t want to make my website insecure. But, like sitemap functionality, security functionality is widespread. Also, I have done what I can to limit the ability for people to access my WordPress site administration or user functions.

On the server, I use .htaccess to limit access to the wp-admin and wp-login.php content to specific IP ranges. This means a login should really only come from an acceptable IP address. But that doesn’t stop people from trying.

I have a rule on Cloudflare to try to intercept all of those attempts before they get to my site. It blocks attempts that aren’t from an IP range that I use and is a request for a common WordPress acces page:

(not ip.src in { [include your ip ranges] })
and 
(not http.user_agent contains "Let's Encrypt") 
and 
(
(http.request.uri.path contains "wp-login.php") 
or (http.request.uri.path contains "/wp-admin/") 
or (http.request.uri.path contains "/xml-rpc.php") 
or (http.request.uri.path contains "/login") 
or (http.request.uri.path contains ".env") 
or (http.request.uri.path contains "/admin") 
or (http.request.uri.path contains "/install.php") 
or (http.request.uri.path contains "wlwmanifest.xml")
)

I have an exception to allow Let’s Encrypt SSL certificate requests to get through. This list of other pages or resources is based on attempts I’ve seen in my Cloudflare logs. I don’t really know what they all are but I know they either don’t exist on my site or I don’t want people to access them, so I’ve thrown them all together in the same rule.

The free Cloudflare account only allows 5 rules so I try to pack in things that are not always for the same purpose, although they’re related. Sometimes, if you’ve got a rule that works the way you want, it seems easier to just block additional resource requests even if it’s not the exact same purpose.

All of this means that there should be relatively few login attempts that can even reach my login page. I am pretty confident that the Jetpack Brute Force protection was not actually doing a lot of heavy lifting. I couldn’t really tell, though, because access logs were another thing you had to subscribe to see. Free accounts only see the last 20.

I decided to go with another large, tried-and-true freemium service, Wordfence. I also like the Limit Login Attempts Reloaded plugin as an alternative. I use a two-factor authenticator plugin too. Again, it is nice to have discrete plugins just in case something happens to one function and you need to replace it.

But Wordfence provides some features that I liked in addition to limiting login attempts. It will warn you if plugins are out of date and will scan files. It also provides a log of blocked login attempts. So I can see that, so far, no one but me has been able to reach the login screen. It means that Wordfence moves into the “nice to have” column.

Statistics

This all started with a Jetpack upsell for statistics which, for me at least, is one of their least compelling modules. I have always felt the numbers were soft and there was never much detail. They have continued to degrade the WordPress.com statistics interface that displays the Jetpack stats over the past 2 years. Recently they started adding new statistics cards for data like UTM codes but that only worked if you paid. If you didn’t pay, you were just left with a large unusable card sitting in the middle of your stats report.

This is small potatoes but it’s the sort of thing I find irritating. Don’t be an Augustus Gloop, eating chocolate in front of other people without sharing. I use the Stylus extension for blocking extraneous content and I ended up with a growing style rule to block all of this Jetpack stats garbage:

div.list-utm,
div.list-utm.stats__flexible-grid-item--60.stats__flexible-grid-item--full--large.stats__flexible-grid-item--full--medium.stats-module-utm-overlay.stats-module__card.utm.stats-card.stats-card__hasoverlay {display: none;}

The thing I used Jetpack stats for was a quick visual of stat changes, mostly for unexpected spikes. But I use Matomo for my main website analytics. And it has a really nice graph that is comparable to the Jetpack monthly view.

Jetpack has a nice mobile app, although, like its web interface, it has become more and more garbled as Automattic tries to upsell and promote the wrong things. For example, it makes a big deal about noting whether your stats are higher today or lower. Who cares? The visual will show if there is an aberrant spike or drop that needs attention. I can’t imagine who makes decisions with such limited data (what might have caused the spike or drop: a weekend? weather? an advertisement? an earthquake?). I was glad to be able to delete it, which I did before I even started tinkering with the website plugin.

Matomo is a web-based analytics app and has a mobile app, that I have tried and dislike. It is not as rich as the website and the interface requires a lot of clicks to get the basic information I want. But on a mobile Android device, you can just save your main Matomo website analytics dashboard as an “app”. It opens the web page without all of the browser chrome. The phone view looks exactly like the image above, which is the mobile web view.

All of the JetPack upsells, for things like UTM codes and the like, are things that can be created and managed for free without paying for Jetpack.

Almost there!

• Related content Ditched functionality, unneeded
• Performance CDN Ditched functionality, already have Cloudflare
• CSS customization panel Child theme style.css
• Site verifications Child theme header.php
• Downtime monitoring Ditched functionality, already have Uptime Robot
• XML sitemaps Added a new plugin
• Brute force protection Added a new plugin
• Stats Ditched functionality, already have Matomo
• Newsletter

The Final Module: Newsletter

I am down to one module remaining on Jetpack. As of writing this post, I have turned off everything else. The only remaining item is Newsletter, the email subscription option that allows people to receive updates when I publish a new blog post.

This one will be a bit trickier but I’m on the down slope now and will take my time to make the change. The challenge is to migrate the email subscriber list from the Jetpack environment to a new newsletter environment. I am hoping to do it without it being noticeable to the people who receive emails (SPOILER ALERT??).

The first thing I learned is that you can only export your subscribers if Jetpack stats are still enabled. So I re-activated those. It’s not immediately obvious but you can export your subscribers as a comma-separated value (csv) list that can then be imported into most other email newsletter management systems, like MailChimp or Constant Contact.

The reality is I could also ditch this functionality. I don’t make money off this blog and so, in a sense, it’s also in the “nice to have” column. But as I wrote recently, I think email remains a primary information delivery tool and email newsletters in particular are having a resurgence. So for two reasons, that I think it’s important for people to get information in the format they want to get it, and because I think it will be interesting to roll my own newsletter while we are going through this resurgence, I am keeping it. Just not within Jetpack.

I’m still exploring this but I have settled on using the Newsletter plugin. It is another well-regarded freemium plugin. I like that it is using modern functionality and supports GDPR privacy requirements. What I am uncertain about is whether I can just use its SMTP add-on or whether I will need an SMTP plugin like WP SMTP. I don’t have a large subscriber base and so I probably can keep this simple. SMTP is the “simple mail transfer protocol” and it is how we all send emails. So I need to still explore my options for how to send whatever it is I’m going to send. It should be a relatively simple choice and I will lean on my philosophy of choosing the least complicated method possible.

Once I can make this transition, I can deactivate the Jetpack newsletter module and remove the Jetpack plugin. This whole process may seem like I had a wild hair but I really enjoy the exploration and experimentation. The worst case is that I remain with the Jetpack plugin and just the bare essential modules. I think, though, that I will be moving back towards small pieces, loosely joined.

The post Ditch the Jetpack appeared first on David Whelan.