You probably don’t need that calendar


I came across another empty calendar on a WordPress site today. It reminded me of a lot of sad meetings where someone said “We should put all our events on a calendar on our website so people hear about them.”

Someone added ‘calendar’ to the requirements list. A plugin was bought, installed and configured. The first batch of executive meetings, general assemblies, and conferences was entered. And then… nothing.

Unless your organization marches daily to its calendar — the people who come to your scheduled events bring you most or all all your revenue, for example— you probably don’t actually put on enough events to bother.

Maybe you have a couple of important events a year. They could even be essential. But you don’t have to have a whole hoo-ha of a calendar to display those on your site. And in fact — if those events truly are important — it’s better that they’re not on a calendar plugin anyway.

Calendars are off to the side. They’re a separate content stream that gets its own visual treatment, has its own metadata and lives in its own space. To bring events to the fore, site editors have to write posts about events or similar editorial shims, hard-coding a link to a time-sensitive bit of content and setting up a broken link in the near future.

And then, after the event passes, you have instant outdated content — a news item pointing to an already-happened event.

What to do about the passage of time

So skip the calendar. Use a plugin like PublishPress Future to give the post announcing your event an expiration date. If the notice of the event needs to stay on the front page despite having newer items, make it sticky or put it in your carousel. Or make it your hero image CTA. The event organizers will probably want that anyway. And they will be happy when they don’t need to remind you to take down the post about the event that just happened.

Or, use something like Toolset to create a calendar where ‘events’ can be folded into the regular content stream while maintaining their date-sensitive display settings. This will be expensive in terms of developer time, but it might be the most elegant solution for a site that needs to display ‘a few important events’.

It is possible for a user interface to be too simple

man in black shirt

A client was getting really frustrated because the social media previews for their site were out of date. They had a new hero image and page title but every time they tried to share the page — whether using the site’s share buttons or just pasting the URL into Facebook or Twitter — it still showed the old one.

Now this stuff is generally a bit too close to alchemy for my taste. Sharing previews are extremely important but the mechanics of how various social media platform construct them are… well, they’re not shrouded in secrecy, but you really do get the impression the developers at Facebook and Twitter aren’t telling us everything.

They have, mercifully, put together tools that let you sleuth these things out. They’re a bit nerdy, but they take you through the code and they show you how their services see your site.

Great. So far. But the Twitter and Facebook tools were indeed previewing the site as the site instructed.

The site’s source code made me think that it was in fact the plugin the site uses to present social media sharing options that was producing the outdated Facebook preview/Twitter card markup.

But the plugin’s admin screen listed nothing about Open Graph tags, or configuring previews or cards or anything.

Its admin page consists of a series of plain language interview questions that ask a site administer basic questions about their social media icons, like: how do you want them to appear? Where do you want them to appear?

They did this probably because configuring social media buttons is kind of a pain in the ass for not a lot of return. Very few people use them. But getting them to appear attractively (to the extent that’s possible at all), in the right place, and to behave as required, is fussy technical business.

I understand the developer’s desire to smooth that path for their customers.

And you would think that one of these helpful, easy to understand questions would be “How do you want your social media previews to appear?”

Nope. I went through each of the so-easy-to-use questions until I got to number six, “Any other wishes for your main icons?”

Expanding this accordion reveals a fairly detailed set of options for configuring social media previews, at least for Twitter, Pinterest and Facebook.

But lord, you’d never know it.

I submitted a support ticket with them identifying their plugin’s failure to provide a way to update Open Graph information or a bug in their algorithm for generating Open Graph tags or its inability to work with the site’s server-side caching plugin or who knows what.

I feel the developer smoothed out a complicated process so much in the name of usability that they actually made their product less useful.

Like a car with two knobs on the dashboard, one to turn it on, the other for everything else.

WordPress plugin pruning: why you need to do it

Prune your WordPress plugins

A client site suddenly went all catatonic on me when I was trying to log in. I could key in username and password and click the login button, but nothing would happen.

Websites are like gardens, after all. Or trees for that matter.

The post request wasn’t sent. No error message came back. Nothing. I thought maybe security. My email address had been in a list of pwned emails so I thought maybe the security plugin suite was blocking my address.

But the client couldn’t log in either.

So I did the usual process of elimination ritual. I disabled all the plugins. I was able to log in.

I started adding the plugins back one at a time. The problem plugin was Awesome Flickr Gallery plugin. Apparently it was condemned in March 2020 for some guideline violation. But it’s been effectively orphaned for years.

“No worries,” the client said. “I’ve got a lot of other Flickr plugins I can use.”

“What? Why?”

“I try them all out and settle on the one that works best. Only I forget to uninstall the ones I don’t use. Is that bad?”


It’s most assuredly bad to leave them activated. They can compete for the same variable names, API access etc., and drag each other — or even the whole site — down.

Worse still they can become windows of vulnerability for bots or hackers seeking unauthorized access to your site. And if you’re unwilling to take the trouble to deactivate and delete unused plugins, you’re almost certainly unwilling to keep up to date on which plugins have vulnerabilities that hackers are exploiting.

But even if you deactivate them, they can still cause you problems. The plugin’s files and directories are still present and could bring you unwanted attention.

By deactivating them, you tell WordPress not to run them. But through the magic such as cross-site scripting and other lovely tricks, hackers can run them for you, so to speak. And there is no way of knowing what path that sort of attack might take. But it won’t end well for you.

The update nag notices will still clutter your admin screen. You’ll become inured to them and ignore them so habitually that you won’t notice when something comes up that matters.

Please prune your plugins. By that I mean:

  • deactivate the ones you can’t think of a use for;
  • run a series of tests to see if your site behaves as expected (create a post, upload an image, attach a document, buy a product etc etc)
  • if it does delete the plugin
  • lather, rinse, repeat for every plugin until you’re left with activated plugins whose function you understand and require.

This cautionary tale is about a WordPress site and uses that platform’s lingo but the same logic applies to all other freely-available content management systems including Drupal and Joomla.