Tag: the-work

Posted on

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?”

“Yes.”

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.

Posted on

Website updates – you really must do them

Website updates: do them or pay someone but do them

Website updates don’t follow the logic a lot of us inherit from the era of software updates that arrived in the mail on a disc of some kind.

Before there ever was broad public access to the internet, going forever without updating your software was a  point of pride for most people who did a lot of computer-driven communications work.

Or it was a mark of world weary wisdom because we’d arrived at the point where we knew that the X.0 release of anything was going to suck rocks. We’d wait. Until X.1 or .2.

The updates were expensive, disorienting, and if they did cause a problem, the solution could be months away.

So trying to get a personal best time and distance between updates made sense.

But you cannot transpose that logic onto your web application.

Because your web application — be it WordPress, Joomla, Drupal or any number of others out there — is not safe and sound in your office.

It’s on a computer on the internet which is, for all intents and purposes, the equivalent of leaving it on the counter in an all-night convenience store off a freeway where the counter clerk is asleep.  Only worse. Because unlike the convenience store, your server gets all the traffic in the world coming through it.

And unlike your computer, which accepts input only from a keyboard, your website is on a server, which accepts input from anywhere. By definition.

But I don’t have anything important on my site

Maybe not credit card numbers, bank account information or medical histories, but you have your reputation and/or your brand. And if someone gains unauthorized access to your site and starts abusing it (which it almost goes without saying they will) these will suffer.

You will have to apologize to clients, prospects and anyone who was coming to your site for any reason about the fact that your site was hacked. You will have to insist that your inability to maintain a website has nothing to do with your competence generally.

And you will lose time. Possibly weeks. You will be restoring your site from backup or recreating it if you didn’t have a backup. You’ll be trying to track down the vulnerability and check the whole attack path to determine if the attacker left any other back doors or malware that might allow them back in. You will be visiting all the security websites to ask that your site be removed from whatever spam or phishing blacklist you’ve been put on.

Or you’ll be paying a security consultant or company at overtime rates to do all of the above.

But no one would want to hack my website — I’m not the CIA/Microsoft

You’re assuming that the hackers are actually human. And you’re mistaking media coverage of famous hacks for what happens in everyday life on the internet.

Most website break-ins are perpetrated by robots which scan the internet for sites that might be vulnerable. They find a site that has the vulnerable application, run the exploit against it, and, if they succeed, install the malware and get straight to work. At some point some human put this process into play and will be interested in the results, but they have no idea who you are, what you do or what a nice person you are.

They’re not interested in defacing your site to show how cool they are or to denounce you for being a tool of the capitalist class or whatever. They want your site as a platform to send spam, serve porn, collect passwords or phish other data from unsuspecting visitors. And for that, one site is as good as the next.

What if I don’t have time to do all this?

Self-hosted websites do indeed take time and expertise to run smoothly. The skill required to apply updates, do backups, and tweak performance can be acquired if you have a bit of time and some curiosity. But if you don’t you can get someone, like me for example, to do it for you. For a small site it’s generally about an hour a month. Plus you get my advice on improvements, best practices and life in general. A bargain at twice the price, really.

Or you can move your site to a software-as-service setup like WordPress.com or Wix, or Weebly where the service itself looks after security, updates and backups. The monthly hosting cost ends up a bit higher, and it may limit the sorts of things you can do with the site, but if you can fit within those constraints and aren’t bothered by an extra $10-20 per month, it might be your best bet. That will be cheaper than paying me or someone like me.

Posted on

Auditing website content that isn’t there

Content audit missing content gaps

Content audit missing content gaps
How do you audit missing content?

Website statistics can tell you a fair bit about what visitors are finding on your site.

But they cannot tell you anything about what they’re not finding.

And that is at least as important — probably more important, if the goal of your content audit is to make the site more useful to its audiences.

But where to find something that isn’t there.

There are clues in emails, messages sent via the site’s contact form, phone calls and discussions with the site’s content sponsors. Do an audit of:

  • Questions visitors ask by email or via the contact-us form?
  • Phone calls the organization gets?
  • Documents the organization’s leaders/reps/experts repeatedly send via email or (shudder) fax?

Auditing missing content involves tracking these inquiries — whether on paper, or a spreadsheet or any way with which you’re comfortable — for a short time: a week, a month, as long as you have.

Then look at the answers to those inquiries and determine:

  • Are they already on the website and if so why are they not being found?
  • If they’re not on the website, could they be?

If the answers are on the website, but they’re not being found, why is that? What’s the language the visitor is using? Does it match how the content is described? Is the content behind a menu item labelled something strange or something that visitors aren’t expecting?

If it’s just not on the website, can you write the answer in generalizable terms? Can you write an answer or answers that apply to most or all of your visitors?

Posted on

PDF strategy in a can: getting to an accessible website

PDF Strategy: Put all your PDFs in the trash

Put all your PDFs in the trash
Self-serve PDF strategy

The onset of the legal deadline for organizational and business websites to be WCAG 2.0 A-compliant has produced a flurry of activity around internet accessibility. Having a PDF strategy is part of the solution.

Because in my experience, what’s killing them – and costing them – most are their PDFs. (And slideshows, but that’s for another post).

Website producers in organizations where creating content is a print first, or print-only affair have to confront the results of years of using PDFs as a kludge for getting content onto their site.

You can make PDFs accessible. But the tools are awful, and it’s time consuming. Especially if all the work is done after the fact. Any time you thought you were saving by tossing that PDF onto the bottom of that page evaporates when you undertake to make it accessible and searchable.

Companies and organizations that are trying to make their front-facing websites comply with the Access for Ontarians with Disabilities Act (AODA) learn that, in addition to retrofitting their PDFs, they have to come up with a PDF strategy.

As a public service, here’s what I call a proper PDF strategy.

  1. No PDFs shall be posted to the website.
  2. See rule number 2.
  3. Any PDF currently on the website will be removed and replaced with an HTML version at the earliest opportunity.
  4. If for some reason you were undeterred by rules 1 and 2, it is conceivable that content could be posted in PDF format if the document is:
    • only intended for print purposes: e.g.: directional signage for a conference, or some other public display etc.;
    • so long, complicated or its production values are so high that conversion to HTML would exceed the content’s lifespan or be otherwise too complicated to be worth the effort.
    • evidence of some kind – the primary source for a research project, an ATIP request, a love letter from a rock star or the like
    • has been:
      • OCRed,
      • edited to add meaningful metadata,
      • tagged in the original application (human-revised auto-tagging after the fact is permissible but will earn you extra stink-eye)
      • formatted and configured to print on the sorts of printers your visitors likely possess (e.g.: no printer spreads crop marks, separations, shrink-to-fit letter-sized paper, 300ppi 54lpi resolution/halftone screen etc)