LISA 2017 Presentation: WordPress Maintenance and Troubleshooting

Good morning. It’s now 9 o’clock so I’m going to go ahead and get started.

This is WordPress Maintenance and Troubleshooting. As you probably know, WordPress is an open source content management system or CMS. A CMS separates the content – text, images, whatever – from the code needed to make the website happen. They’re great for updating a site without having to hand-craft the HTML at the same time.

Who I Am

So I’m Dash Buck. I’m a front end web developer. I work with small businesses and nonprofits of various sizes. Most of my clients use WordPress. And I apprenticed to a WordPress developer for two years.

I’m also an educator. I teach a WordPress 101 class and run a WordPress study group in the Seattle area. I also offer tutoring and staff training to my clients.

And I’m nonbinary, specifically agender. Please use they/them pronouns when you’re talking about me. You can also use he/him pronouns if you absolutely can’t wrap your brain around they/them. I’ve got a great FAQ here if you’re new to this idea or want to argue about the validity of they as a singular pronoun.

So that’s me. Now let’s talk about you.

Who You Are

You are a sysadmin or related IT person who knows the basics about web servers and static HTML websites. If you know more that, cool, welcome! That’s just the minimum, because I won’t be explaining how the internet works.

And you’re here because you need to take care of your organization’s WordPress website, or you’re transitioning to WordPress, or you’re thinking about using WordPress.

What This Tutorial Will Cover

This tutorial is going to cover the following topics in the following order:

  • When to use WordPress (or not!)
  • How to take care of a WordPress installation
  • Troubleshooting your install
  • WordPress Public Service Announcements
  • Answers to Your Questions!

What This Tutorial Will Not Cover

This tutorial is not going to cover the following: >

Creating WordPress Themes or Plugins, PHP, HTML, CSS, SASS, Twig, or Drupal. We just don’t have time, sorry.

When to Use WordPress

Okay, let’s talk about when to use WordPress.

If your org is regularly changing content on your website or would like to, you can’t just throw up a static site and be done with it.

If you have a small time and money budget, WordPress is pretty cheap on both axies compared to other CMSes. You can get a decent looking website set up for almost $0 in an afternoon if you know what you’re doing.

If you need a simple site now but might need more later – WordPress is designed to be modular. It’ll let your site grow and change with your org. You can add onto and level up your installation piecemeal as you need things, or have time to add features. You can also update the design of your website without having to recreate the content. This can be important, since web designs age quickly.

If you want to control your content and your connection to your audience, WordPress is not a walled garden. If you use a proprietary website builder or focus your online presence around social media accounts, you don’t have control over your content or your communication with your customers. Your provider could change the GUI or the API without warning. They could change their fee structure, or go out of business, or get acquired by someone you hate. Then your org will have to recreate everything.

And of course, if you’re using someone else’s service, you have to rely on them to keep the server running and your data secure.

WordPress is turning fifteen next year and it runs 28% of websites. It’s not going anywhere anytime soon. There are regular security patches and you can run your own instance on your own server with your own theme. I’m a fan.

That said, WordPress isn’t the right fit for every org.

When Not to Use WordPress

Don’t use WordPress when:

You need a custom web app. Your online visitors are trying to complete very specialized or high security tasks.

Your org already has a great website and a staff that can easily take care of it. If it’s not broke, don’t fix it!

If you or your org doesn’t have an hour each month to do basic maintenance, now is not the time to start a new WordPress project. Maintenance can be taken care of by your web dev – I take care of maintenance for my clients usually – but you probably wouldn’t be here if you had a web person taking care of you.

Your org doesn’t have the resources to create and update content. If you won’t be updating the text and images on your site more than once or twice a year, a static site would probably serve you better.

You don’t need an online presence. If you’re part of a larger organization that already has a good website, or if you’re part of a super secret spy organization that needs to avoid public attention, you should not use WordPress.

Themes and Plugins

Themes and Plugins are where a lot of the power and flexibility of WordPress comes from. If you’ve worked with other CMSes or similar software, you might think of these as extensions. They’re added to your WordPress install once it’s set up, and they live in the same folder structure on the server as WordPress itself.

In general, Themes control the visual display of a website: the colors and fonts, the scrolling to click ratio, whether the site looks okay on a phone, stuff like that.

Plugins, on the other hand, customize function. There’s a lot of plugins out there. If you need a plugin for a common website function like a calendar, you’re going to have a frankly ridiculous number of options. There’s just no guarantee that it’s functional or maintained properly, let alone good.

Sometimes Developers Cheat

As a sidenote: sometimes devs cheat! Themes often have custom functions, not just visual display. Now, it’s understandable to have a little function in a theme. There are a lot of functions that create visual output, and it’s easier to style output you’ve designed yourself. But some folks go way overboard. These themes are usually clunky and inflexible, with only one expected use case, inexpertly executed. They’re not hard to spot – the sites selling them usually want to tell you all about their wonderful features. They’re also usually aimed at a specific non-tech-savvy business area, like real estate.

Plugins often affect visual display outside of their functions. A certain amount of this is expected for the same reason as themes: styling the custom output your plugin creates. But some plugins make massive changes, adding entire design elements or attempting to control vast swaths of the display. These are aimed at users and designers that don’t have access to a dev and don’t want to code. Some of these plugins can be good options if you’re in a hurry, on a tight budget, or hate writing JavaScript. But most of them are clumsy hackjobs because they’re trying to control the display, which is already being given orders from the theme.

I call all of this “cheating” because, like many other coding cultures, there’s a “WordPress way.” The WordPress way is to separate form from function whenever possible, and put them in their appropriate places. When done correctly, it allows website owners to have the look that they want in the theme, and the functions that they want in the plugins, without any weird extra riders or conflicts to deal with.

Okay, with all that out of the way, let’s move on to the actionable stuff.

First Things First

If I was told that a WordPress site was now my responsibility, this is what I would take care of ASAP.

  1. You should have a login to the WordPress admin area, sometimes also called the back end, just to be confusing. Make sure your login has an Administrator role (or Super Admin if it’s a multisite). “Roles” are how WordPress handles permissions. You need an admin role to run updates and manage user accounts.
  2. Your org should have the keys to your domain registrar and your hosting. If either of these are purchased by, under the name of, or otherwise controlled by an individual, your site belongs to them, not your org. That’s bad. Fix it. Even if you trust the individual, stuff happens. Contracts end, people change jobs, whatever. It’s better to move that info into the org and out of an individual’s hands.

By the way, throughout this I am going to assume that you’re using a hosting service instead of standing up a webserver yourself. I know that’s not always going to be the case with you folks, but it’s where a lot of my experience is and there’s stuff you need to know if you’re using a hosting service.

If you don’t control your DNS, your traffic can be redirected by a bad actor. Or your website address could stop resolving if the yearly payment isn’t made. If you don’t control your hosting, your data can be stolen, deleted, or altered. Or heck, held for ransom by the web dev you’ve just fired – that happened to one of my colleague’s clients. Fun times.

You might also want to make sure that your content and any custom web designs your org might have are licensed correctly, either copyrighted or some sort of creative commons license. That way you can make changes in the future without worrying about someone kicking up a fuss. This seems like an excellent time to remind you that I am not a lawyer and licensing is not my area of expertise.

The next three things I’ll go over in more detail: backups, salting wp-config, and moving to HTTPS.


You need backups. There will come a day when something that cannot be fixed happens to your site, and you will need a backup to restore your data.

Hosts will often offer backups as a service. The expensive ones generally roll it into the hosting charge. Don’t trust your host to keep backups for you unless you’re explicitly paying them to do so…and maybe not then, either. I mean, if they lose your data, they lose your business, so they have an impetus not to mess it up. But I wouldn’t trust it until I’d tested it.

Run backups more often than your content changes. If you’re changing monthly, backup weekly. If you’re changing daily, backup hourly. If your content is changing hourly…what are you doing? Are you, like, aggregating and displaying data or something? Do you really want to use WordPress for that?

Anyway. Keep at least a couple month’s worth of backups, preferably more. If my client has cheap storage, I usually don’t bother deleting backups. It can take time to discover that malicious code has gotten into your system. You might have to reach pretty far back to find an uninfected version of your data.

If you have more time than money, and are comfortable with terms like “cron,” you could set up a backup process yourself. If you decide to go that route, do yourself a favor and check out >

wp-cli. It’ll give you access to your WordPress install from the command line, which is pretty shiny. You’ll also want to check the documentation on wp-cron, which works a little differently than system cron.

Or you could just use a plugin.  There’s a lot of backup plugins out there; my go-to recently started to disappoint me in quality, so I can’t recommend it anymore. I’m currently using a freemium plugin called Updraft Plus, but I’m still in the testing phase so I’m not sure I can recommend it yet.

Backup Plugin Features

Here’s what to look for in a backup plugin:

Automated, scheduled backups to your cloud storage of choice. Some plugins only do manual backups, or only local backups, and nobody’s got time for that.

That said, you will need the option of manual backups so you can run one when you’re taking care of updates. More on that later.

You should also make sure that the plugin backs up both your files and your database. Your themes and plugins and images and stuff are in the files, but the rest of your content is in the database.

There should be a short, reliable series of steps to restore from backup, probably a button in the WordPress admin area. Rolling back changes can be a tricky, messy business by hand and I never do it if I can avoid it.

Incremental backups are useful in theory for huge sites, or limited storage space, or low bandwidth. Some plugins supposedly do incremental backups, but I haven’t seen one that works properly.

And if you’re running a multisite install, you’ll need to make sure to pick a backup that explicitly handles that.

Whichever one you choose, you’ll have to test it. The manual backup usually works, but the automatic backup and cloud storage connection are more difficult to get right. My previous go-to stopped having reliable cloud connections and started dropping auto backups.

Salt wp-config

Next step: salt wp-config. If you’re installing WordPress or have just inherited a WordPress installation, make sure to properly salt your config to keep your user’s credentials safe. You can read the official instructions here, but I’ll go over it anyway.

SFTP or FTP into the WordPress install. In the root folder, there’s a file called wp-config.php. If you haven’t finished going through the installation dialog, there might only be wp-config-sample.php; you’ll want to go and finish installation and then come back and do this step.

About 3/4ths of the way down the file you’ll see a chunk of code that looks like this (see previous slide).

You’ll want to replace it with a set of unique salts.

You can generate a nicely formatted block of salts here.

Copy and paste your replacement code block into wp-config.php, save and upload, and repeat whenever you want to invalidate everyone’s cookies and force them to log in again.

Site-wide HTTPS

The next thing to do is set up site-wide HTTPS. It’s not just for payment pages anymore! This goes for everyone, not just folks on WordPress. Tell your friends. Sometimes it’s called SSL or TPS/SSL, those are the cryptographic algorithms used to put the “S” in HTTPS.

By the way, if you need some ammo to convince folks to switch over, Google started penalizing non-secure sites in their search results as of last month.

Get a free security certificate from In this case, free is better than paid. If you pay for your cert, there’s even odds your reseller is going to give you one from Symantic. They aren’t, uh, super trustworthy lately, so I don’t recommend it.

Since this is just an extension of technology that’s been in play for years, pretty much every host should be able to handle HTTPS. The actual method to set it up is going to change from host to host, though, so I can’t go over it here. There should be documentation and/or customer support you can use. If they insist that you have to pay for a certificate through them, they’re probably a bad host and you should move.

HOWTO: Maintenance

Once you’ve got those first things handled, WordPress maintenance basically boils down to regular backups and regular updates. WordPress is a super popular CMS, so it’s constantly being attacked. If you’ve updated recently, it lowers your risk of a successful attack against your site.

I generally recommend running updates on a monthly basis. In my experience, monthly is the happy medium between spending too much time on maintenance and spending too much time fixing issues that happened because you didn’t do maintenance. Although I have been known to run updates whenever I have the time and I happen to be in the admin area taking care of something else.

There are times you should absolutely take your updates ASAP, and that’s when a massive security hole is patched. I had to doublecheck all of my clients for plugins affected by Heartbleed, for example. There was another one a couple years ago that was WordPress specific that I had to do an update mid-month for. Before you ask, there is no good source for WordPress specific security alerts; I have to kind of keep my ear to the ground and ask my colleagues to keep me in the loop. It’s not great. I’m trying to fix it but I don’t have anything solid yet.


Okay, here’s how to run updates. If you have a staging site, run updates on it first! That way if you run into problems you can fix them without disturbing your visitors.

Whether you’re running updates on staging or live, the routine is the same.

  1. Log in. The default address to hit the WordPress admin area is
  2. Run a full backup. Put it somewhere you’ll be able to get to easily, probably your local machine. You’ll need it at hand in case something goes wrong. >
    1. (See next slide) Then either click here or here to hit the Updates page. This is the number of updates you need to run. If there’s no icon, everything is up to date. <
  3. Run updates in the following order: plugins and themes, then core. They’re more likely to be reverse compatible with previous WordPress versions than vice versa.

Okay, that’s the basics of maintenance. Now we’ll start getting into troubleshooting. Well, the gray area between maintenance and troubleshooting, because I recommend doing some preventative testing right after running updates.

Preventative Measures After Updates

Once you’ve run updates, check to see if the updates made anything weird or broken. Log out and spot check the pages of your website, especially any pages affected by plugins, such as contact forms. Logging out for the check is important – you get a different experience from the average visitor when you’re logged in as an admin. For example, injected spam will hide itself if you’re logged in!

If you have users, log in as a user and check to make sure you can complete normal tasks. I’ve had bugs happen to lower permission users that didn’t affect admins.

You’ll need to run these checks on both staging and live. Paid plugins don’t usually work quite right on staging since licensing is on a per-domain basis.

If you run into a problem while you’re error checking, you’ll need to either partially or completely roll back the update. This is why you need to back up right before you run updates.

How to Undo Updates

If you’ve got a good backup plugin or you’re using a website backup service, you should be able to just restore from backup and get everything working again. If something went horribly wrong or you need to call in someone else to deal with the issue, this is the right choice.

If it’s a smaller problem, you most likely just need to undo a specific update.

This individual rollback will work for themes and plugins. Do not use these instructions to roll back the core. If you’ve determined that you need to roll back the core, just restore from backup.

  1. Find the backup version of the plugin. Backups should use the same file hierarchy as the WordPress install, so you’re looking for backup/wp-content/plugins/plugin-name-folder.
  2. Use your SFTP or FTP login to replace the new version of the plugin folder with the backup version.
  3. Head back to the admin area and activate the plugin. WordPress doesn’t just run any code that’s dropped willy nilly in its filesystem, so you’ll have to go activate it.
  4. Empty your browser cache. You might be able to see the change without this, but I recommend flushing your cache whenever you make changes over FTP, because it gets in the way so often.
  5. Check to see if the issue is fixed.
  6. If not, you’ll want to restore from backup, then run each update individually until you discover which one (or more) is causing the issue.

Fixing the issue is going to be somewhat unique to the situation, but most issues stem from extensions coming into conflict with each other or with your site’s custom code. Sometimes this can be fixed by tweaking some settings or fiddling with your site’s CSS or whatever. If that doesn’t cut it, you can either wait for the issue to be patched or find another plugin that does the same thing and doesn’t break stuff. Failing that, you’ll want someone who speaks PHP, preferably the WordPress dialect.

Okay, then you’re done, right? No! There’s one more step.

  1. Alert the maintainer! They can’t fix it if they don’t know it’s broken!

You can contact the maintainer from the Plugins page.

On each listed plugin, there’s a version number, an author, and then a “view details” or “visit plugin site” link. From there, you should be able to navigate to a contact method for the maintainer.

If it’s a free plugin, you can contact the maintainer from the plugin’s repository page on Paid plugins and themes usually have a website where you can get customer support.

As a rule of thumb, if customer support for a paid extension isn’t obvious and available, you should not purchase it. I’ve never heard of a plugin or theme that works perfectly 100% of the time. If the developer isn’t willing to deal with the inevitable issues that arise, you do not want to work with them.

By the way, a lot of ticketing for free and paid plugins happens in forum format. This can be a real time saver if someone else has already run into your issue. Some plugins are also on GitHub and accept issues as well.

General Troubleshooting Tips

Okay, now some general troubleshooting tips.

When in doubt, run updates. It might not fix the problem, but it’ll remove confounding factors.

The White Screen of Death is when you try to hit your site and all you get is a white blank screen, usually with no way to log in. Sometimes the front of the site is fine, but wp-admin is blank. This generally happens on live sites that have PHP error printing turned off. If the error printing was turned on, the entire internet would be able to see exactly what went wrong, and where.

It’s got a pretty simple solution. If you get the Screen right after updates, roll the plugins and themes back until it unblanks. If you get the Screen right after activating something, delete its folder off the server or just rename it to deactivate it.

If you can read PHP error messages, you can go into wp-config.php and turn them on by setting define(‘WP_DEBUG’, false); to true. It’ll be most of the way down the file, past the salts. Make sure to set it back to false after you’re done debugging! This can be helpful if you’re not sure which plugin caused the issue.

Even if you know PHP, the answer probably isn’t to go comb through the plugin code. It’s usually complicated and undocumented with nonsensical comments. Even if there is something in there I can change and fix, it’ll get overwritten the next time I take an update. It’s Sisyphean and not worth the time.

When troubleshooting for users, always start by having them flush their browser cache. This has saved me enumerable headaches. is a resource that lists how to clear the cache of every browser version on every os and device. It’s great, I send this link to my clients all the time. Sometimes I use it myself if I’m testing browser compatibility on some OS and browser I don’t use often and I need to clear the cache.

Public Service Announcements

I’m now going to take advantage of this soapbox to make some Public Service Announcements, which is a mix of questions I get asked a lot and questions I wish people would ask me a lot. > vs

Alright so vs is a hosted service that happens to use the WordPress software. It’s run by Automattic, who is a major contributor to WordPress core, and is a bit of a benevolent overlord in the WordPress community. is where you go to download the software, read the documentation, get free plugins and themes, and so on. If you have FTP access to your site, you’re on the side of things, where I live. If you have to pay $3 a month to have a domain that doesn’t end in, you’re on the hosted service.

I might sound like I’m dissing, but honestly, it’s got its uses. It’s a great place to point folks that just want to start writing a blog right away without messing around with the setup. If your friends or relatives ask you to play webmaster but they’re too cheap to pay you, is a great place to send them. Once they’re ready for a real setup, their content can be imported into a installation with no problems.

Web Designer != Web Developer

Web designer is not equal to web developer. Not everyone seems to get this, which I find odd. Designers figure out how to express personality and ethos through color and font choices, which is basically wizardry. And then, if they’re good, they create images that are representative of informative, intuitive interfaces, which is like, wizard science. Developers take those images and breathe life into them, and adapt them to the functions the website needs. They’re two completely different skill sets. Three, if we’re counting UI as a separate discipline, which I do.

Generally speaking, if you’re contracting outside your org to put together a customized WordPress site, you need both a designer and a developer. This might be personal bias speaking here, but I think you’re better off with a developer if you can only hire one person. You can purchase a decent premade theme from a designer and then have a developer personalize it for you. That’s the cheapest way to get a site that doesn’t look like you bought it off the rack, so to speak.

If you only hire a designer, and something goes wrong with your site down the line, and it turns out that they don’t touch code or code badly…you’re going to have to try to fix it yourself.

Envato is Evil

Envato is Evil. Envato is a marketplace for digital content. They’ve given each of their sections a cutesy name; the ones I run into most are Theme Forest and Code Canyon, which sell themes and plugins respectively. This is fine. The problem is that Envato takes something like 60% of the profits and makes you sign a contract saying that you can’t sell your goods anywhere else. So most of the suppliers can’t make ends meet. That means there’s a high turnover rate in folks that sell through Envato. Which in turn means that a plugin or theme that you buy through Envato is going to stop being supported in six months, if it hasn’t already been abandoned and not taken down yet. Which means sooner or later, your site will break and you’ll have to switch out that plugin for something else. Envato is Evil. Avoid them.

Let polite robots find you

Let polite robots find you. This is most likely going to be an issue if you’ve just installed WordPress or if your dev was…forgetful. There’s a setting in the WordPress admin area, under Settings>Reading, called Search Engine Visibility. It starts off checked, and means that search engine crawlers will ignore your site. This is nice because it means you can finish making sure everything is ready before you get traffic directed to your site. But once you’re ready, you need to uncheck it, or no one will be able to find you.

Don’t touch the database

Don’t touch the database. This PSA is especially for you folks. WordPress is designed for non-tech users, and as such, works best when you don’t manipulate the database directly. Leave it alone! Let it do its thing! You can export the tables or whatever if you want to, but don’t change the data- it’s a good way to bork your site.

One Click Installs Bloatware

There’s a “One Click Install” option on hosts that don’t specialize in WordPress. You can use it if you want; just be aware that it won’t just install WordPress. Usually it’ll also include a plugin that wants to sell you stuff, like themes or whatever. That might be the end of it, but I’m always suspicious that there’s other stuff going on that I can’t see and don’t want going on.

Really though, setting up a WordPress install is easy…if you’re comfortable with FTP and creating MySQL databases and can follow a set of directions, so it’s not worth the hassle as far as I’m concerned. Directions for installing WordPress.

Extra Security Step: Disable the Theme and Plugin Editors

If you can’t convince your users to use strong passwords or you’re worried about someone messing with things they shouldn’t, this is a good idea. If you’ve got high enough permissions, you can edit any theme or plugin files on your server directly from the WordPress admin area, no FTP required. Turn them off in the wp-config file by adding the following line of code:

define( 'DISALLOW_FILE_EDIT', true );

I am available for hire

I do projects, consulting, staff training, all sorts of stuff.

Question Time

Okay, now, tell me your troubles, ask me your questions!

Thank You!

Thank you all for coming! If you need my slides or the updated written version of this tutorial, it’ll be up on my site by the end of the conference. I’ll be around for the rest of the week if you wanna chat. You can also email me for a fast response or tweet at me for a slow response.