Using Toolbelt instead of Jetpack on WordPress

A screenshot of the Toolbelt plugin in the WordPress plugin directory

A couple of weeks ago, I stopped using the Jetpack plugin for WordPress, and switched to Toolbelt instead.

Jetpack is one of the most popular WordPress plugins and is developed by Automattic, so ditching it has been a big step. Here’s my thinking behind my decision.

What’s wrong with Jetpack?

Jetpack is a big plugin. This is because it does a lot of things, but it can add some big overheads to your WordPress install. Whilst more recently some features have been made available as individual plugins (such as Jetpack Security), many still use the large monolithic plugin.

It relies on services provided by WordPress.com, so there’s background web traffic going there. That can have an impact on your web site’s privacy policy, especially across international boundaries. And Automattic has been in talks with OpenAI and MidJourney about using content from WordPress.com and Tumblr to train AI models. Whilst there’s an opt-out, this really should have been opt-in. My content is licensed under Creative Commons, and I doubt these models respect licensing.

I’m also not keen on how Jetpack inserts adverts for its premium services into my WordPress install.

More disconcertingly, there’s been a recent incident of transphobia that involved a Tumblr user and Matt Mullenweg, Automattic’s CEO. It’s somewhat reminiscent of the Twitter Joke Trial, where an amusing but poorly thought out post got the user into trouble, and Matt waded in. I’ve generally been a supporter of Matt but this incident made me decidedly uneasy. I’m a member of the LGBTQ+ community and try to be a good ally to my trans friends, and I don’t want to support a company which is hostile to trans people.

What is Toolbelt?

Toolbelt is essentially a replacement for Jetpack. Like Jetpack, it offers a wide range of features in a modular way. By default, they’re all switched off, so you just need to enable the ones you want. There’s some overlap with Jetpack, but Toolbelt offers some additional features that Jetpack doesn’t have.

Toolbelt is much more lightweight; since installing it, my WordPress installation feels faster. I haven’t been able to quantify improvements, but pages should load quicker. Hopefully, WordPress will use less server resources too now. It does mean that some things look a little different, as I’m using Toolbelt’s social sharing icons and related posts, rather than those from Jetpack.

For the time being, this means new posts won’t be automatically shared to my Mastodon profile (and occasionally LinkedIn) until I install a different plugin to enable this. And I am currently still using Akismet for spam protection, although Toolbelt offers a comment spam module.

The only major caveat to Toolbelt is that it’s not currently in active development, although it says it has been tested with current versions of WordPress (at time of writing). Maybe it’ll get renewed attention.

A WordPress plugin update fix

An AI generated image of a man holding a giant plug, looking at his watch

For a little while now, I’ve had some issues with installing and updating plugins in WordPress. Trying to do either of these tasks has resulted in the process hanging for a long time, and then eventually failing. As a side effect, the Site Health screen would never load – it was just sit there for minutes at a time, but never timing out. Which was frustrating, as I was hoping that Site Health would give me some clues as to why my site wasn’t, well, healthy.

Eventually, I dug into my wp-config.php file. I’ve edited mine a bit, to add some FTP credentials and define the home page and site URL. This offers a marginal performance improvement as it reduces the number of database calls your site needs to make. With my FTP credentials was this line:

define('FS_METHOD', 'ftpext');

It turns out that I probably shouldn’t have that line there. I commented it out, as below:

/* define('FS_METHOD', 'ftpext'); */

And suddenly everything worked again. Huzzah!

According to the documentation, you probably don’t need to have this in your wp-config.php file and removing it can solve problems. Having it there forces WordPress to use a particular method for interacting with your host’s file system, but by default WordPress should choose the correct method automatically.

I’m guessing it was in there after I copied and pasted some code from somewhere else, without knowing what it did. Which is a reminder that just copying someone else’s code without understanding it is not a good idea.

New theme, who dis?

Screenshots of the old and new themes for the blog, side by side

I’ve deployed a new theme on the blog. If you’re reading this in your feed reader, firstly, go you, because so few people do nowadays, but also, please click through and have a look.

The theme I’m using is GeneratePress, with mostly default settings. This replaces one of the default WordPress themes that I was using before.

Why the change? Mainly page bloat; whilst the default WordPress themes are very extensible, the output code includes shedloads of extra JavaScript, CSS and style tags which result in web pages which are bigger than they should be. Whilst I’m at no risk of exceeding the data transfer limits offered by my hosting company, it does affect the speed of the site, and not everyone has unlimited mobile data or a fast connection.

I learnt HTML at a time when it was the done thing to hand-code pages – indeed, back when I used Blogger and later Movable Type as my blogging tools, for the most part I used themes that I had written all myself. JavaScript was used very sparingly, and the HTML and CSS code was nice, clean and simple. So seeing the code soup that was being outputted by the default themes was off-putting.

I also think about this blog post by Terence Eden, ‘the unreasonable effectiveness of simple HTML‘, where he gives an example of someone applying for housing benefit on a PlayStation Portable (PSP). This is presumably because it’s the only portable device with a web browser that she can use. But because the HTML on gov.uk is so clean and lightweight, the old, under-powered web browser on the PSP is still able to render it, and she’s able to get the information that she needs. A big, flashy web site oozing with various JavaScript frameworks, loads of tracking scripts and adverts everywhere just isn’t going to work on such an old device.

And then I saw this toot today:

I can't help but notice the new Apple laptops rate "Video Playback 22 hours, Web Browsing 15 hours" under battery life.

Congratulations web developers everywhere, it's now more computationally intense to render a webpage than video playback!

— Brad L. :verified: (@reyjrar) 2023-11-05T04:41:28.299Z

Web pages are getting so full of cruft, that they require more processing power than video playback.

So, that’s why I’m going with a lightweight theme. It makes the web site much more accessible to more people. GeneratePress seems to output lighter code that displays fast, and it offers a good balance between extensibility and speed. It won’t be for everyone, but it seems to work well for me.

The times, they are upgrading

An AI generated image of a superhero emerging from a server cabinet, generated using Microsoft's Bing AI Image Creator

Hello – if you can read this, then the server upgrade worked!

I’ve wiped the previous server image (yes, I remembered to do more than one type of backup this time), and installed a freshly upgraded version of Linux. This means it’s running on Debian 12 (codenamed ‘bookworm’), and version 12 of Sympl. Sympl is a set of tools for Debian that makes managing a web server remotely a little easier, and is forked from Symbiosis which was originally developed by my hosting company Bytemark.

Going nuclear and starting from a fresh installation was for two reasons:

  1. The next version of WordPress, which will be 6.4, will have a minimum recommended PHP version of 8.1. This server was running version PHP 7.3, and whilst I’m sure future versions would work up to a point, it’s a good opportunity to upgrade.
  2. I’ve had a few issues with the previous installation. The FTP server software never seemed to work correctly, and the database (MariaDB) would lock up almost every time I posted a new blog post. Hopefully, this won’t happen anymore.

As this is a fresh WordPress installation, there may be a few things which don’t quite work yet. I’ve imported the existing blog posts and pages, and the theme is mostly the same, but I need to re-install the plugins and probably need to amend some settings. I’ll sort these issues out over the next few days.

WordPress in the Fediverse

A screenshot of the settings page for the ActivityPub plugin for WordPress

If I’ve set up everything correctly, then you should be able to subscribe to this blog in your favourite Fediverse app, such as Mastodon, by following @nrturner@neilturner.me.uk .

You’ll need to install the ActivityPub plugin, and then it should just work where your fediverse username is @your-wordpress-username@your-domain.tld. If you’ve used a plugin to disable author archives, such as Yoast’s SEO plugin, you’ll need to re-enable it for this to work.

I found this guide particularly useful, as it links to Webfinger to test that you’ve set it up correctly.

(Update: since this post was written almost 12 months ago, the ActivityPub plugin has been formally adopted by Automattic and so enjoys wider support)

Goodbye Melody, Hello WordPress

https://www.flickr.com/photos/neilt/20932089/

It is with something of a heavy heart that I’ve decided to abandon Melody and move the blog to WordPress.

Long time readers will find this as a surprise – in the past, I’ve defended Movable Type when I’ve felt it under attack from WordPress ‘zealots’. Back then, WordPress was the new kid on the block, whilst Movable Type was much more established. Today, however, the situation has changed, and this is why I’ve made the change.

I left Movable Type earlier this year for a few reasons. Firstly, after trying Movable Type 5, I found it was aimed at large, professional blogs and not personal blogs like mine. The 4.3x line is still being maintained with security updates – MT 4.36 came out last week – but not with new features.

I hoped that Melody would provide a good continuation of MT 4.3x. Unfortunately I’m not that impressed – whilst it has improved some aspects of Movable Type, it hasn’t been the major step forward that I’d hoped it be. Furthermore, a number of plugins that I found really useful in MT didn’t work properly (or at all) in Melody, and as some of them were several years old and seemingly abandoned by their authors there was a slim chance of this happening.

It’s well known that the past few years has seen Movable Type stagnate. When I first started using it in 2002, there was a very active community developing plugins and themes for the platform. But this community has all but died out, and despite the best intentions of the Open Melody group it hasn’t re-ignited. The MT community is, basically, dead.

WordPress is where the community is. Whilst blogging in general is past its prime, WordPress still has a large number of themes and plugins which work with the latest version, plus active support forums. The documentation has even improved.

I’ve also changed. I don’t revel in spending all night adding new features and installing plugins. I want a blogging system that just works.

What made me choose WordPress is taking over administration for the web site for one of the student groups that some friends are involved in; this previously used WordPress and rather than try to shoe-horn it into Melody I decided to stick with it. The system proved to much easier, more manageable and more slick than MT or Melody ever was. Upgrades, in particular, were very easy. So having used it for a while, a few hours ago I decided to migrate this blog too.

Getting the blog up and running in WordPress has been pretty easy – the import process from Melody was quite straightforward and work fine. I’ve then spent no more than a couple of hours trying some themes and getting the configuration in place. Despite being a completely different system, migrating from Melody to WordPress has taken about the same time as Movable Type to Melody.

The current theme is somewhat temporary – I haven’t yet decided on a final one. In the meantime I’d welcome any comments you may have.

Why I’m not switching to WordPress

Now that I’ve announced the book, I’ve had a couple of emails on the lines of “So I’m guessing you’re not switching to WordPress now, huh?”, and indeed I’m not. The book, however, is not the only thing that’s keeping me with MT and I’d like to use this (rather long) entry as a list of reasons why I’m not likely to switch any time soon.

Firstly, MT is what I’m used to. As of the middle of next month, I’ll have been using it for 2 years – whereas I’ve been using WordPress for less than 3 months. It’s the same reason why I use Windows as opposed to Linux – sure, Linux may be more secure and less likely to crash, but I know how Windows works and I feel comfortable in that environment.

Secondly, there’s the templating system, which I’m afraid to say, sucks. Again, maybe I’m just used to how MT works, but altering the way comments display in WordPress requires a lot more time and knowledge than it does in MT. In MT, the templates are totally separate from the MT source code – in WordPress, that separation isn’t so finely defined. Indeed, when you edit wp-comments.php (in 1.2) you’re faced with a 20 lines of PHP that you can’t edit before being able to dig in. And even then, you get comments like “if you delete this the sky will fall on your head” – hardly reassuring for a newbie.

Want to alter how the RSS feeds display? Then you have to edit a page with lots of PHP code which can’t be removed for fear of the sky falling on your head, and with a warning about this being an integral part of WordPress. You also need to know what the file is called since it’s not linked in the WordPress interface. Adding new pages, especially new types of feeds, seems to require a good understanding of PHP – adding a new template in MT is far, far easier.

WordPress isn’t all bad though, and it’s a whole load easier to install than MT is. In fact, a newbie to blogging* would be better off installing WordPress than MT, and includes nice blog-centric features like a links manager. But if you want to control how your site displays and don’t know much PHP then MT is the way to go, in my opinion.

(* = a newbie to blogging would really be better off on a service like Blogger or Typepad, but if they wanted something they could run themselves, WP would be easier than MT)

WordPress also wins on the comments front, despite what I said above, since it has much better comment management features built-in (although in 1.2 they are rather hidden away). That said, MT is brilliant once you have MT-Blacklist installed, since it deals with all the duplicate comments and spam perfectly, but that isn’t included out of the box (though it will be available with MT 3.1).

Rebuilds seem to be a bone of contention with some – if your web server isn’t so fast, they can take forever. I’ve never really had that problem as my host’s servers seem to run well (and I have optimised MT a bit to make it faster) but some people do find that rebuilds take forever for them. With that in mind, I suggest you wait for MT3.1 which adds support for dynamic pages. This will give you the best of both worlds – pages that get requested often like your indexes and feeds can be static, whereas other pages can be generated on the fly as needed. Sure, you can install a caching plug-in for WordPress but it’s not something that’s there out of the box (in 1.2, at least). The result is that rebuilds will be much quicker since only 2 or 3 files are being regenerated each time, plus, unlike in WordPress, you won’t have the PHP preprocessor kicking in and doing an SQL query every single time someone requests your RSS feed.

Rebuilds are also quicker in MT3.x due to its more efficient use of SQL queries and background tasks. Since upgrading to MT3, this site has been a whole lot faster, though I am working a new search script to replace mt-search which is a little slow.

Both packages have plug-ins and while WordPress kicks MT2.x’s arse in that respect, MT3.x does have much better plug-in support and many more hooks to allow developers to integrate their plug-ins with the MT interface without needing to modify the MT source code (detect a theme here?). For example, with MT-Blacklist installed, the comments mass editor has a ‘despam’ link added for running comments through the blacklist and removing the bad ones. As more plug-ins designed for MT3.x are released I’m sure we’ll see some truly great plug-ins that integrate tightly with MT.

MT’s help is better. There are some very extensive help documents provided with MT, whereas WP has a few links back to its rather sparse documentation pages on its web site. There’s also the wiki but like many wikis it suffers from a lack of structure, and some areas are quite patchy, in my opinion. Trying to have information only display on an individual entry page meant having to use a seemingly undocumented PHP function, for example. Apparently the #wordpress chat room is a good source of help but I’m not comfortable with asking for help in chat rooms and it assumes that you have an IRC client and that you’re on a connection that doesn’t block IRC like my university does.

This is getting quite long but as you can see, I have my reasons for not switching. What this isn’t is a “WordPress sucks and I can’t believe you all use it” rant, it is merely pointing out that WP is not for me. I’m sure that when WP reaches maturity it’ll be much better and I may give it another look when it hits 2.1 or something, but I’ve yet to be totally impressed. MT is at 3.01 now and feels much more mature than WordPress does. That said, my test install isn’t about to disappear any time soon, though a test install is what what it will remain.

I’ll leave comments open on here – I know this may seem controversial to some of you so please play nice.