Affinity Guard 2.0.0

Removes self updating.

A must-use file runs on every request and cannot be deactivated from the admin. Giving that file the ability to fetch code from the network and overwrite itself is a remote foothold on every site that runs it, and all it bought was not having to deploy. The plugin now makes no outbound requests, no writes to disk, and registers no cron — it reads two constants and answers four WordPress filters.

Breaking

• AFFINITY_GUARD_SELF_UPDATE is gone. Leaving it defined in wp-config.php is harmless but does nothing.
• The affinity_guard_self_update_enabled filter and the affinity_guard_self_updated / affinity_guard_self_update_failed actions are gone. Anything hooking them becomes dead code rather than an error.

Upgrading from 1.x

Copy affinity-guard.php over the installed file. Core update behaviour is unchanged — same defaults, same constants, same filters.

Two bits of 1.x residue are left behind deliberately, because clearing them would have required migration code running even on disabled installs:

wp cron event delete affinity_guard_self_update   # stale daily event, if scheduled
rm wp-content/mu-plugins/affinity-guard.php.bak   # only if a self update ever ran

This plugin no longer updates itself — deploy new versions the way you deploy everything else.

Full notes in CHANGELOG.md.