The introductory post covered what Site Defaults does. This one is about the two mechanisms underneath it: how a preset actually gets applied, and how the plugin notices when something changes afterward.
Presets are allowlisted, not freeform
Site Defaults ships four starting presets — Agency, Business, Blog, and Development — each one a fixed set of WordPress option values defined in includes/class-defaults.php. There’s no arbitrary option editor hiding behind this: the set of options a preset can touch is allowlisted in code, so a preset can’t be expanded at runtime into something that writes options nobody reviewed.
Applying a preset is explicit and visible before it happens. The settings page shows a before/after preview of every option the preset would change against the site’s current values, and the apply action itself is capability- and nonce-protected — it’s a deliberate admin action, not something that fires as a side effect of visiting a page. includes/class-applier.php is the only code path that actually mutates settings, which keeps “what changed and why” answerable from one place instead of scattered across the plugin.
Customize creates a derivative, not a mutation
Picking “Customize” on a preset doesn’t edit that preset in place — it creates a persistent Custom preset, seeded from the one you started with. Any values you haven’t touched keep the original preset’s defaults; only the fields you actually change become part of your Custom derivative. That matters because it means tweaking one setting on top of “Business” doesn’t silently drift the whole preset into something undocumented — the base preset stays exactly as shipped, and your customization is its own named, inspectable thing (includes/class-custom-preset.php validates and persists it against the same allowlist as the built-in presets).
A small plugin-owned audit record tracks the most recently applied preset, so “what did we apply, and when” doesn’t depend on remembering or on WordPress’s generic revision history.
Drift monitoring: baseline, compare, resolve
Applying a preset once is the easy part. The harder, more useful piece is includes/class-drift-monitor.php, which takes a baseline snapshot of the applied values and then watches for changes — a theme resetting a setting, another plugin writing over it, a manual edit in Settings. This is event-driven, not a polling cron job: it reacts to the same WordPress hooks that would fire when those options change, and compares the live value against the stored baseline.
When something drifts, it surfaces in three places that all point back to one underlying record rather than three separate alerts: the Site Defaults settings page (monitoring intentionally sits above preset controls on that page, since unresolved drift is more urgent than picking a new preset), an administrator-only admin notice, and a WordPress Site Health result. None of these duplicate the detailed report — they all link back to the same page.
Resolution is explicit, with four actions and no silent auto-correction: restore the baseline value, accept the drift as the new expected state, stop monitoring that setting, or resume monitoring one you’d previously stopped. Nothing gets reverted behind the site owner’s back; drift just sits there, visible, until someone decides what to do with it.
Why there’s no uninstall restoration
One choice that surprises people: Site Defaults does not restore the WordPress settings it finds when you uninstall it. The README is blunt about why — after a preset is applied, the site owner or another plugin may have legitimately changed those values since. Restoring whatever was there before the preset, at uninstall time, would mean overwriting real, current configuration with stale history. So uninstall cleans up only the plugin’s own data — baselines, audit records, policy state — and leaves your site’s settings exactly as they are.
The other half: cleanup policies
Alongside presets and drift monitoring, Site Defaults ships thirteen reversible cleanup policies — things like reducing common public user-enumeration paths — each with a preset-level preview and an individual on/off control. They follow the same rule as everything else in the plugin: previewable before you commit, and reversible after. There’s no policy here that quietly rewrites something it can’t undo.