• Every Pro feature vanished after I updated the free plugin. The add-on is older than the floor the core sets (GuardForge Pro 1.4.0 for free 1.6.0; GuardForge Pro 1.2.0 for free 1.3.0 to 1.5.x). It is switched off whole rather than left running — from free 1.6.0 on it is not even started — and a red admin notice names the installed version, the required one and what stopped. If Dashboard → Updates lists no update for the add-on, download it from your Avakode dashboard (Downloads) and upload it over the old copy in Plugins → Add New Plugin → Upload Plugin. Install the current add-on and everything returns. Your logs, baselines and settings are kept.
• A notice says GuardForge Pro 1.4.0 requires GuardForge 1.6.0 or newer. The add-on was updated before the free plugin. Pro 1.4.0 does not start beside an older free core (that core still carries its own upgrade prompt and License screen); the notice names the core version it found. Update GuardForge from the Plugins screen and the add-on starts again.
• Locked out of my own site. Use the Unblock IP screen from another network, or delete the _transient_gf_bf_% rows (the address is hashed, so delete the whole prefix). If 2FA is the blocker, a recovery code works once.
• Nothing gets blocked and no alert e-mail arrives. Check GuardForge > Settings for the staging-mode panel. If it says the mode is on, the site looks like a copy — the login log will show soft_locked rows where a lockout would have been. The panel names the signal that decided it, and “always treat this site as production” turns it off.
• A file is reported as “not in the official build”. That is the finding worth acting on: nothing wordpress.org published contains it. Open it before deleting it, and use the Restore button (Avakode build only; the wordpress.org package links a core file to Dashboard → Updates instead) only on core files — for a plugin, reinstall the release from the Plugins screen.
• Everything is “no reference”. That is normal for themes and for premium or custom plugins: nobody publishes hashes for them, so they stay on the scan-to-scan comparison. It is also what a fresh install shows for a day or two after a release, while wordpress.org catches up; the answer is cached for three days in that case, not thirty.
• “Verify chain” says the chain is broken. It names the first row that failed. Check whether anybody has edited or deleted rows in the table directly — restoring a database backup over a live log will also break it, because the rows after the restore point at hashes the restored tail no longer produces.
• “Verify chain” says the check was truncated. The log is larger than fifty thousand rows. The check covered the oldest part; there is no resume today. Lower audit_log_keep_days if the table is routinely that large.
• The vulnerability list is empty, or says the feed brought nothing (Avakode build). That is honest, not broken: the plugin refuses an empty document rather than clearing the mirror on the strength of somebody else’s bad deploy. It will retry on the next daily run.
• The vulnerability screen shows a dash in the Summary column (Avakode build). Free rows have no summary — the public endpoint does not send one. Pro rows do.
• The Vulnerabilities screen says the advisory database is served by GuardForge Pro, and lists nothing. You are on the wordpress.org package: it carries no free feed (that one belongs to the Avakode build and is switched on in Settings), so the screen lists advisories only while the Pro add-on’s real-time feed is running.
• There is no Explain button on the login log, the audit log or the file-integrity screen. The button is in the Avakode build only (the free zip at avakode.com/download); the wordpress.org package does not have it, and the Pro add-on does not add it.
• There is no Forge Suite item in the admin menu. The Forge Suite screen is part of the Avakode build; the wordpress.org package does not carry it. To connect the Pro licence on that package use GuardForge → License (add-on 1.4.1 or newer).
• Patch by update never does anything. It needs all of: the switch on, an advisory that names a fixed version, an update WordPress is actually offering, and that offered version outside the advisory’s affected range. A range it cannot parse, a * range, a staging copy, a symlinked plugin directory, a deny-list entry, or a failure in the last 24 hours all stop it — by design.
• An alert never arrived. Press “Send test” on the channel: it uses the same dispatcher and reports the HTTP status. Then check the channel’s minimum severity, the digest mode (an hourly or daily digest is not late, it is batched) and quiet hours — which hold everything except lockdown and malware.
• The site locked itself down. Auto-lockdown fired: twenty addresses locked out inside ten minutes, or a malware finding if that trigger is on. The audit log has both the reason and the timestamp; it lifts itself after the configured window, or you can lift it by hand from GuardForge > Lockdown.
• The badge link 404s. It is refused when the site’s host name no longer matches the one the badge was issued for — which is what stops a staging copy publishing the live site’s grade. Press Issue a new link on GuardForge > Hardening score.
• A plugin stopped working after activation. The REST allow-list is the usual cause. Add the plugin’s namespace under GuardForge > Settings > API & Protocols.
• The WAF blocked a legitimate request. The block is logged with the rule that fired, in GuardForge > Audit log as a waf_block row. Administrators and the addresses on the IP whitelist (GuardForge > Settings) are exempt. There is no setting to switch off one rule or exempt one parameter today.
• Cloudflare sync says “not connected”. Both the Zone ID and a token are required, and the token needs Firewall Services → Edit on that zone.
• Everyone shows up as a Cloudflare address in the login log. The edge range list is stale. With Pro it refreshes daily; the Cloudflare screen says when it last changed.