Safety Passwords

The periodic check starts a required reset and attempts one recovery email. Later checks keep the reset pending, even if that email fails; they do not retry the email. A successful reset or profile password change clears the pending state and renews the period. Before expiry, the profile shows a countdown and the admin bar shows a reminder in the final seven days. After expiry, they ask for a password change without a countdown; if a reset is already pending, they point to the recovery form. An interval of 0 disables periodic resets and these reminders.

Settings apply to the current network. Only network administrators with manage_network_options can change them. On a single-network installation, periodic and manual checks include every account, even one without site membership. On a multi-network installation, each network checks accounts with membership on at least one of its sites, including inactive sites. It excludes accounts assigned only to another network or to no site. Passwords and password history belong to the WordPress account globally, so a reset of an account shared by networks affects it everywhere. The plugin keeps one…

Normally, no manual action is needed. The first eligible request records current password history, grants administrator capabilities, and schedules checks. A changed plugin version triggers automatic setup on the next eligible request, including after file, Composer, or CI deployment, if the new code loads against the target database. Failed setup retries with bounded delays. Eligible requests also repair missing or duplicate periodic events. A code change that requires a fresh full initialization must advance the plugin version marker. The settings page shows its diagnostic panel only while…

Periodic resets use WP-Cron. WordPress requests or an external cron trigger are needed for them to run on time. Automatic setup and schedule repair also require the plugin to load; they cannot run while the site is idle. Standard plugin deactivation removes the periodic schedule and invalidates setup state for later activation.

Remove the MU loader and deactivate any separately active standard copy. Removing the loader does not run deactivation, so manually remove the safety_passwords_periodically_reset event from the network’s main site and any legacy subsites. Saved settings and password history remain. If the same-version loader returns, its retained setup marker does not trigger a full history pass. Run Initialize / repair or wp safety init --url= to include current passwords for accounts added during the gap. Password changes made while the code was absent cannot be reconstructed.

With the plugin loaded, wp user update with a password and wp user reset-password complete any pending reset, renew the period, and record the saved password in history. These administrative changes bypass password strength and reuse checks; WP-CLI warns on stderr when a password is changed. Later changes through web forms still check password history. Changes made with the plugin skipped cannot update its history or reset state, and WP-CLI changes made before version 1.5 are not repaired automatically.

The plugin integrates with Stream. Current password reset logs use fixed failure categories and aggregate periodic reset and reminder counts, without account identifiers or WordPress error details. wp safety check-users likewise logs only aggregate counts and reports Success: Done. Older Stream records may contain details from previous versions. Site operators should review those records privately under their retention policy; updating the plugin does not remove them.

Background reset emails and silent reset links also work on WordPress 5.0 through 5.6, where the login-page recovery function is unavailable during periodic checks.

The release package includes runtime dependencies. If installing from a source checkout instead, run composer install --no-dev --no-scripts in plugin-dir/ before WordPress loads the plugin.