woocommerce Case study
Options Autoload Guard
Every WordPress request loads the autoloaded options into memory before anything else happens. When plugins start writing transients with autoload set to yes, that payload grows quietly until page generation slows down for no visible reason. This plugin enforces the one rule that prevents it.
The business problem
Several plugins on the store wrote transients into wp_options with autoload set to yes. Autoloaded options are read on every single request, cached or not, so a few thousand stray transient rows turn into memory and query weight on every page view. The cost is real but it never shows up as an error, which is exactly why it survives for months.
What I delivered
- mu-options-autoload-guard.php, which flips any transient row found with autoload=yes back to no and does nothing else.
- A once-per-day execution lock held in a site transient, so the guard costs one cached read on every request but only touches the database once in 24 hours.
- A separate monitoring count that logs when the total autoload=yes population passes 4,000 rows, kept behind a constant so it stays off in normal operation.
Technical approach
- The corrective UPDATE only runs when a preceding COUNT(*) finds at least one offending row, so a healthy site pays for the count and nothing more.
- It hooks wp_loaded at priority 50, late enough that plugins which write transients during boot have already done so.
- The monitoring query counts the indexed autoload column rather than measuring row size, which keeps it cheap enough to run alongside the corrective pass.
- Logging is compiled out by default through a constant, because a guard that writes to error_log on every run becomes its own kind of noise.
Result and evidence
Transient rows no longer accumulate in the autoload set. This is a preventive control rather than a one-time fix: it corrects whatever the currently installed plugins do wrong, every day, without me having to audit them individually after each update.
Commercial value
Plugin updates regularly reintroduce this bug. Enforcing the rule in code rather than fixing the table by hand means a bad release costs a day of drift instead of a week of unexplained slowness.
Readable implementation brief
implementation_brief {
project: "Options Autoload Guard"
file: "mu-plugins/mu-options-autoload-guard.php (43 lines)"
invariant: "no _transient_ row may have autoload = yes"
hook: "wp_loaded, priority 50"
rate_limit: "site transient lock, one DB pass per 24h"
alert: "logs when total autoload=yes exceeds 4000 rows"
default: "logging off; correction always on"
}What this project shows
Most of the value here is in what the plugin refuses to do. It does not clean the options table, deduplicate, or optimize; it enforces exactly one invariant.
Small, single-purpose guards like this are easy to review, easy to remove, and hard to get wrong. That is usually the right shape for infrastructure that runs on every request.