BadgerScan changelog
====================

The readme.txt changelog keeps only the most recent releases, as the WordPress.org plugin
guidelines ask. This file is the complete history.

= 0.5.27 =
* Internal: restored a code-analysis annotation that was dropped in 0.5.23, so the bounded execution-time guard no longer shows up as an unexplained warning in WordPress's Plugin Check.

= 0.5.26 =
* The note on the connect form no longer promises a daily scan when you have switched automatic contact off.
* Tidied two internal comments that still described how the automatic-contact switch worked before 0.5.25, and one duplicated style rule.

= 0.5.25 =
* Switching automatic contact off now stays off. Previously, connecting or disconnecting an account afterwards re-recorded your consent and quietly restarted the 15-minute dashboard check, while the screen still showed it switched off.
* That switch now clearly governs both automatic behaviours, the daily scan and the dashboard re-scan check, rather than appearing to control only the daily scan.
* The on-screen notice now says that a scan also happens once a day without a click, unless you switch it off.
* Deleting the plugin from a multisite network now removes its scheduled jobs from every site, not just the one it was deleted from.

= 0.5.24 =
* Fixed: connecting or disconnecting an account switched the automatic daily scan off, because those forms share a handler with the scan form and did not carry the new daily-scan checkbox. Connecting an account no longer disables the automation it enables.
* On a multisite network, the daily scan is now scheduled on every site rather than only the one the plugin was activated from.
* Corrected the data list in this readme: the plugin no longer sends an email address, and it does send the plugin version and the names of any suspicious files it flags.
* Added an FAQ entry explaining why the plugin's own code contains words like eval and base64_decode (it searches for them; it never runs them).
* Stopped writing a cached scan result that nothing read back.

= 0.5.23 =
* You can now switch the automatic daily scan off from the BadgerScan screen. Before this, running one scan started a daily one with no way to stop it short of deactivating the plugin.
* The 15-minute check for re-scans you queue from your dashboard is now described in the plugin and in this readme. It was never hidden, but it was not written down either.
* Corrected the "read-only" wording. Every check is still read-only about your site and nothing about your files, settings, or content is ever changed, but the plugin does store its own settings and cached results, and saying it never writes to the database at all was too broad.
* Restored a WordPress file the previous release removed by mistake, which had silently stopped the core-integrity and auto-update checks from running on the automatic daily scan.
* Deleting the plugin now clears its data from every site in a multisite network, not just the current one.
* Scanning no longer forces a WordPress update check on every run, and no longer removes the PHP time limit outright.

= 0.5.22 =
* The sensitive-files finding now says those files are present in your web root, rather than claiming they are reachable from the web. From inside your site we can only see that the file exists; whether your server actually serves it is something only the outside scan can confirm. The severity is unchanged, because a credentials file sitting in the web root is a real risk whether or not a rule currently blocks it.
* Removed two unnecessary WordPress admin file loads.

= 0.5.21 =
* The admin page's styles are now tied to the screen identifier WordPress itself assigns, instead of one assumed in advance, so they cannot fail to load.

= 0.5.20 =
* Compatibility: the one place that still passed the autoload setting as a string now passes a boolean, matching every other option write in the plugin and the form newer WordPress versions expect.

= 0.5.19 =
* The automatic daily scan now runs for every site that has consented, not only sites with an account. It was built-in functionality gated behind connecting, which the WordPress.org guidelines do not allow, and there was no good reason for it: the scan result is useful on its own. Consent is still required, because the scan contacts an external service.
* The admin page's styles are now delivered through WordPress's own enqueue system instead of an inline style tag.
* The uploads folder is now located through WordPress rather than assumed to be wp-content/uploads, so the check behaves correctly on multisite and on installs with a custom uploads path.
* Removed leftover references to the closed beta.

= 0.5.18 =
* Hardening and code-quality pass ahead of the WordPress.org listing. The one user-visible effect is none: no check, grade, or finding changes.
* The status glyph beside each finding is now escaped on output like every other value we print, rather than emitted as a raw HTML entity.
* Moving the stored connect key off autoload no longer needs a direct database write, and no longer depends on a function only present in WordPress 6.4 and later.

= 0.5.17 =
* Fairer XML-RPC reporting: if Jetpack or VaultPress is active (including network-activated on multisite), XML-RPC being enabled is now reported as expected rather than as a weakness, since those plugins need it to work. The advice becomes how to contain the risk without breaking them, such as allowing only that plugin's IP ranges or rate-limiting logins. Sites without such a plugin still get the finding, now worded around what actually makes XML-RPC risky.
* readme.html is now reported as "present in your web root" rather than as a confirmed disclosure. Whether visitors can actually read it is your web server's decision, which only the full outside scan can see, so the plugin no longer claims an exposure it cannot observe. The advice leads with blocking it at the web server, since deleting the file needs file access that managed hosting often does not give you.

= 0.5.16 =
* New informational check: your report now notes how many of your active plugins are not set to auto-update (and calls it out if plugin auto-updates are turned off for the whole site). Auto-updates apply security fixes without waiting on a person. This is context only and never affects your grade, since leaving auto-updates off can be a deliberate choice. It reflects the effective setting, so a managed host that patches for you is not counted as missing.

= 0.5.15 =
* The core integrity check no longer raises a false "core files do not match" alarm while a WordPress update is installing. A core update briefly leaves your site a mix of two releases, which used to look like modified files for a scan run in that moment. The check now confirms each changed file against the official checksums for both your current version and the version being installed: if every change matches the incoming release it reports "core update in progress" and invites a re-scan, while a file that matches no official release still surfaces as a critical finding. The decision is based only on WordPress.org's official checksums, never on any local file, so it cannot be tricked into staying quiet.

= 0.5.14 =
* wp-admin now shows the right grade for your plan. With a connected Pro account, it shows the same combined inside and outside grade as your dashboard, because the outside scan now runs as part of the scan. Without one, it shows your inside grade, clearly labeled, and no longer over-reports A+ by skipping the hardening checks (HSTS, DMARC, two-factor) that only the full scan confirms.
* More accurate HTTPS check. The grade now follows your site's canonical address (Site and Home URL) rather than how you happen to be viewing wp-admin, so browsing the dashboard over https no longer hides a site that still serves visitors over plain HTTP.
* The HTTPS finding no longer tells you to install a certificate when it simply could not reach your site over https to check (for example when outbound requests are blocked from your server). It now separates three cases: you have a certificate and only need to enforce it, a certificate responded but is not valid (expired, self-signed, or for the wrong domain), and https could not be confirmed from here.
* Clearer account message: if your BadgerScan account is already at its site limit, connecting a new site now says so plainly instead of showing a generic "connect key was not recognized" error.
* The connect / account panel now stays visible if a scan can't reach the service, so a temporary error no longer hides your connection status.
* Widened login-protection detection (WP Cerber, Shield Security) so more hardened sites are recognized.

= 0.5.13 =
* The HTTPS finding now verifies whether a certificate is actually present. If you already have one and only the http-to-https redirect is missing, it says so and does not tell you to install a certificate; if no valid certificate responds, it correctly recommends installing one.

= 0.5.12 =
* Clearer HTTPS finding: if your site loads over plain HTTP but already has a certificate, we no longer tell you to install one. It now explains how to switch your WordPress Site and Home URL to https and add a redirect.

= 0.5.11 =
* The inactive-theme check now keeps one default (Twenty*) theme as the recommended fallback instead of flagging it, so a site that correctly keeps a single backup theme is no longer counted as having an unnecessary inactive theme. Extra inactive themes are still flagged.

= 0.5.10 =
* Security: the user-enumeration self-check now keeps TLS verification on for public sites, so a certificate error (the signal of an on-path attacker) is never silently ignored. The relaxed-TLS fallback is limited to loopback and private/dev hosts, where self-signed certificates are normal.
* Tested with WordPress 7.0.

= 0.5.9 =
* The dashboard now shows a live "active" indicator: the plugin's 15-minute check-in is recorded, so a connected site shows as active and you can tell if the plugin stops checking in (deactivated, disconnected, or a stalled cron).
* Your installed plugin version now refreshes on each check-in (about every 15 minutes) instead of only on the daily scan.

= 0.5.8 =
* "No two-factor or login-protection plugin detected" is now medium severity, not high. It is a heuristic (it looks for known security-plugin names), so it no longer single-handedly caps the grade of a site that is otherwise clean. It is still surfaced prominently.
* Renamed the inside "Exposure" category to "Exposed files" so it no longer collides with the outside scan's "Exposure" category in the combined report.

= 0.5.7 =
* The connected status now names the account your scans save to. If that is not the account whose dashboard you use, your key belongs to a different account, the most common reason scans do not appear. "Connected" now also means the scan actually saved, not just that the key was recognized.

= 0.5.6 =
* Disconnect no longer triggers a scan. The connection status is now truthful: if a saved key is not recognized by the service, the plugin tells you the scan did not save and prompts you to re-enter the key, instead of showing a false "connected".

= 0.5.5 =
* Fix connecting an account: "Connect & save" now works on the first click. Consent is given by clicking the button (with a clear note about what's sent), so there's no separate checkbox to miss, and connecting no longer silently does nothing until a scan had been run first.

= 0.5.4 =
* The plugin now reports its version to your dashboard so it can tell you when a site is running an out-of-date BadgerScan and needs updating.

= 0.5.3 =
* Copy: the scan button now reads "Run security scan".

= 0.5.2 =
* Fix a false positive: the parent of an active child theme is no longer counted as an inactive theme or suggested for deletion (a child theme cannot run without its parent).

= 0.5.1 =
* Security hardening for client networks: the plugin now fully validates and size-bounds everything the BadgerScan service returns, so a malformed, oversized, or hostile response can never crash, hang, or slow your site. Connect key moved off autoload and out of request URLs; TLS verified on all non-loopback checks.

= 0.5.0 =
* Rescan from the dashboard: you can now queue a fresh scan from the BadgerScan web portal. The plugin checks for it (outbound only, nothing is opened on your site) and runs it within about 15 minutes.

= 0.4.2 =
* New free check: flags when usernames are exposed via the REST API (user enumeration), the first half of a brute-force attack.

= 0.4.1 =
* New free checks: flags when no two-factor or brute-force-protection plugin is active (logins are the #1 attack surface), and when wp-cron is disabled (which scheduled scans rely on).

= 0.4.0 =
* Reworked the results screen for clarity: a "Fix these first" priorities block, findings sorted worst-first with the supporting evidence shown, and a count of any known CVEs matched to your exact versions.
* The connect-account and Pro options now appear under your result (after you see your grade), not before it.

= 0.3.1 =
* Far fewer false positives on the uploads check: skip the harmless "Silence is golden" index.php stubs that legit plugins drop, and only flag a file CRITICAL when its contents actually match backdoor patterns; other PHP is a low-severity note.

= 0.3.0 =
* New checks: core-file integrity (verifies your WordPress core files against the official release to catch tampering), PHP executables hiding in the uploads folder (a common backdoor), end-of-life PHP, weak or unset authentication keys/salts, and HTTPS for the admin area.

= 0.2.2 =
* Redesigned the results screen to match the BadgerScan web app: per-grade color ramp, a grade hero with a status pill, category grade badges, and severity-coded findings.

= 0.2.1 =
* Rebranded the wp-admin screen to the BadgerScan look (orange button, wordmark, brand cards, grade badge).
* Copy fix on the reviewed-report note.

= 0.2.0 =
* Single free/Pro model: the scan and grade are free; connecting an account unlocks Pro.
* Added the external-service data disclosure and an explicit consent step before any data is sent.
* Added optional automatic daily scans for connected (Pro) sites.

= 0.1.0 =
* Initial release: authenticated read-only scan with a graded report.
