wp_options explained · Field guide 07
Does WordPress Keep a History of wp_options Changes?
The short answer.
No. WordPress does not maintain a built-in, universal revision history for wp_options rows. The database normally reflects the current option value. To know who changed it, what the previous value was, and which request caused the write, you need observation in place before the change.
Read the practical guideCurrent state is not change history.
The options table is an implementation layer. It can tell you what is stored now, but not reliably why it is there or which visible settings save produced it.
Database
Current option value
A row can hold a scalar, serialized structure, or plugin-managed data used by several fields.
Missing context
No universal revision trail
Core does not add a readable actor, request, and before-value history for every option update.
Observation
Capture before the write
A settings observer can connect an authorized request to the supported mutations it caused.
Observe the Options API, not only the table afterward.
ConfigOps records supported option additions, updates, and deletes during authorized requests, then presents the original and final values as one investigation.
- 01
Capture before and after
The prior value must be recorded at mutation time. A later database query cannot recreate it reliably.
- 02
Group by request
Several option writes can belong to one human save. Request grouping preserves that causal boundary.
- 03
Reduce repeated writes
When code writes the same option several times, ConfigOps shows the original and final result instead of noisy intermediates.
Evidence stays in WordPress. A conflict, redacted value, incomplete observation, or unsupported storage path prevents automatic Undo.
Read the support contractRecovery procedure
Match the request. Check the current value. Choose the restore scope.
What the options table actually stores
WordPress uses its Options API for many site-level configuration values. In a standard installation those values commonly live in the options table. A value may be a simple string or a serialized structure containing several related plugin settings.
The table is optimized for the application’s current state, not for human-readable auditing. A database backup can preserve an older snapshot, but it does not by itself explain which request changed a row or whether copying that old value back would overwrite newer work.
Changing a serialized or structured option with the wrong shape can damage neighboring settings. Prefer the owning admin interface or a recovery path that understands the value.
How ConfigOps builds an options history
ConfigOps observes supported Options API mutations caused by authorized wp-admin, REST, and WP-CLI requests. It groups those writes by request, records relevant context, and reduces repeated changes to the first old value and last new value.
The resulting history stays local to WordPress for 30 days by default. Probable secrets are replaced before persistence. Custom tables remain outside the generic Options API history unless an explicit adapter provides the necessary interpretation.
Recover an option without overwriting newer state
A recorded old value is not enough for safe restoration. Between the harmful save and the attempted undo, another user or process may have changed the same option. Restoring the old snapshot blindly would erase that newer state.
ConfigOps compares the current stored value with the result captured after the original save. Only a match permits automatic restoration for supported evidence. A mismatch becomes a visible conflict and leaves the current value untouched.
- No trustworthy pre-change value exists.
- The incident includes custom tables, files, code, content, or remote services.
- The site is unavailable or the affected layer is unknown.
- A tested backup provides the only complete known-good state.
Sources and next steps
Undo boundaries
Can ConfigOps undo this save?
Check whether the request was observed, its evidence is complete, and current values still match.
Can I see an old wp_options value after it was overwritten?
Not from WordPress core alone. You need a prior backup, database-level history, or an observer that recorded the value before the change.
Are all WordPress plugin settings in wp_options?
No. Many use the Options API, but plugins may also use custom tables, files, caches, or remote services.
Is copying a row from an old backup a safe undo?
Not automatically. The value may be structured, version-dependent, or newer than related state. Compare on staging and verify the owning component first.