v0.31.0

Added

• Database Optimize subsystem — new src/DbOptimize/ package
  with three REST routes powering the dashboard's
  /sites/{site}/db-optimize tab.

  Routes (all HMAC-protected):

  • POST /wp-json/deckwp/v1/db-scan — read-only snapshot. Returns
    the install's table inventory (name / engine / row count /
    data + index size / overhead bytes via Data_free) plus the
    seven well-known cleanup-target counts: post revisions, spam
    comments, auto-drafts >7 days old, trashed posts + comments,
    expired transients, orphaned postmeta, pingbacks/trackbacks.
    Filtered to the WP table prefix so a shared DB hosting multiple
    apps doesn't bleed unrelated tables into the snapshot.

  • POST /wp-json/deckwp/v1/db-cleanup — body {categories: [...]}.
    Executes DELETEs for the operator-selected cleanup categories.
    Per-category try/catch isolates failures (one broken category
    doesn't abort the sweep). Each category's matching wp_postmeta
    / wp_commentmeta rows are deleted in the same statement so
    cleanups don't orphan meta rows.

  • POST /wp-json/deckwp/v1/db-optimize-tables — body
    {tables: [...]}. Runs OPTIMIZE TABLE against the requested
    list. Two-layer allowlist defends against SQL injection: each
    table name must (1) match a row returned by SHOW TABLES on
    the install AND (2) match ^[A-Za-z0-9_]+$. Reports per-table
    reclaimed_bytes by snapshotting Data_free before/after.

  Multisite posture: scoped to the current blog's tables (per-blog,
  not network-wide). Operators pairing a sub-blog see that blog's
  bytes; pairing the root blog catches network-wide options /
  sitemeta transients automatically.

Fixed

• SiteHealth\Runner now pre-loads the wp-admin/includes/
  utility files that WP_Site_Health test methods depend on.
  Without this, REST-request context (no auto-load of admin
  files) caused 5+ checks to throw Call to undefined function get_core_updates() / get_plugin_updates() /
  get_theme_updates() / wp_check_php_version(), which the
  Runner's per-test try/catch swallowed and surfaced as
  status=error rows on the dashboard's Health tab.

  Confirmed in prod by an operator running the first manual
  snapshot on wptestes (Health tab showed 5 ERROR rows for
  "WordPress Version", "Plugin Versions", "Theme Versions",
  "PHP Version", etc.).

  Loaded up-front (each require_once is idempotent + cheap):

  • wp-admin/includes/update.php — core/plugin/theme update
    lookups
  • wp-admin/includes/misc.php — wp_check_php_version
  • wp-admin/includes/plugin.php — get_plugins,
    get_mu_plugins, is_plugin_active
  • wp-admin/includes/theme.php — theme metadata
  • wp-admin/includes/file.php — WP_Filesystem for tests
    that probe disk
  • wp-admin/includes/class-wp-debug-data.php — used by the
    Site Health debug-info test

  All wrapped in is_readable() checks so a future WP version
  that reorganizes any of these doesn't break the connector.

Wire contract change

None. Pure server-side fix; the response shape is unchanged.
Pre-existing error rows on prior runs stay as-is — only NEW
runs (manual click or hourly cron tick) on v0.30.0+ get the
full classification.