Prepared for submission to the WordPress.org plugin directory.
Checked with the official Plugin Check tool: 12 errors and 130 warnings down to 0 errors and 81 warnings, with no change to what the plugin records.
The finding that mattered
The checker reported this plugin as bundling its own updater - a practice WordPress.org bans outright. It never did. The update transients were listed by name in the ignore list, being options this plugin refuses to record, and the scanner matched the strings. They were already covered by the general transient test, so naming them was redundant as well as misleading.
Submitting without running the checker would have meant a rejection for a banned practice rather than a routine fix.
Also in this release
- Client-supplied values are sanitised as well as unslashed before being stored. The user agent in particular is sent by the caller and kept.
- Settings input is sanitised on the way in, keeping line breaks in the multi-line fields.
- Internal failures log only when
WP_DEBUGis on. Failures are still swallowed, because logging must never break a page. - Text domain and translators comment on the one plural string.
- A row identifier escaped at the point of output.
Tested up tocorrected to 7.0.
What the remaining warnings are
Direct database access, which is inherent to a plugin that owns a table and reads it live. Each significant case now carries a written justification: table names come from $wpdb->prefix, sort columns are whitelisted, every user value is bound as a placeholder, and results are deliberately not cached - a stale audit log would misrepresent the record.
Full notes in CHANGELOG.md.