WordPress Maintenance

When people talk about backup strategy, the “3-2-1 rule” comes up often: three copies of your data, on two different types of media, with one copy stored offsite. It’s a catchy sequence of numbers, but few people stop to unpack what each digit is actually protecting against. This post breaks down where the rule comes from and how it maps onto a real backup implementation. Note: The 3-2-1 rule is widely attributed to photographer Peter Krogh. It isn’t a formal standard set by any single organization — it’s a rule of thumb that spread through practical experience. What each number protects The rule bundles three separate conditions: Number What it …

WordPress site maintenance constantly involves one basic question: after an update, is the site still working? Instead of relying on a human eyeballing a page and deciding “looks fine,” most tooling answers that question mechanically, using the three-digit HTTP status code a web server returns for every request. That single number carries more information than it looks like at first glance. Note: An HTTP status code is a three-digit number a web server always attaches to its response to a client (a browser or a program). It comes paired with a short phrase describing what it means, like 200 OK. The leading digit sets the broad category The hundreds digit …

A WordPress URL like https://example.com/blog/some-post-title/ looks clean, but there’s no directory or file on the server that actually matches that path. Behind the scenes, Apache’s mod_rewrite module intercepts the request and silently forwards it to index.php. The rules that make this happen live in .htaccess, and when a WordPress site suddenly starts throwing 404s or 500s for no obvious reason, the cause is very often a misread rule in that file. Note: .htaccess is a configuration file Apache reads on a per-directory basis. On shared hosting environments where you can’t edit the server’s global configuration directly, dropping this file into a directory is often the only way to change how …

Ask most people where WordPress settings live, and they’ll point to the admin dashboard’s Settings menu. But a specific category of settings — the ones that determine how the site starts up in the first place — don’t live there at all. They’re written directly into a PHP file called wp-config.php, using define(). There’s a reason for that split. Dashboard settings are stored in the database (the wp_options table) and get read only after WordPress itself has finished booting. wp-config.php, on the other hand — which also holds the database connection details — is read before WordPress boots. So anything that shapes the boot-time conditions themselves — where the database …

Parts of WordPress that look like they’re reading straight from the database are often actually going through an HTTP API behind the scenes. Loading a post list dynamically with JavaScript, or having an external PHP script pull “just the titles and excerpts of the latest three posts” — both of these can be done without touching SQL directly, by calling the REST API that ships with WordPress itself. Understanding this means that whenever you need one system to peek into another WordPress site’s content, you don’t have to install a plugin or scrape the admin screen to do it. Note: REST (Representational State Transfer) is an API design style where …

“What does */5 * * * * actually mean?” — anyone setting up a scheduled task on a server has probably stared at that row of asterisks at some point. If you run WordPress, you may already be familiar with inspecting WP-Cron’s internals through WP-CLI, but the actual crontab syntax used by the OS itself is something many people never learn properly. Before you can switch WP-Cron over to a real OS-level cron job, you need to understand that syntax first. Note: crontab is a scheduling mechanism built into Unix-like systems (Linux, macOS, etc.). The name is short for “cron table” — a configuration file, and the command used to …

If you maintain WordPress sites across more than a couple of servers, you’ve probably typed a command like ssh -i ~/.ssh/xxx_key.pem -p 2222 user@203.0.113.10 more times than you’d like. Remembering the right key path, port number, and username for each server isn’t realistic, and copying a similar-looking command from shell history is exactly how you end up connecting to the wrong box. ~/.ssh/config solves this by letting you collect per-host settings in one file. Note: ~/.ssh/config is a file read by the OpenSSH client — it’s not a server-side setting. It lives on your local machine (Mac/Linux/Windows SSH client) and teaches it how to reach each server, typically with just …

If you maintain WordPress sites over SSH — running wp-cli remotely, checking logs, transferring files with rsync — you’re relying on SSH key authentication as the foundation. What rarely gets explained clearly is what you’re actually choosing when ssh-keygen -t asks for an algorithm. This post walks through what RSA, ECDSA, and ED25519 actually rest on mathematically, and which one makes sense to pick today. Note: SSH key authentication uses public-key cryptography. You keep a private key on your machine (never shared) and place a public key on the server (safe to share). The server issues a challenge that only the matching private key can answer, so you prove who …

WordPress ships with a built-in way to store data temporarily — save something for a fixed window of time, and it stops being valid once that window closes. This is the transient API, and both WordPress core and countless plugins lean on it to cache things like external API responses or the results of expensive calculations. It’s a genuinely useful mechanism, but used without understanding how it actually behaves, expired entries can pile up and quietly bloat the database. Note: the transient API is WordPress core’s name for a small set of PHP functions — set_transient(), get_transient(), delete_transient() — built around the idea of a cache entry with an expiration. …

A WordPress database doesn’t tidy itself up over time. Spam comments pile up, expired transients linger, post revisions accumulate, and tables left behind by uninstalled plugins never quite go away. All of that adds up to bloated tables, and occasionally to actual table corruption. This is territory the admin dashboard barely shows you — but WP-CLI reaches it directly with two short commands: wp db check and wp db optimize. Note: WP-CLI’s wp db subcommands operate directly on the MySQL (or MariaDB) database WordPress uses, without going through the admin dashboard. Connection details are read automatically from wp-config.php. wp db check — verifying table health wp db check Under the …