ReportedIP Hive 2.0.16 — Promo Frequency Cap & Quota Alert Mails
ReportedIP Hive 2.0.16 puts every upgrade hint behind a single frequency cap, adds relay quota alert mails at 80% and 100%, and clears out a set of Hardening Mode re-arm and relay-backoff bugs. The release is stable and ships through the built-in 12-hour update check.
Sites on auto-update get it within twelve hours. To pull it now, force a check via Dashboard → Updates or download the tagged release from GitHub.
How the unified promo cap changes Hive 2.0.16 for free-tier admins
A new class, ReportedIP_Hive_Promo_Manager, is now the single source of truth for the question “may this upgrade hint show now?”. Every promo surface routes through it: the WooCommerce 2FA banner, the Frontend-2FA inline upsell card, the Mail/SMS-Relay dashboard card, and the Hardening Mode info block. Before 2.0.16 each of those carried its own ad-hoc cooldown and they could stack.
The manager enforces four rules at once:
- 90-day global cap per admin across all promo surfaces.
- 60-day cooldown after a dismiss, scoped per feature.
- Permanent per-user opt-out with a “Don’t show this again” link.
- Kill switch under Settings → Notifications that hides all upgrade hints at once.
The net result: a free-tier admin sees at most about four discreet promo touches per year. The release also removed a duplicate Frontend-2FA upsell card that had no business advertising itself on the Hardening Mode tab, and raised the Two_Factor_Recommend soft-banner dismiss cooldown from 30 minutes to 14 days. The hard-block onboarding path for privileged roles is untouched — a security recommendation still outranks comfort.
Relay quota alerts now reach you by mail
A new ReportedIP_Hive_Quota_Notifier evaluates the relay-quota snapshot after every six-hour cron refresh. When a channel crosses 80% or 100% of its monthly allowance it sends one factual mail to the alert-recipient list. Each channel and stage has a 30-day cooldown, and that cooldown resets automatically at every new billing period (the period_start flip), so a fresh month starts the warnings over.
There is also an in-dashboard companion. When the mail or SMS relay returns HTTP 402 (monthly cap) or 429 (recipient/site backoff), the provider stamps a network-wide reportedip_hive_relay_cap_state_* site-transient. Admin pages then render a non-promotional warning notice — dismissible for 24 hours — explaining that mails currently fall back to wp_mail() and SMS-2FA is paused, with a link to the quota details. The next successful /relay-quota refresh that shows usage below the limit clears the state on its own.
Plan changes send a short factual mail
Tier_Upgrade::on_tier_changed now handles the downgrade path as well as upgrades. On a downgrade it clears the stale post-upgrade banner state, soft-disables the WooCommerce Frontend-2FA toggle — your data is preserved so a later re-upgrade is seamless — and sends a short factual mail. Upgrades trigger a matching welcome mail that points at the remaining setup steps. Both mails can be suppressed with the new toggle under Settings → Notifications.
That settings tab gains three toggles in 2.0.16: hide all upgrade hints (off by default — hints stay on), email when the relay quota reaches 80% or 100%, and email when the plan changes. Security recommendations and operational status notices are deliberately not gated by any of these.
Hardening Mode and relay backoff fixes
Hardening Mode no longer re-arms itself inside the 2-hour lookback
After a natural expiry or an admin deactivate, Hardening Mode could re-arm if the same minute-bucket was still inside the 2-hour SQL lookback. The per-time_window marker now stores the canonical strongest-reason payload instead of a presence flag, so suppression survives the lazy wipe of TRANSIENT_REASON in is_active() and the explicit clear in deactivate(). An deactivate('admin') override now also clears the marker for the live reason’s window, so the override sticks.
A related TTL-low extension bug is fixed too: TRANSIENT_REASON used to expire while hourly extensions kept bumping TRANSIENT_UNTIL, and the next weak sweep then clobbered the original strongest trigger. The extension branch now refreshes the marker TTL alongside TRANSIENT_UNTIL and records a marker for the candidate’s window, so a follow-up sweep cannot fire a second hardening_mode_extended log for the same bucket.
Coordinated-attack events fire once per pattern, not once per cron tick
Security_Monitor::check_coordinated_attacks() now writes a 2-hour log marker per time_window, so the structured coordinated_attack_detected critical event fires once per pattern instead of once per cron sweep. cron_sync_reputation() no longer logs a duplicate Coordinated attacks detected aggregate on top of that — the hourly Activity-log noise an earlier changelog blamed on the cron wrapper was in fact this inner stream.
Relay 429 backoff is now network-wide and honours Retry-After
The relay-mail and relay-sms 429 backoff switched to set_site_transient (network-wide on multisite), preserves the original HTTP status code in the cooldown payload, parses HTTP-date Retry-After headers correctly, and caps the cooldown at DAY_IN_SECONDS instead of one hour. Each of those corrects a real behaviour seen in production: per-blog transients let three subsites independently flood the per-recipient server cap; a synthetic 429 masked a 402 monthly-cap as a “too many sends” message and hid the upgrade prompt; an HTTP-date Retry-After cast to (int) collapsed to 0 and fell back to a 5-minute default; and the one-hour clamp generated hourly probes against a 24-hour server cap.
Smaller correctness fixes
- The 2FA SMS code transient is now written after the provider accepts the send. A pre-dispatch write left stale code hashes in
_transient_rip_2fa_sms_code_<user>for ten minutes when the relay short-circuited via the client backoff. - Enterprise and Honeypot tiers no longer hit the queue
no_quotashort-circuit when the upstream stampsremaining_reports = 0on an unlimited account. A sharedquota_is_unlimited()helper now drives bothhas_report_quota()andget_quota_status(). - The admin “Send test mail” action surfaces a banner when the relay fell back to
wp_mail(), using a newReportedIP_Hive_API::is_relay_in_backoff()probe so you know whether you actually validated the managed-relay path. - Plugin uninstall now flushes plugin transients.
delete_all_plugin_optionsonly matchedoption_name LIKE 'reportedip_hive_%', which skipped the_transient_…and_site_transient_…rows; those keys would otherwise survive uninstall and confuse a fresh re-install. - The Logs UI dropdown now lists
hardening_mode_extendedand the structuredcoordinated_attack_detectedevent types as filters.
How to update to 2.0.16
- In-plugin auto-update. The Plugin Update Checker polls GitHub Releases every 12 hours. Force a check via Dashboard → Updates if you don’t want to wait.
- Manual download. Grab the ZIP from the v2.0.16 release on GitHub.
- WP-CLI.
wp plugin update reportedip-hiveif you manage WordPress from the command line.
For the previous release and the full version history, see the 2.0.15 release notes and the API and Plugin changelog. Setup and configuration live in the WordPress plugin documentation.