JB SiteAudit 1.2.1

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_DEBUG is 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 to corrected 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.

JB SiteAudit 1.2.0

An audit log that records what changed, not merely that something did.

Entries now state the change

Before and after values for post titles, bodies, web addresses and parents; custom fields; categories and tags; user roles; and plugin and theme versions. Body edits report word counts and whether the text was reworded or replaced.

Two features that were silently broken

The CSV download and the Settings save both had handlers registered under the old plugin prefix while the link and the form requested the new one. Nothing listened. The download led to a blank page and the settings screen discarded every save without an error.

Changes that were never recorded at all

• Adding a custom field. update_post_meta() on a new key fires added_post_meta, which was not hooked.
• The value held by a deleted custom field. The delete hook receives the value passed to the call, not the stored one.

Far less noise

A plugin update produced up to eleven rows. It now produces one, naming each plugin and the version before and after. Machinery that WordPress and plugins write about themselves - calendar flags, taxonomy caches, patch states, version stamps, trash slug renames, scanner results - is no longer recorded.

Detail screen

Complete before and after values, the exact setting or field name, checksums for content too large to store, where the change came from, and a link to open the changed item.

Accessibility

WCAG 2.2 Level A and AA, verified with a browser driving real key presses: ARIA treegrid with roving tabindex, and reflow at 320px on all four screens.

Full notes in CHANGELOG.md.