DEV Community: Susumu Takahashi

How WordPress Revisions, Autosaves and Auto-Drafts Work — and How to Manage the History in Your Database

Susumu Takahashi — Tue, 10 Nov 2026 23:46:14 +0000

When you edit a post in WordPress and click "Update", a "Revisions" item appears in the sidebar, letting you compare earlier versions and restore one. It is a useful safety net against accidental overwrites. At the same time, maintenance advice often warns that revisions pile up in the database and should be capped.

Where exactly are revisions stored, and in what form? How do they differ from autosaves and auto-drafts? As promised at the end of the previous article on autoload options, this post answers those questions using read-only queries against this blog's own WordPress database (7.1 series) and the core source code.

Revisions live in the same table as your posts

Revisions have no table of their own. They are stored in wp_posts, as rows whose post_type is revision. Grouping this blog's wp_posts by type and status (with SELECT only; nothing was changed):

post_type	post_status	Rows	Total content bytes
`post`	`publish`	126	1,144,680
`revision`	`inherit`	42	396,549
`page`	`draft`	1	6,788

A revision always has post_status = inherit, its parent's ID in post_parent, and a post_name like 7-revision-v1. Note the byte count: 42 revisions hold about 390 KB of content. A revision is a full copy of the content, not a diff. The single post with four revisions (ID 7) accounts for about 64 KB by itself.

When revisions are created

In wp-includes/default-filters.php, revision creation is attached to post-saving hooks (see WordPress action and filter hooks explained):

add_action( 'wp_after_insert_post', 'wp_save_post_revision_on_insert', 9, 3 );
add_action( 'post_updated', 'wp_save_post_revision', 10, 1 );

wp_save_post_revision_on_insert() returns immediately when $update is false, so a revision is created only when an existing post is updated. wp_save_post_revision() also does nothing during an autosave, for post types without revision support, for auto-draft posts, when revisions are disabled, or when the title, content and excerpt are unchanged from the latest revision (compared after whitespace normalization). Clicking "Update" without changing anything adds no revision.

Measured: only updated posts have revisions

This blog publishes with wp post create from WP-CLI rather than the editor. Creation is not an update, so no revision is made at publish time. Revisions appear only when a post is later changed with wp post update, for example to add internal links. The numbers match exactly:

Measurement	Count
Posts	126
Posts whose `post_modified` differs from `post_date`	31
Posts with at least one revision	31
Total revisions	42

The 95 posts that were never updated have no revisions at all.

A revision records the state after saving

Comparing each post's revisions with its current content, the newest revision matched the current content for all 31 posts, while the oldest revision of every post with two or more revisions did not. As a core comment puts it, the most recent revision always matches the current post. A revision is a snapshot of the version after the save, not before it.

That leads to a less obvious consequence. For the 23 posts with exactly one revision, that revision equals the current content. So where is the original, pre-update version? Nowhere. With the editor, opening "Add New" creates a placeholder row and clicking "Publish" counts as an update, so the published version is kept. A post created directly in the published state (via WP-CLI, an import or an external tool) has no revision of its first version, and after one update only the updated version remains.

This is by design, not a bug, but it means revisions do not guarantee you can return to the original, and they are not a substitute for backups (see the 3-2-1 backup rule).

Autosaves and auto-drafts

While you write, WordPress autosaves every AUTOSAVE_INTERVAL seconds (default 60, also 60 here). For a draft being edited by its author, the autosave overwrites the post row itself. For a published post, it goes into a separate row named like 7-autosave-v1, so unsaved edits never leak onto the live page. There is one autosave row per user, overwritten each time, and because wp_save_post_revision() skips autosaves, autosaving does not add regular revisions. This blog has zero autosave rows; all 42 are -revision-v1.

An auto-draft is the placeholder row created as soon as someone opens "Add New", so media can be attached before the first save. A daily WP-Cron event, wp_scheduled_auto_draft_delete, runs wp_delete_auto_drafts(), which force-deletes auto-drafts older than seven days. If WP-Cron is not running, that cleanup does not happen either (see crontab syntax basics vs WP-Cron). Similarly, wp_scheduled_delete empties trashed posts after EMPTY_TRASH_DAYS (default 30).

Type	What it is	Growth	Automatic cleanup
Revision	Full snapshot per update	One per changed update	Only if a limit is set
Autosave	In-progress edits	One per user, overwritten	Not needed
Auto-draft	Placeholder for "Add New"	One per screen opened	WP-Cron after 7 days
Trash	Deleted posts	One per deletion	WP-Cron after 30 days

With default settings, revisions are the only one that grows without limit.

Limiting revisions with `WP_POST_REVISIONS`

wp_revisions_to_keep() reads the WP_POST_REVISIONS constant (see key wp-config.php constants): true (the default) means unlimited and becomes -1, a positive integer keeps that many per post, and false or 0 disables revisions. This blog leaves it undefined, so it returns -1. The wp_revisions_to_keep and wp_{post_type}_revisions_to_keep filters can override the constant, so a plugin may make your setting appear to have no effect.

The important detail is when the limit is enforced. In wp_save_post_revision(), old revisions are trimmed only right after a new revision is saved, and only for that post. Setting the limit to 5 does not touch a post that already has 20 revisions until that post is updated again. A limit controls future growth; it does not clean up existing history.

Disabling revisions entirely saves space but removes the only per-post undo. Restoring from a backup works at the site or database level, which is a poor fit for "I want yesterday afternoon's version of this one post." A modest cap is usually easier to live with than turning revisions off.

Checking and cleaning up

Everything can be checked read-only:

wp post list --post_type=revision --format=count
wp eval 'var_dump( defined( "WP_POST_REVISIONS" ) ? WP_POST_REVISIONS : "undefined" );'

Look at the total count and size compared with your posts, which posts hold the most revisions, and whether the limit is unlimited or filtered. If you decide to clean up:

Back up first. Deleted revisions cannot be recovered.
Set a limit first, or the history will simply build up again.
Delete through WordPress (wp_delete_post_revision() or wp post delete), never with a raw SQL DELETE, which can leave orphaned metadata behind.
Verify that key posts and the revisions screen still work.

Deleting rows often does not shrink the database file right away; reclaiming that space is what wp db optimize is for (see wp db check and wp db optimize).

Do revisions slow down the front end?

Mostly no. Front-end queries filter on post_type and post_status, and the composite type_status_date index excludes revision rows before they are read (see database index basics). Unlike autoloaded options, revisions are not read on every request. Their cost shows up in maintenance work: larger backups and migrations, a sluggish revisions screen when a post has hundreds of them, full-table operations such as search-and-replace, and database size limits on shared hosting.

Summary

Revisions are full copies stored in wp_posts, created only when an existing post is updated and its content changes, and each one captures the version after the save. On this blog, only the 31 posts updated after publishing have revisions, and posts created with WP-CLI kept no record of their first version. Autosaves overwrite one row per user, while auto-drafts and trash are cleaned up by WP-Cron. Revisions are the one thing that grows without limit by default, and WP_POST_REVISIONS only applies on the next update, so clean up in order: back up, set a limit, delete through WordPress, then verify.

Forgotten files in your public directory: how to find them on your own site, and where to keep them instead

Susumu Takahashi — Tue, 10 Nov 2026 00:04:09 +0000

When people think of data leaks, they often picture a sophisticated outside attack. In practice, one common entry point is much plainer: a file you placed in a public directory and then forgot. A backup made mid-task, a database dump, a copy of a configuration file. If someone knows the URL, a browser is all it takes. This article explains why it happens, how to check your own site calmly, and the placement principle that prevents it: do not keep these files in a public location at all.

Why forgotten files happen

On shared hosting, anything under the public directory (public_html or similar) is generally reachable by URL. Whatever you put there is treated the same as something you intentionally published.

Forgotten files are usually born during harmless work:

You made an archive before an update or migration, "just in case," in the same folder
You exported the database and used the public folder as a temporary spot before downloading it
You saved a copy of a configuration file under another name before editing
You left a test page or scratch file behind after verifying something

All of these are made with the intention of deleting them later. The trouble is that nothing warns you when you forget. The site keeps working normally, so there is no moment that prompts you to notice.

What can be exposed

The impact depends heavily on what the file contains.

Database dumps: posts, user records, and form submissions in one place. Passwords are usually stored in a transformed (hashed) form, but email addresses, names, and other content are often readable as-is
Whole-site archives: if they include the configuration file, database connection details and authentication keys come along
Renamed copies of configuration files: the real configuration file runs as PHP, so its contents are not displayed. A copy with a changed extension, however, may be served as plain text. This is the easy one to miss
Log and debug files: internal paths and error details (covered in a separate article)

The third point is the common blind spot. "The configuration file is PHP, so nobody can read it" stops being true for a renamed copy.

How to check your own site

This check is something you do calmly, on your own server and your own site.

1. List files by extension

If you have SSH access, look under the public directory for extensions commonly used for backups and exports.

cd ~/example.com/public_html
find . -type f \( -name "*.sql" -o -name "*.zip" -o -name "*.tar.gz" -o -name "*.bak" -o -name "*.old" -o -name "*.orig" -o -name "*~" \) -ls

Without SSH, simply browsing the same folder in an SFTP client helps. Old files you do not remember creating are candidates.

2. Confirm whether it is actually reachable

A file existing and a file being retrievable from outside are different things. For anything suspicious, request its URL with your browser or curl and look at the response.

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/path-to-the-file

A 200 means it can be fetched from outside. A 403 or 404 means at least that URL does not serve it, but server configuration can differ by route, so do not treat "it did not load" as permission to leave the file in place.

3. Check search engines too

Run a site: search restricted to your own domain and look for file types you did not expect to see. If something appears, it was already discoverable.

What to do if you find one

First, delete it or move it outside the public directory. Then:

Check what it contained: for a dump or a configuration copy, work out which information was in it
Replace credentials if they were included: if database passwords or the authentication keys (salts) in wp-config.php were inside, deleting the file is not enough. Allow for the possibility that it was retrievable for some period, and issue new values
Review access logs: see whether the access log shows requests for that file. If so, it may have been fetched. If there is no trace, that still does not prove it was not
If personal information was involved: depending on scope, legal obligations may apply (to be covered in a separate article)

Establishing what was exposed, since when, and whether it was reachable step by step tends to lead to better decisions than rushing to change many things at once.

Placement principles: do not keep it in public space at all

A one-time check is less durable than habits that make forgetting less likely.

Keep working files outside the public directory: use a location that no URL maps to, such as directly under your home directory
Store backups apart from the site: not inside the public area of the same server. Decide who can read the storage location
Do not keep copies under alternate names: saving wp-config.php.bak next to the original invites trouble. Use version control or a non-public location
Add a cleanup confirmation to every task: put a single line in your update or migration steps, "working files removed"
Audit regularly: running the check above during a monthly maintenance pass reduces what lingers

Server configuration can also deny certain extensions. That is an additional layer against forgotten files, not a replacement for not leaving them there. A configuration mistake or an environment change can quietly stop it from working.

Summary

Anything under the public directory is generally retrievable by URL, so a forgotten working file can become an entry point for a leak
Database dumps, whole-site archives, and renamed copies of configuration files have the largest impact
Check your own site by extension, by actual response, and via search engines
If you find one, delete or relocate it, replace any credentials it held, and review the access logs
Long term, make these habits: keep files out of public space, confirm cleanup at the end of each task, and audit regularly

Maintenance work tends to create files. Treat clearing them away as part of the same task.

WAF and rate limiting basics: what they can and cannot stop, and why they buy time rather than replace updates

Susumu Takahashi — Sun, 08 Nov 2026 23:56:30 +0000

You may have seen advice like "just install a WAF and you are fine." But a WAF (Web Application Firewall) and rate limiting are filters that sit in front of your site. They do not repair the weakness inside it. This article explains what each one does, what it is good and bad at, and what is easy to miss after you turn it on. We then place both in the right role for vulnerabilities: a way to buy time until you can update. Features differ greatly by product and contract, so this stays at the level of general principles.

What a WAF is: a reception desk in front of the site

A WAF inspects the contents of each incoming request and decides whether to let it through or stop it. Think of a reception desk at the entrance of your site.

It can live in several places:

Cloud-based (in front of a CDN or similar): filters requests before they reach your site, running on the provider's network
Server-side feature: some hosting providers offer one. Whether it is on depends on your plan and control panel settings
Plugin-based: runs inside WordPress. Because it decides after PHP has started, it sits further inside than the two above

Where it sits changes what it can see and what it can stop. It is worth finding out which one, if any, is running on your site.

What rate limiting is: drawing a line by count

Rate limiting looks at how often, not what. It decides based on how many requests one source has made in a given time.

Typical uses are repeated attempts against the login page (wp-login.php) and bursts of traffic meant to overload a site. Even if each password attempt looks legitimate, an unnatural count can be stopped.

A WAF (what is in the request) and rate limiting (how many requests) are different viewpoints. Some products bundle both.

What they are good at

Blocking clearly suspicious requests that match well-known patterns: familiar shapes of request can be stopped at the desk
Slowing repeated login attempts: a count-based line reduces the payoff of mechanical guessing
Reducing noise in access logs: if routine probing stops at the entrance, logs become easier to read. See how to read WordPress access logs
Sometimes creating a grace period: right after a vulnerability is disclosed, a provider may ship a rule that blocks its abuse (often called "virtual patching"). Whether a rule exists and when it arrives varies by product and vulnerability, and none of it is guaranteed

What they are weak at

Filtering at the entrance has trouble with the following:

Requests that look legitimate: a well-formed request that appears to be an authorized action may be indistinguishable by content alone. Weaknesses in the site's own design fall in this group
Real logins with stolen credentials: with a genuine username and password, the person looks like an ordinary user
Updates from a compromised distribution source: things that arrive through a channel you trust are rarely suspected. This is one of the types covered in our supply chain article
Anything already placed inside the site: entrance protection does not act on what happened after entry. If you suspect that, follow the order in the first-response article
Paths that bypass the WAF: with a cloud WAF, an open direct path to the origin server may let requests skip the desk. Check that "the WAF is in front" is actually true of your setup

Common stumbling blocks after turning it on

The stronger the protection, the more likely it is to stop legitimate users too.

False positives: saving in the editor, REST API calls, image uploads, and notifications from payment or external services can be flagged. A sudden site malfunction turning out to be the WAF is not unusual
Collateral stops on shared sources: traffic from one office or facility network can look like a single source from outside. A strict rate limit may stop several legitimate users together
Misjudged client address: behind a CDN or proxy, the address your site sees may be the relay, not the actual visitor. If the count is attached to the wrong address, the limit may not work or may hit everyone at once. It needs settings that match your architecture
Starting in "log only" mode: many products can record without blocking. Looking at what gets flagged before enforcing makes false positives easier to notice

How to check that it behaves as intended

After configuring, confirm it works as expected. These are read-only checks:

In the access logs, watch the number of stopped responses (such as 403 or 429) before and after the change. HTTP status meanings are covered in our HTTP status codes article
Try normal admin work: saving a post, uploading an image, changing a plugin setting
Make sure blocked requests are recorded, so you can review them later

Testing your own site with attack-like traffic can violate your provider's terms or affect other customers. Staying within logs and ordinary operations is the safer course.

The relationship to updates: time bought, not a substitute

A WAF and rate limiting do not remove the weakness. As long as it remains, requests that slip past the desk may still work. There are periods when rules lag behind, and weaknesses that no rule covers.

So the roles can be summarized like this:

Updates (patches): remove the weakness. This is the thing to do
WAF and rate limiting: an additional layer that may reduce harm in the meantime

For thinking about update timing, see our article on time to exploitation; for trimming unused plugins, see the plugin inventory article. Adding layers and keeping up with updates go together.

Limits and things to keep in mind

Features, rule content, and update frequency differ widely by provider and contract. Having one installed is different from your site being protected
Weaknesses that rules do not cover, and cases where legitimate traffic is stopped, never fully disappear
A small number of blocked requests does not prove that no attacks are arriving

Summary

A WAF looks at content and rate limiting looks at count, deciding in front of the site what to pass and what to stop
They help with known suspicious requests and repeated login attempts, but are weak against legitimate-looking requests, stolen credentials, compromised distribution sources, and anything already inside
After enabling, watch for false positives and misjudged client addresses, and consider starting in log-only mode
The role is an additional layer that can buy time until you update. It is not a replacement for updating

No single layer stands alone. Think of protection as combining updates, inventory, permissions, and backups.

A checklist for shrinking your WordPress attack surface: admins, file editing, permissions, wp-config.php, and uploads

Susumu Takahashi — Thu, 05 Nov 2026 23:56:08 +0000

Applying updates and checking for compromise are both essential, but there is a step before them: reducing how many ways in there are. This article lists five things to review to shrink a WordPress site's attack surface: administrator accounts, file editing from the dashboard, file permissions, how wp-config.php is handled, and PHP execution under uploads. It pulls together earlier articles in this blog. None of these settings makes a site "secure". They lower how easily things go wrong and how far damage can spread.

What an attack surface is

The attack surface is the total set of entry points and capabilities that can be reached from outside, or from inside once someone is in. The more there are, the more likely something is overlooked. Closing what you do not use makes the day an update arrives late less costly.

Narrowing the surface reduces the impact when a vulnerability is found; it does not remove the vulnerability. Updates and checks remain the main defense. The items below are supporting layers.

Review	What it narrows	Related article
1. Administrator accounts	How much power a stolen account holds	Compromise checks
2. File editing in the dashboard	A route for rewriting code after an admin login	wp-config.php constants
3. File permissions	What other users and processes on the server can see	Permissions and least privilege
4. wp-config.php	Exposure of a file holding credentials	wp-config.php constants
5. Code execution in uploads	Whether an uploaded PHP file can run	This article

1. Keep fewer administrators

An administrator can install plugins, create users, and change settings. So the number of admin accounts is also the number of places where a takeover has full impact.

Limit administrators to people who manage the site now. Remove or downgrade accounts of former staff and finished contracts
Someone who only writes posts usually needs the Author or Editor role. Give the smallest role that covers the job
Shared accounts hide who did what. Use individual accounts where you can
Confirm the admin email address still receives mail, since it is part of the password-reset path

A read-only listing:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

The test is whether you can explain, for every account, who it is and why it is an administrator. If one is unexplained, record it and investigate before deleting anything.

2. Turn off file editing in the dashboard

The WordPress dashboard can edit theme and plugin files in place. That is convenient, but it is also a route to rewrite server-side code for anyone who gets past the admin login.

Adding this constant to wp-config.php disables that editor:

define( 'DISALLOW_FILE_EDIT', true );

As covered in the wp-config.php constants article, this has few side effects if you do not edit code in the dashboard. A separate constant, DISALLOW_FILE_MODS, also blocks installing and updating plugins and themes. Check it against your maintenance routine first, because stopping updates would defeat the purpose.

3. Use the smallest file permissions that work

On Unix-like servers each file has read, write, and execute permissions for owner, group, and others. As the permissions article explains, the principle is the needed operations, for the needed parties, and nothing more.

Avoid world-writable permissions such as 777 unless there is a specific reason
Common starting points are 644 for files and 755 for directories, but the right values depend on how PHP runs and who owns the files. Follow your host's guidance
Record the current state before changing anything, so you can revert if something stops working

Checking is read-only:

find . -type f -perm -o+w -not -path "./wp-content/cache/*" | head -20

This lists files writable by "others". Do not fix results mechanically; first work out why each one is that way.

4. Protect wp-config.php

wp-config.php holds the database credentials and the keys (salts) used by the login system. It is one of the files you least want read by others.

Consider placing it outside the web root. WordPress can load it from one directory above the install. If your server layout allows it, that keeps it out of the public area. Take a backup first, since some setups break
Tighten permissions along the lines above, so other users cannot read it. 600 or 640 are common candidates, but some PHP setups need different values, so test after changing
Do not leave copies such as wp-config.php.bak or .old in a public directory. They are often less protected than the original
Rotate the salts when you review admins. Changing them invalidates existing login sessions

wp config shuffle-salts

Everyone is logged out afterwards, so pick the timing with care.

5. Do not let PHP run under uploads

wp-content/uploads/ stores media and is not meant to hold PHP code. If a PHP file lands there and can execute, a flaw in an upload path becomes far more serious.

The principle is simple: places for data should not execute code. How you do it depends on the server.

On Apache, a .htaccess file in the uploads directory can deny PHP execution (Apache 2.4 example):

<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

On Nginx, configure the server so .php files under uploads are not passed to PHP
On shared hosting, whether .htaccess is honored, and how, may depend on the control panel. Check your plan's documentation

After any change, confirm that ordinary media such as images still display. Some plugins also keep their own PHP under uploads, so check that a deny rule will not break them.

To look for what may already be there, use the read-only commands in the compromise checks article.

Limits to keep in mind

None of these fixes a vulnerability. They buy time when an update is late, but do not replace updating
Settings can change behavior. Make one change at a time, after a backup, and record the state before and after
Hosting differences are large. The values here are general guidelines and need checking in your environment
This is not one-and-done. Staff changes and new plugins gradually widen the surface again, so review it regularly

Summary

Narrowing the attack surface is a layer that limits damage on the day a vulnerability appears. It does not replace updates and checks
Five items: number of admins, dashboard file editing, file permissions, wp-config.php, PHP execution in uploads
Record the current state before each change and confirm behavior afterwards
Values vary by environment. When unsure, rely on your host's guidance or a specialist

One thing to do today: run wp user list --role=administrator and check whether any account is no longer in use.

What to do first when a WordPress site may be compromised: isolate, preserve, restore, rotate credentials

Susumu Takahashi — Thu, 05 Nov 2026 00:21:55 +0000

The moment you suspect a site has been tampered with is when it is easiest to act in a hurry. But the wrong order can erase the clues you need, or let the same visitor back in through the same door. This article lays out a first response for a suspected WordPress compromise in this order: isolate, preserve evidence, restore from a clean backup, rotate credentials. It does not cover attack techniques; it focuses on a calm way to proceed. The best steps depend on your environment, so please treat this as a starting point and involve your hosting provider or a specialist when unsure.

First, do not rush to delete

When you find a suspicious file, the urge is to delete it immediately. That is natural, but record what happened before you remove anything. Once files are gone, you may no longer be able to tell when or how someone got in, and the same gap may remain after recovery.

Also, finding and removing one item does not mean you are done. What you found may be only part of it. So think in this order: limit the damage, keep a record, return to a clean state, close the door again.

1. Isolate: stop the damage from spreading

The first goal is to keep the problem from reaching visitors or other sites.

Take the site offline temporarily: show a maintenance page or restrict access, following your server panel or provider's guidance
If other sites share the same server or account, check them too. A compromise on one can reach the others
Contact your provider: on shared hosting, they can sometimes share what they can see, such as logs or blocking status

At this stage, do not delete or overwrite files yet.

2. Preserve evidence: keep it before you change it

To investigate and prevent a repeat, save the current state as it is.

Copy the whole site: download files and the database before any changes and keep them elsewhere, separate from your recovery backups
Collect access and error logs: logs are rotated away after a while, so fetch them early. See Reading access logs for how to read them
Write down how you noticed: what you saw and when. Screenshots help

You can check things in a read-only way. For example, WP-CLI can compare WordPress core files against official checksums:

wp core verify-checksums
wp user list --role=administrator

These commands look at the state without changing it. The reasoning is covered in Three checks to confirm a site has not been compromised. Note that a clean result is not proof that nothing happened. Treat each finding as one clue.

3. Restore from a clean backup

In general, returning to a backup known to predate the problem tends to leave fewer things behind than removing suspicious files by hand. Points to keep in mind:

Decide which backup generation is safe: if you do not know when it started, compare several. The newest backup may already contain the problem
Consider restoring into a fresh environment: restoring to a new location and verifying before switching over also keeps the original as evidence
Reinstall WordPress core, plugins and themes from official sources: update to current versions after restoring, and remove what you do not use
A backup is only useful if it can be restored: how to take a restorable database backup is covered in mysqldump and consistent backups. Avoid trying a restore for the first time during an incident

If you have no backup, or none you can trust, prioritize talking to your provider or a specialist over going it alone.

4. Rotate credentials: close the door again

Even after a clean restore, stolen credentials let the same person back in. After restoring, rotate what may have been involved.

WordPress administrator passwords: change them for every admin account. Investigate any admin account you do not recognize before deciding what to do
Database password: update wp-config.php to match
SSH keys, FTP/SFTP passwords, server panel password: renew anything that may have leaked, and disable old keys
Salts (authentication secret keys): wp config shuffle-salts regenerates the salts in wp-config.php. This invalidates every existing login session, so everyone must sign in again. Do it knowing that
API keys for external services stored on the site: reissue them at the provider

Rotate after returning to a clean environment. If you change them while the problem remains, the new credentials can be read as well.

5. Prevent a repeat, then decide when to reopen

After recovery, review what may have been the entry point: plugins that stopped receiving updates, forgotten admin accounts, unused plugins and themes, file permissions. The attack surface checklist can help.

Even after reopening, watch logs, admin accounts and file changes more closely than usual for a while. Base the timing on whether you have a lead on the cause and have closed the likely entry points.

Limits to be aware of

Even if you follow the steps, the cause may remain unknown. In that case you close likely entry points broadly
If the site handles personal data, you may need to notify affected parties or authorities depending on the situation. Talk to the person responsible in your organization or a specialist
Tools alone cannot determine whether or how far a compromise went. Finding nothing is not a guarantee of safety

Summary

Do not delete in a hurry. Go in order: isolate, preserve evidence, restore to a clean state, rotate credentials
Recovery depends on a backup you can actually restore, so routine backup verification shapes the quality of the first response
Rotate credentials after returning to a clean environment
When unsure, ask your provider or a specialist

Steps decided in the middle of an incident tend to go wrong. Writing your own version down while things are calm will help when it matters.

Reading access logs: scans that end in 404, and the 200 responses worth a second look

Susumu Takahashi — Wed, 04 Nov 2026 01:13:42 +0000

A public site receives requests every day from visitors that are just looking for something. Most of them ask for files that do not exist and end in a 404. Without a habit of reading the log, though, the one line that deserves attention is easy to miss among them. This article describes how to look at a WordPress access log in a read-only way, centered on separating routine probing from what to confirm. Reading logs does not make a site safe. It gives you more clues to notice things.

What an access log records

A web server records each request as a line. In the common "combined" format, a line looks roughly like this:

client - - [time] "METHOD path protocol" status bytes "referrer" "user-agent"

Note: The status is the HTTP response code. 200 means the server returned the content; 404 means nothing was found. See the HTTP status code article for more.

Where logs live and how you download them depends on your hosting provider, so check its documentation first. Also, old logs are rotated away after a while, so confirm that the period you want to inspect still exists.

Routine probing mostly ends in 404

The first time you read a public site's log, you may be surprised by how many requests are for paths you never created. Names that look like configuration backups, diagnostic pages that print environment details, or entry points of admin tools: these are mechanical guesses at "files that might exist" and are not necessarily aimed at your site.

Most of them end in 404 because the file does not exist. So the presence of probing in the log is not, by itself, abnormal. Two things are worth keeping apart:

Probing arrives: routine for a public site. No reason to panic on this alone
Probing gets a 200: the requested thing may exist and its content may have been returned. This is what to confirm

Look at the overall distribution first

Before reading single lines, count the statuses. This is a read-only command (access.log stands for a downloaded log file):

awk '{print $9}' access.log | sort | uniq -c | sort -rn

A typical shape is mostly 200, then 301/304, with a smaller share of 404, but it varies a lot by site. What matters is knowing your usual shape. A sudden rise in 404s or a visible share of 5xx is a reason to look closer.

Skim the paths that returned 404

Then list the 404 paths, most frequent first:

awk '$9==404 {print $7}' access.log | sort | uniq -c | sort -rn | head -30

What to look for:

Names that should not exist on your site at all are most likely routine probing. Just skim them
URLs that used to exist on your site near the top suggest broken links or a missed redirect, which is an operational improvement
Many requests to one path in a short time are worth noting from a server-load point of view

The thing not to miss: a suspicious path that returned 200

Here is the main point. The 404 list records probes that missed. Probes that hit are recorded as 200. Count PHP requests that returned 200:

awk '$9==200 && $7 ~ /\.php/ {print $7}' access.log | sed 's/?.*//' | sort | uniq -c | sort -rn | head -30

A normal WordPress site shows a limited set of PHP files (index.php, wp-login.php, wp-cron.php, xmlrpc.php, admin-ajax.php, and so on, depending on the setup). For any other PHP name returning 200, ask whether you can explain what that file is.

Two combinations deserve particular attention:

A PHP file under uploads returning 200: that directory is for images and similar files, so PHP running there is not what normal operation expects. Combine this with the "PHP in uploads" check from the compromise-check article and look at whether the file exists
A POST request to an unfamiliar PHP file returning 200: also worth confirming

awk '$6=="\"POST\"" && $9==200 {print $7}' access.log | sed 's/?.*//' | sort | uniq -c | sort -rn | head -30

Neither finding means a site has been compromised. A plugin may ship its own PHP, or you may have forgotten a diagnostic file you placed yourself. The order of confirmation is: what is the file, who placed it and when, and is its content what you expect. If you cannot tell, record the current state and preserve it before deleting anything.

Why a 200 alone is not enough

Reading logs has limits:

Some setups return 200 for pages that do not exist. Depending on the theme, plugins, or server settings, a missing path may return an error-looking page with a 200 (a soft 404). Then a 200 line is not necessarily a hit. Open the path and see what actually comes back
Behind a CDN or reverse proxy, the client address may be the provider's. You may not be able to tell who the requester was
Absence from the log does not mean it did not happen. Retention, recorded fields, and what you can download are limited. Do not read "not in the log" as "nothing occurred"
A log records; it does not protect. Reading alone defends nothing. It matters when it leads to updates, setting reviews, and checks

A minimal habit

You do not need to read everything daily. One sustainable shape:

At a regular interval such as weekly, count the status breakdown and compare it with your usual shape
List PHP files that returned 200 and that you do not recognize
For anything unclear, check whether the file exists, its modification time, and its content
Leave a short note of what you checked and decided, so you can explain it next time

As the log level and rotation article describes, a log is valuable when it stays available to review later. Decide retention and review frequency to fit your own operation.

Summary

Probing requests to a public site are routine. Most end in 404 and are not abnormal in themselves
What to confirm is whether something probed actually exists and returned 200, especially PHP under uploads and POSTs to unfamiliar PHP files
A 200 line only suggests a possible hit, and soft-404 setups exist. Decide by the file's existence and content
Logs are material for noticing, not evidence of safety. Use them together with updates, checks, and setting reviews

Reading the access log is a status check before acting. Shrinking entry points, as in the attack surface checklist, and checking how those entry points look in the log complement each other.

What is a supply chain attack? When "just update" is not enough

Susumu Takahashi — Tue, 03 Nov 2026 01:51:47 +0000

Applying updates is the basis of maintenance. But reports show that the update itself can be tampered with, including around WordPress. This article looks at how supply chain attacks work using public information, then sorts out how to balance "apply quickly" with "wait a little", and how to reduce the scripts your site loads from outside. The aim is calm planning, not alarm.

What a supply chain attack is

Instead of attacking your site directly, the attacker targets something your site already trusts. A WordPress site trusts several things:

What you trust	Examples
Update delivery	Update servers, the official directory, paid-plugin update channels
The vendor itself	Developer accounts, build systems, who owns the vendor
Files loaded from outside	JavaScript served from a CDN, third-party tags, font delivery

When an admin decides "there's an update, apply it" or "this script is well known, load it", that trust is turned against them. Unlike an ordinary vulnerability, the problem arrives as a result of applying the update.

Public cases (checked as of 2026-11-01)

These are listed to show different mechanisms, not to blame any product.

A CDN-served script changed (2024)

A domain that served a popular JavaScript library was acquired by another company in February 2024. Security firm Sansec reported on 2024-06-25 that scripts from that domain then included code that redirected visitors on certain devices to other sites. More than 100,000 sites were reported to embed it.

Source: Sansec, Polyfill supply chain attack

The key point: nothing changed in the site's own code. Only the content at the load location changed. Updating the site or its plugins would not have prevented it.

A vendor changed hands (2025–2026)

In an article dated 2026-04-15, Patchstack reported that a plugin vendor was sold in 2025 and that a malicious mechanism was introduced in the new owner's earliest changes. It reportedly stayed dormant for months and became active around April 2026. The WordPress.org plugin review team confirmed it on 2026-04-07 and closed the affected plugins in the directory.

Source: Patchstack, Critical supply chain compromise on 20+ plugins

The number of affected plugins varies within the same article ("20+" and "25+"), so we do not state a count. The point is that a change of owner alone can change what a plugin is.

An update channel was compromised (2026)

Several 2026 reports describe paid-plugin update channels being compromised so that official updates carried malicious code (for example, The Hacker News). Timing and scope differ between reports, so we do not go into detail. Check each security firm's advisory for primary information.

What the three cases show

An official channel or valid update does not guarantee safe contents
There can be a time gap between insertion and discovery (some stayed dormant for months)
Scanners look for known bad patterns, so something arriving through a legitimate channel is harder to spot

"Apply quickly" and "wait a little" together

An earlier article (wait before a major update) said to wait a little for feature-bearing updates. The previous one (hours, not weeks) said to apply security fixes early. Supply chain attacks add another angle.

Update type	Basic handling	What to add for supply chain risk
Security fix	Check and apply early	Glance at whether the vendor looks normal (sudden ownership change, odd releases)
Small routine update	Weekly batch	Back up first, check the screens afterward
Major update	Wait and verify	While waiting, see whether reports of problems or oddities appear

So the two rules fold into one idea: decide from the content of the update and the state of its source. Don't fix the number of days to wait; know why you are waiting (compatibility, or the source's condition).

What you can do

Know where each item comes from

# Installed plugins and their state
wp plugin list --fields=name,status,version,update

# Do core and plugin files match the official releases?
wp core verify-checksums
wp plugin verify-checksums --all

verify-checksums compares plugins registered on WordPress.org against official releases. Paid or self-distributed plugins are outside its coverage. Simply listing which ones cannot be checked is valuable.

Watch for changes at the vendor

Has the vendor or contact of a plugin you use suddenly changed (plugin page, changelog)?
Has a long-quiet plugin suddenly started releasing again?
Delete, don't just deactivate, plugins you don't use (inventory article)

Keep external scripts to a minimum

Loading an external script gives code outside your site the right to run inside it.

List the external domains you load now (browser dev tools network tab, or check <script src> in HTML fetched with curl)
Keep only what is needed. Drop things that are no longer necessary, such as compatibility shims for old browsers
For what remains, consider self-hosting. If the source changes hands, your local copy does not change
Adding integrity (a hash) to external scripts is another option, though you must update the hash when the content is legitimately updated

Stay able to roll back

Not everything can be prevented. Being able to return to the state before the problem is the last line of preparation. A backup is only maintenance if you can restore from it.

If something looks wrong

Don't pile on operations; record the situation (version, time, screens)
Check the vendor and security firms' advisories
If needed, put the site in maintenance mode so the impact doesn't spread
Recover from a clean backup as the baseline

If it seems fixed just by updating, a swapped-out component may not be visible from the surface. When in doubt, consult a specialist.

Summary

Supply chain attacks target what your site trusts. They can occur even if you update and even if you load external scripts
Public cases vary: CDN rewrites, vendor ownership changes, compromised update channels
"Apply quickly" and "wait a little" are one rule: decide from the update's content and the source's condition
Reduce external scripts and consider self-hosting what remains
Stay able to roll back. Maintenance includes being able to restore

One thing to do today: run wp plugin verify-checksums --all and list which plugins fall outside the check.

Three checks to see whether a site has been compromised: checksums, admin accounts, and PHP in uploads

Susumu Takahashi — Mon, 02 Nov 2026 00:28:31 +0000

Updates keep things out. But how do you check whether something is already in? This article walks through three checks you can run with WP-CLI: verifying core and plugin checksums, taking stock of administrator accounts, and looking for PHP files under uploads. We cover how to read each result and where it stops being useful. These checks are defensive routine work, and a clean result is not a guarantee of safety.

Why check for "already inside"

Applying updates and removing unused plugins only makes the site harder to get into from now on. A survey we looked at in the previous article on exploit timing suggests the window between disclosure and exploitation can be short, so we cannot rule out that something arrived before the update.

Maintenance therefore needs a second viewpoint: is the current state the same as the state it should be in? All three checks below are read-only. They do not change the site.

Check	What it confirms	Main command
① File match	Core and plugin files equal the published originals	`wp core verify-checksums` / `wp plugin verify-checksums`
② Accounts	No administrator you do not recognize	`wp user list --role=administrator`
③ Location	No PHP where code does not normally live	`find` over `uploads/`

① Compare files with the published checksums

As described in our hash and checksum basics article, changing even one character of a file changes its hash. WP-CLI applies this idea to WordPress.

wp core verify-checksums

The command downloads the MD5 checksum list for your installed version from WordPress.org and compares it with the files on disk. According to its documentation, it avoids loading WordPress while verifying, so tampered code is not executed during the check.

A clean run prints:

Success: WordPress installation verifies against checksums.

When something differs, you get a per-file warning, such as a checksum mismatch or a file that should not exist.

Points to keep in mind:

Locale and version: if verification misbehaves, pass --locale and --version to match the values on the Updates screen, since localized packages differ
Root directory: by default the check covers core files; add --include-root to also warn about unfamiliar items in the site root
Your own edits: if you edited a core file, a mismatch is expected. What matters is whether you can explain every mismatch

Plugins work the same way

wp plugin verify-checksums --all

This works for plugins distributed through the WordPress.org directory. The important part is not overlooking what could not be checked. Paid plugins and plugins distributed elsewhere have no published checksums, and the tool reports that it cannot verify them. That is not itself a problem, but it is a gap in your coverage and should be covered by other means, such as the vendor's change history or file modification times.

What checksum verification cannot do

It cannot check themes or plugins that have no published checksums
It ignores wp-config.php, uploads/, and files you created, because no reference exists
It cannot see database content, such as options or posts that contain unwanted code
It cannot detect a case where the distribution source itself was tampered with (see our supply chain article)

"Matches" means "same as the published original", not "safe".

② Take stock of administrator accounts

A trace that often remains after an intrusion is an administrator account you do not recognize. Changing a password does not remove it, and an unfamiliar admin remains a way in.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Filter by role and include the registration time. Then ask:

Can you explain everyone? Who each admin is and why they need that role
Do the registration dates make sense? Any account created when nobody was working on the site
Are the email addresses expected? Former staff, past agencies, or unused mailboxes
Are there too many admins? Often an Editor role is enough

If you find an unfamiliar account, do not delete it on the spot. Deleting removes evidence. Record the situation first.

Fewer administrators is better in general. A periodic pass that downgrades or removes unused accounts shrinks the number of entrances.

③ Check for PHP files under uploads

wp-content/uploads/ holds images and documents added through the media library. Normally it contains no PHP files, because a place for media has no reason to hold executable code.

The check is read-only:

find wp-content/uploads -type f -name '*.php'

No output means this check found nothing. If something is listed:

No idea where it came from: do not open it in a way that runs it. Record the path and modification time
A plugin placed it on purpose: some plugins write generated files there. Confirm which plugin and whether you can explain it

A nearly empty index.php is a common convention that prevents directory listing and is easy to recognize by its content.

A step further is to configure the server so PHP does not run in uploads at all. That reduces entrances rather than detecting intrusions, and the method differs by server, so we will cover it separately.

Make it a routine

These checks are more useful when run the same way on a schedule, looking at the difference from last time.

Record the date and the outcome, including warnings
Until you can explain a warning, do not treat it as "no problem"
Run them after updates too, to see whether anything unfamiliar arrived

If you manage several sites, switching between them with aliases keeps the procedure consistent. Judge the results one site at a time with your own eyes.

If something looks wrong

Record the command, the output, and the time. Do not delete or overwrite anything yet
Confirm it is really abnormal: is it your own change or a plugin's legitimate behavior?
If it still looks abnormal, move to a response that includes recovery. Whether you have a backup you can restore to a clean state decides much of what follows

We will cover the response steps in a separate article. If you are unsure, consult a specialist.

Summary

Updates protect the future. Checking for what is already inside is the other half of maintenance
wp core verify-checksums and wp plugin verify-checksums compare with published hashes. Treat what could not be verified as part of the result
Review administrators with wp user list --role=administrator until you can explain each one
PHP under uploads/ is normally unexpected. If you find it, record it instead of running it
A clean result is not proof of safety. A habit of comparing with last time is what makes the checks useful

One thing to do today: run wp user list --role=administrator and confirm you can explain every name and why it exists.

What Is Autoload in WordPress? How a Bloated wp_options Table Weighs Down Every Request

Susumu Takahashi — Sat, 31 Oct 2026 00:40:24 +0000

Besides posts and pages, every WordPress database has a table called wp_options. It stores site-wide settings: the site title, the permalink structure, the list of active plugins, and the configuration of each plugin, one row per setting.

That table has a column named autoload. It looks like a simple flag, but any row with autoload enabled is loaded on every single request, whether that request needs it or not. When a long-running site's admin screens gradually get heavier, a bloated autoload set is one of the first things worth checking.

Following the previous article on database index basics, this post uses measurements taken on this blog's own WordPress database (7.1 series), using read-only queries only, to explain how autoload works and what happens when it grows too large.

wp_options: the home of site-wide settings

wp_options is a simple key-value table: option_name, option_value, and an autoload column. On this blog it holds 215 rows. Core, themes and plugins all read and write it through get_option() and update_option(), and core settings live side by side with plugin settings.

Autoload means "read it all up front"

Early in each request, WordPress calls wp_load_alloptions(), which fetches every autoloaded row in a single query and keeps the result in memory. After that, any get_option() call for an autoloaded option is answered from memory without touching the database. Options with autoload disabled are fetched individually, only when something actually asks for them.

	Autoload enabled	Autoload disabled
When it is read	Early in every request, all at once	Only when requested
Queries	One query for all of them	One query per option used
Cost on requests that do not use it	Loaded anyway	None

That design makes sense for values nearly every page needs. The catch is the last row: an autoloaded setting used by one obscure admin screen, or left behind by a plugin you deleted years ago, is still read on every page load.

Measuring this blog's autoload set

Grouping this blog's wp_options by the autoload value gives the following:

SELECT autoload, COUNT(*) AS cnt, SUM(LENGTH(option_value)) AS bytes
FROM wp_options GROUP BY autoload;

autoload value	Rows	Total value bytes	Loaded up front?
`on`	101	38,669	Yes
`auto`	84	10,063	Yes
`yes`	3	40	Yes
`off`	24	6,022	No
`no`	3	3	No

188 of 215 rows, about 48 KB of values, are loaded up front. Counting the result of wp_load_alloptions() via wp eval gives the same 188. For a small blog like this one, that is nothing to worry about.

Why there are more values than yes and no

WordPress 6.6 reworked autoload. Besides the legacy yes/no (still honored), you will now see on/off (explicitly set), auto (left for WordPress to decide), and auto-on/auto-off (decided automatically). Which values count as autoloaded is defined by wp_autoload_values_to_autoload(); on this blog it returns yes, on, auto-on and auto.

Since 6.6, if an option is saved without an explicit autoload choice and its serialized size exceeds 150,000 bytes (the default of the wp_max_autoloaded_option_size filter), WordPress keeps it out of the up-front load. This does not help when a plugin explicitly asks for autoload, so it cannot prevent bloat on its own.

The largest rows show why they are needed every time

option_name	Bytes	What it is
`_transient_wp_core_block_css_files`	22,266	Cached list of core block CSS files
`rewrite_rules`	8,349	Rules that map URLs to content
`wp_user_roles`	3,177	Role and capability definitions
`cron`	2,748	Scheduled WP-Cron events

Core's largest entries each have a clear reason to be loaded on every request: routing, permission checks, and the WP-Cron due-event check (see crontab syntax basics vs WP-Cron).

The top entry is a transient, stored in the same table (see how the WordPress Transient API works). In core's set_transient(), a transient saved with an expiration is stored with autoload disabled, while one saved without an expiration is autoloaded:

$autoload = true;
if ( $expiration ) {
    $autoload = false;
    // the expiry time goes into a separate _transient_timeout_ row
}
add_option( $transient_option, $value, '', $autoload );

So any code that saves large transients without an expiration keeps adding to the up-front load.

The up-front query is a full table scan

Running EXPLAIN on the autoload query:

EXPLAIN SELECT option_name, option_value FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

type	possible_keys	key	rows
ALL	autoload	NULL	215

An index on autoload exists, yet the optimizer chooses a full scan, because 188 of 215 rows match. This is the "most rows match, so scanning is cheaper" case from the previous article. The takeaway: autoload cost is about how much is read, not how it is found. No index fixes it; only reducing the autoloaded data does.

What gets heavier when autoload bloats

Every uncached request. Page caching bypasses PHP for anonymous visitors, but admin screens, logged-in browsing, REST API calls, WP-Cron runs, and the first hit after a cache expires all pay the cost. That is why "only the admin feels heavy" often points here.
PHP memory. The loaded values stay in memory for the whole request, and serialized arrays expand when unserialized, pushing requests closer to WP_MEMORY_LIMIT.
Persistent object caches. With Redis or Memcached, the autoload set is stored as one large alloptions item that is fetched and unserialized on each request. Some caches also cap the size of a single item; if the set outgrows that cap, it cannot be cached and falls back to the database every time.

Common causes

Settings left behind by deleted plugins that have no uninstall cleanup
Transients saved without an expiration
Plugins that keep appending logs or statistics to a single option
Large settings arrays, mostly used on one screen, stored as one autoloaded option

None of these break anything on a given day. They accumulate over years of operation.

The Site Health threshold

Tools → Site Health checks the total autoload size. In core, the warning fires above 800,000 bytes (the default of site_status_autoloaded_options_size_limit). Treat it as a prompt to look, not a hard line; the point where it actually hurts depends on the server and caching setup.

Checking without changing anything

# Total bytes of autoloaded options (WP-CLI)
wp option list --autoload=on --format=total_bytes

# Autoload value of one option
wp option get-autoload <option_name>

For a size-ordered list, run a SELECT like the one above through wp db query. Look at the total, the names of the largest rows (their prefixes usually hint at the owner), and whether that owner is still in use.

Fixing it safely: read, verify, keep a way back

Back up first, so any change to wp_options can be reverted (see the 3-2-1 backup rule).
Identify the owner. Never delete an option based on an unfamiliar name alone, and leave settings of active plugins alone.
Prefer turning autoload off over deleting. wp option set-autoload <option_name> off keeps the value and simply loads it on demand, which keeps the risk of breaking something low.
Handle transients with transient tools, such as wp transient delete --expired.
Verify afterwards: admin screens, key pages, and the error log.

Note that wp db optimize defragments tables but does not shrink the autoload set (see wp db check and wp db optimize).

Pitfalls

Deleting options just because the names look unfamiliar
Turning off autoload for values used on every request, which adds a query each time
Expecting an index to help, when the cost comes from the volume read
Judging only by cached front-end pages while admin, REST and cron requests carry the load
Cleaning up once and never checking again
Assuming a deleted plugin took its settings with it

Summary

Autoload is a sensible way to load frequently used settings in one query, but every autoloaded row is read on every request, needed or not. On this blog, 188 of 215 rows (about 48 KB) are loaded up front via a full table scan, and what matters is the volume, not the lookup. Settings from removed plugins and transients without expirations pile up over time, so check the total and the largest rows periodically, and when you act, go in order: back up, identify the owner, prefer disabling autoload over deleting, then verify. Next time: revisions and auto-drafts, another thing that quietly piles up in the WordPress database.

PHP, WordPress core, plugins, themes — who updates what? Splitting "the host's job" from "the site owner's job" on shared hosting

Susumu Takahashi — Fri, 30 Oct 2026 00:53:00 +0000

A follow-up to A critical flaw in PHP itself. How each hosting provider handles updates differs by provider and changes over time, so this article does not claim anything about any specific provider. It covers how to think about the split and how to check it against your own contract.

"Somebody is handling it" is the riskiest assumption

When security updates come up, two beliefs often coexist: "the hosting company surely patches that" and "updating my site is my job." Each is half right.

A WordPress site runs on a stack of layers.

Layer	Examples	Who usually updates it (general tendency)
Hardware, OS, web server	Linux, Apache / nginx	The host
PHP (the runtime)	8.3 branch, etc.	Depends on the contract — sometimes the host, sometimes you choose
Database	MySQL / MariaDB	The host
WordPress core	Core	You (depending on auto-update settings)
Plugins	Various	You (depending on auto-update settings)
Themes	Various	You (depending on auto-update settings)

The important point: only the PHP row says "depends on the contract." That is where things stay vague, and when a PHP-level flaw like the last one appears, you can end up thinking the host raised the version when it was actually a setting you were meant to change.

Each layer is checked in a different place

PHP

Shared hosting commonly looks like one of these. Which one applies depends on provider and plan, so confirm it for your own contract.

A control panel where you pick the PHP version per domain. Patch updates within the chosen branch are often applied by the host, but not always
The host raises the version for everyone, announced in a notice
Old branches that stay selectable after their support ends. Being selectable is not the same as being safe

Two starting points: the host's announcements / status page (PHP updates and end-of-support dates are usually posted there), and the version shown in the control panel. The version actually serving your site is visible in WordPress under Tools → Site Health → Info → Server. php -v over SSH reports the command-line PHP, which can differ from the web one.

WordPress core

Minor releases (e.g. 6.8.1 → 6.8.2) are auto-updated in the background by default; major releases (6.8 → 6.9) are not. We covered this in what WordPress automatic background updates cover. What you should verify is whether anyone has changed that setting.

Plugins and themes

Not auto-updated by default; you decide per plugin. This is entirely the site owner's job, not the host's. An update notice that nobody acts on does nothing.

You can list pending updates with WP-CLI:

wp plugin list --update=available
wp theme list --update=available
wp core check-update

Even where the host does the work, checking is yours

Make sure you can receive the host's notices: outdated contact addresses and spam-filtered mail are common
Track announced deadlines: when an old PHP branch stops being available, put the date on a calendar
Verify the site after the change: if a host raises PHP, an old plugin may stop working — that consequence lands on your site

Even when the host does the work, checking what happened to your site is the owner's job.

If you manage several sites, keep a table

Contracts, servers and PHP versions drift across sites. As the last article noted, working out what's affected after an advisory arrives costs time. Prepare a table during calm periods.

Site	Server (contract)	PHP version / checked on	PHP updated by	Where host notices go
example-a	Host X	8.3.36 (Oct 29)	You choose	Admin mailbox
example-b	Host Y	8.2.35 (Oct 29)	Host, for everyone	Shared address

The last two columns — who updates and where notices go — are the ones that tend to stay blank, and they make the difference in the first hour of an incident.

The shared-responsibility idea

Cloud providers talk about a "shared responsibility model": the provider secures the foundation, and the customer configures and operates what runs on it. Shared hosting follows the same shape, and where the line sits differs slightly per contract.

If you don't know where the line is, a layer can fall into the gap between "the host must be doing it" and "I must be doing it." Part of maintenance is confirming the line, writing it down, and revisiting it regularly.

Summary

The updater differs by layer. PHP depends on the contract, so check it specifically
WordPress core depends on settings; plugins and themes are mostly the owner's job
Even for the host's layers, receiving notices and verifying the site afterwards are yours
For several sites, keep a table that includes "who updates" and "where notices go"

Check once, today, who updates PHP under your own contract. That one answer changes how fast you can move in the next emergency.

Database Index Basics — Why the Same WHERE Clause Can Use an Index or Scan Every Row

Susumu Takahashi — Thu, 29 Oct 2026 00:18:25 +0000

When a database query is slow, the first question people usually ask is: "Is there an index on that column?" Indexes are central to database performance, yet they're often treated as a magic switch. Why do they help? And why does a query sometimes ignore an index that's clearly there?

In this post I'll answer both questions using real EXPLAIN output from the WordPress database (MariaDB) that runs this blog.

An index is a book's index

The classic analogy holds up. To find every page that mentions "transaction" in a thick technical book, you either read every page, or you go to the index at the back, find the entry, and jump straight to the listed pages.

A database table works the same way. Without an index on the column you filter by, the database reads every row and checks each one. That's a full table scan. With an index, it looks the value up in a sorted structure and jumps directly to the matching rows.

The key word is sorted. A book index is useful because its entries are in alphabetical order. Nearly every "why didn't my index get used?" question comes back to that one fact.

B-trees in one paragraph

InnoDB and most other engines store indexes as B-trees (technically B+trees): a shallow tree of "tables of contents for tables of contents." You start at the root, compare your value against ranges, and walk down a few levels to a leaf that points to the actual row. Even a table with a million rows needs only a handful of steps. The leaves are kept in order and linked together, so the same structure serves exact matches, ranges (BETWEEN, >, LIKE 'abc%'), and ORDER BY.

The indexes on this blog's wp_posts table

Here's what SHOW INDEX FROM wp_posts returns on this blog (summarized):

Index	Columns (left to right)
`PRIMARY`	`ID`
`post_name`	`post_name` (first 191 chars)
`type_status_date`	`post_type`, `post_status`, `post_date`, `ID`
`post_parent`	`post_parent`
`post_author`	`post_author`
`type_status_author`	`post_type`, `post_status`, `post_author`

WordPress core creates all of these at install time. Each one matches a query WordPress runs constantly. type_status_date, for example, exists for "published posts, newest first," which runs on every home page and archive view.

Reading EXPLAIN

Prefix a query with EXPLAIN and the database shows its execution plan (how it intends to find the rows) without running the query.

EXPLAIN SELECT ID FROM wp_posts
WHERE post_type = 'post' AND post_status = 'publish'
ORDER BY post_date DESC LIMIT 10;

type	key	rows	Extra
ref	type_status_date	124	Using where; Using index

key: the index actually chosen
type: the access method; ref means "walk the index to rows with a matching value"
rows: the estimated number of rows to examine
Using index: every column the query needs lives inside the index, so the table itself is never read (a covering index)

There's also no Using filesort. The index is already ordered by post_date within each type and status, so it handles both the filtering and the sorting.

Same column, different outcome

Leading wildcards

Condition on `post_name`	type	key	rows
`LIKE 'robots%'`	range	post_name	1
`LIKE '%robots%'`	ALL	NULL	138

Same column, same operator, but type=ALL means a full scan. Words that start with "robots" sit together in a sorted index. Words that contain "robots" could be anywhere, so the order doesn't help. This is why WordPress's built-in search (?s=), which uses LIKE '%term%', gets heavier as a site grows, and why large sites add a dedicated full-text search engine.

Skipping the leftmost column

EXPLAIN SELECT ID FROM wp_posts WHERE post_status = 'publish';

type	possible_keys	key	rows
index	NULL	type_status_author	138

post_status appears in two composite indexes, yet possible_keys is NULL. A composite index can only be searched from its leftmost column. You can't look someone up by first name in a phone book sorted by last name.

The type=index line is worth a second look. It means "read the whole index from start to finish." The optimizer picked it only because the index is smaller than the table and happens to contain ID. Nothing is being filtered. A name in the key column doesn't mean the index is doing its job.

Functions on the column

-- can't use the index
WHERE YEAR(post_date) = 2026
-- can
WHERE post_date >= '2026-01-01' AND post_date < '2027-01-01'

The index stores post_date, not YEAR(post_date). Leave the column untouched and transform the value you compare it against.

No index at all

wp_postmeta indexes post_id and meta_key, but not meta_value. EXPLAIN SELECT post_id FROM wp_postmeta WHERE meta_value = 'x' returns type=ALL. Sites that filter heavily on custom field values with meta_query hit exactly this wall.

Small tables hide the problem

This blog's wp_posts has only about 140 rows, so a full scan finishes instantly. The optimizer may even prefer a full scan on a small table, or when most rows match. The trouble shows up later. A query that seemed fine in development gets heavy once production data piles up. Not being slow on small data proves nothing about large data, so it pays to check for type=ALL early.

Indexes aren't free

Every write updates every index: more indexes mean heavier INSERT/UPDATE/DELETE
They take disk space, sometimes approaching the size of the table itself
Unused indexes are pure cost: an index on a two-value column rarely narrows anything, so the optimizer ignores it and you pay the write cost anyway

If you add custom indexes to WordPress core tables, find the real culprit with the slow query log and EXPLAIN first. Run ALTER TABLE ... ADD INDEX on large tables with a backup and off-peak. After core updates, confirm your additions are still in place. Note that wp db optimize defragments tables and does not create indexes (see my earlier post on wp db check and wp db optimize). For safely embedding values in queries, see $wpdb->prepare() and SQL injection basics.

Common pitfalls

Searching with LIKE '%term%' on large tables
Filtering only on the second or third column of a composite index
Wrapping the column in YEAR(), LOWER(), DATE() and similar functions
Comparing a string column to a number (implicit conversion can disable the index)
Treating any value in EXPLAIN's key column as success
Judging performance on a tiny development dataset
Adding indexes "just in case"

Wrapping up

An index keeps values sorted so the database can reach matching rows without reading everything. Whether it helps comes down to one question: can this condition be answered using the sort order? Prefix matches can, but infix matches can't. Composite indexes work from the left. Function results don't match the stored order. When you run EXPLAIN, check that type isn't ALL, that key is the index you expected, and that rows looks sensible. Next time I'll look at another part of the same database that's read on every single page load: autoloaded options in wp_options.

Why Meta Descriptions Have a Length Limit — and the HTML Entity Trap That Inflates the Count

Susumu Takahashi — Wed, 28 Oct 2026 01:41:29 +0000

Every time we publish a post on this blog, we run an SEO audit script that checks the title, meta description, canonical URL and hreflang tags. On the English posts, one number keeps showing up: 164 chars. The theme is written to cap meta descriptions at 160 characters, yet the audit keeps reporting more. Is the theme broken, or is the audit wrong? Neither. They are simply counting two different strings.

This post uses that "phantom overflow" as a way into two questions: why meta descriptions have a length guideline at all, and how many different things "length" can mean.

What a meta description is (and is not)

A meta description is a short summary placed in the page <head>:

<meta name="description" content="A one- or two-sentence summary of this page." />

It is not shown on the page itself. It is mainly used as a candidate for the snippet under the title in search results, and often as preview text when a URL is shared (many sites put the same text in og:description).

Two things are worth keeping in mind. Google has said the meta description is not used as a ranking signal, and it is not guaranteed to be displayed — search engines frequently pull a different passage from the page to match the query. Its value is on the click side: when it is shown, it helps a reader decide whether to open the page.

Who decides the length limit?

You will see advice like "keep it under 155–160 characters." But neither the HTML specification nor Google's documentation sets a maximum length. A 1,000-character description is valid HTML and will not be treated as an error.

The guideline comes from display width. Snippets are truncated with "…" to fit the space on the results page, and that truncation is based on pixels, not characters. Wide characters (Japanese full-width text takes roughly twice the width of a Latin letter) get cut sooner, mobile results tend to be shorter than desktop ones, and the layout itself changes over time. The "limit" is a rule of thumb, not a rule. The practical takeaway is simple: put the important information first, so the text still makes sense if the end is cut off.

How this blog's theme generates descriptions

Our theme, wpmm-blog, builds the description in a function called wpmm_blog_meta_description(). For a single post, it does roughly this:

$excerpt = has_excerpt() ? get_the_excerpt() : '';
if (!$excerpt) {
    $body = wp_strip_all_tags(strip_shortcodes($post->post_content));
    $excerpt = trim(preg_replace('/\s+/u', ' ', $body));
}
$desc = wp_trim_words($excerpt, 60, '…');

// cap at 160 characters (characters, not bytes)
if (mb_strlen($desc, 'UTF-8') > 160) {
    $desc = mb_substr($desc, 0, 158, 'UTF-8') . '…';
}

And it outputs it like this:

echo '<meta name="description" content="' . esc_attr($desc) . '" />';

One subtle point: wp_trim_words() means different things in different languages. In English it counts 60 words. On our Japanese site, WordPress's translation settings make it count characters instead, because Japanese does not separate words with spaces. So Japanese descriptions come out at 60 characters plus "…" (61), while English descriptions usually exceed 160 characters at 60 words and hit the second cap: 158 characters plus "…" (159).

Where 164 comes from: `esc_attr()` and the apostrophe

Here is the actual output from our previous post on robots.txt:

<meta name="description" content="When a search engine crawler visits a site, it usually doesn&#039;t jump straight to your articles. It first checks robots.txt to learn where it may go, and it rea…" />

The apostrophe in doesn't has become ' — an HTML entity. Inside an attribute value, characters like ", ' and < could be confused with markup, so esc_attr() replaces them with safe notation just before output (we covered this "escape on output" approach in our esc_html()/esc_attr() post).

Character	Entity	Added length
`&`	`&`	+4
`<`	`<`	+3
`>`	`>`	+3
`"`	`"`	+5
`'`	`'`	+5

One apostrophe adds five characters: 159 + 5 = 164. The audit script extracts content="..." from the raw HTML with a regular expression and measures the still-escaped string. Browsers and search engines decode entities when they parse the page, so readers see 159 characters. English, with all its contractions, triggers this on nearly every post; our Japanese posts rarely do.

A deeper version of the trap

The English esc_html()/esc_attr() post also audits at 164 characters, but decodes to only 156:

content="... Instead you see echo esc_html( $title ); or &lt;a h…"

That < was not added by esc_attr(). The post body contains a code example, so the stored HTML already had <a href.... wp_strip_all_tags() removes tags but leaves entities as text, so the 160-character check counted < as four characters. Step by step:

At the cap check: 158 characters (including < as 4 and ' as 1) plus "…" = 159
After esc_attr(): ' becomes ' (+5) = 164, the audited value. esc_attr() does not double-encode the existing <
After decoding: −5 and −3 = 156, what readers actually see

The cap was measuring a string that already contained entities, so posts with lots of code produce shorter visible descriptions than intended. It is harmless here, but it shows that you need to know which stage of the string you are measuring.

"Length" has at least four meanings

For the robots.txt post, measured on the live pages:

Measure	English	Japanese
Characters in HTML source (escaped)	164	61
Characters after decoding	159	61
UTF-8 bytes (decoded)	161	177
Display width	depends on device and font	depends on device and font

The Japanese description is 61 characters but 177 bytes, because most Japanese characters take three bytes in UTF-8 (the "…" does too). Languages disagree as well: PHP's strlen() counts bytes while mb_strlen() counts characters, and JavaScript's .length counts UTF-16 code units, so some emoji count as two. That is why the theme comment insists on "characters, not bytes": truncating Japanese with a byte-based substr() can cut a character in half and emit broken output.

If the goal is to check what readers see, decode first, then count:

import html
raw = "it usually doesn&#039;t jump straight"
print(len(raw))                 # 37 (escaped)
print(len(html.unescape(raw)))  # 32 (what readers see)

Our audit still reports the escaped length, so we treat a small overshoot on English posts as a known, acceptable difference rather than something to "fix" by trimming text.

Common pitfalls

Treating HTML-source length as visible length — entities inflate the count
Capping an already-escaped string — the visible result ends up shorter than planned
Truncating multibyte text by bytes — use mb_substr() in PHP
Ignoring mid-word cuts — character-based truncation produces endings like it rea…; a hand-written excerpt avoids this
Assuming the description will be shown as written — it is a candidate, not a guarantee
Forgetting language differences — wp_trim_words() counts words in English and characters in Japanese

Summary

The meta description "limit" is a guideline derived from display width, not a hard rule, so the most useful habit is to front-load the key message. When you work with lengths, be clear about escaped versus decoded, characters versus bytes, and which stage of processing the string is at. Our recurring "164" was never a broken cap; it was HTML's safe notation for an apostrophe being counted as five extra characters. Check what a number actually measures before acting on it.

DEV Community: Susumu Takahashi

How WordPress Revisions, Autosaves and Auto-Drafts Work — and How to Manage the History in Your Database

Revisions live in the same table as your posts

When revisions are created

Measured: only updated posts have revisions

A revision records the state after saving

Autosaves and auto-drafts

Limiting revisions with WP_POST_REVISIONS

Checking and cleaning up

Do revisions slow down the front end?

Summary

Forgotten files in your public directory: how to find them on your own site, and where to keep them instead

Why forgotten files happen

What can be exposed

How to check your own site

1. List files by extension

2. Confirm whether it is actually reachable

3. Check search engines too

What to do if you find one

Placement principles: do not keep it in public space at all

Summary

WAF and rate limiting basics: what they can and cannot stop, and why they buy time rather than replace updates

What a WAF is: a reception desk in front of the site

What rate limiting is: drawing a line by count

What they are good at

What they are weak at

Common stumbling blocks after turning it on

How to check that it behaves as intended

The relationship to updates: time bought, not a substitute

Limits and things to keep in mind

Summary

A checklist for shrinking your WordPress attack surface: admins, file editing, permissions, wp-config.php, and uploads

What an attack surface is

1. Keep fewer administrators

2. Turn off file editing in the dashboard

3. Use the smallest file permissions that work

4. Protect wp-config.php

5. Do not let PHP run under uploads

Limits to keep in mind

Summary

What to do first when a WordPress site may be compromised: isolate, preserve, restore, rotate credentials

First, do not rush to delete

1. Isolate: stop the damage from spreading

2. Preserve evidence: keep it before you change it

3. Restore from a clean backup

4. Rotate credentials: close the door again

5. Prevent a repeat, then decide when to reopen

Limits to be aware of

Summary

Reading access logs: scans that end in 404, and the 200 responses worth a second look

What an access log records

Routine probing mostly ends in 404

Look at the overall distribution first

Skim the paths that returned 404

The thing not to miss: a suspicious path that returned 200

Why a 200 alone is not enough

A minimal habit

Summary

What is a supply chain attack? When "just update" is not enough

What a supply chain attack is

Public cases (checked as of 2026-11-01)

A CDN-served script changed (2024)

A vendor changed hands (2025–2026)

An update channel was compromised (2026)

What the three cases show

"Apply quickly" and "wait a little" together

What you can do

Know where each item comes from

Watch for changes at the vendor

Keep external scripts to a minimum

Stay able to roll back

If something looks wrong

Summary

Three checks to see whether a site has been compromised: checksums, admin accounts, and PHP in uploads

Why check for "already inside"

① Compare files with the published checksums

Plugins work the same way

What checksum verification cannot do

② Take stock of administrator accounts

③ Check for PHP files under uploads

Limiting revisions with `WP_POST_REVISIONS`

Where 164 comes from: `esc_attr()` and the apostrophe