=== Shabnam Tornado Database Maintenance ===
Tags: database, cleanup, backup, integrity, reindex
Requires at least: 7.0
Tested up to: 7.0
Requires PHP: 8.3
Stable tag: 2.4.2
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Inspect, back up, clean, and repair WordPress databases with safe cleanup, extension detection, and controlled reindexing.

== Description ==

Shabnam Tornado Database Maintenance is a WordPress database inspection, cleanup, backup, integrity, and recovery toolkit. It combines routine database housekeeping with advanced maintenance engines, while protecting destructive actions with previews, verified backups, ownership evidence, and live dependency checks.

Tornado reads active table names through $wpdb and supports custom database prefixes, including shcd_. It does not assume the default wp_ prefix. This readme documents version 2.4.2.

= Administration Languages =

Tornado follows the language of the current WordPress administration user. Persian, English, and Arabic translations are included. Change the Language field in your WordPress user profile to select the administration language; Tornado has no separate language setting. When the profile uses the site default, WordPress supplies that language. Other locales fall back to English.

English uses a left-to-right layout. Persian and Arabic use right-to-left layouts. Interface labels, cleanup controls, supported report messages, errors, and number formatting follow the selected administration locale. Content titles, table names, option keys, UUIDs, confirmation tokens, and numeric form values retain their original values.

Translations are bundled locally, with gettext catalogs and an English translation template for WordPress translation tools. Language selection does not create an additional database table or send text to an external service.

= Database Discovery =

Tornado inspects tables, columns, indexes, storage engines, and available foreign-key metadata through INFORMATION_SCHEMA. Its inventory considers active and inactive plugins, must-use plugins, drop-ins, themes, WordPress Core tables, and other database tables. Unknown ownership or unreadable dependency metadata is treated conservatively; unfamiliar tables are not automatically considered unused.

= Intelligent Maintenance Engines =

The 2.x architecture includes coordinated components built into the plugin, not separate add-ons or external services.

* **Extension Inventory Engine (ExtensionInventoryEngine):** Inventories installed extensions, themes, Core tables, and database tables, then classifies protected owners, forensic candidates, and unknown tables.
* **Ownership Evidence Engine (OwnershipEvidenceEngine):** Assesses ownership using installed paths, namespaces, table families, runtime signals, and independent witnesses. A name match alone never authorizes deletion.
* **Extension Forensics Engine (ForensicCleanupEngine, ExtensionCleanupService):** Provides forensic inventory and bounded static ZIP inspection for removed-plugin and removed-theme residue. PHP source is inspected without execution.
* **Residue Evidence Service (ResidueEvidenceService):** Correlates historical theme identities, table ownership, private option/meta namespaces, and unregistered content to identify likely legacy residue.
* **Smart Cleanup Orchestration Engine (SmartCleanupService):** Coordinates verified backups, guarded migration, cleanup, extension-residue processing, table checks, uploads scanning, and final audit/compaction under a lock.
* **Uploads Residue Scanner (UploadsResidueScanner):** Checks removed-extension paths and database references, rejects unsafe trees and symlinks, applies size limits, and verifies moved files with SHA-256. Eligible files enter reversible private quarantine with a restore manifest.
* **Adaptive Structured Reference Engine (AdaptiveStructuredReferenceEngine):** Previews and transforms supported Post ID references in extension tables, including semantic ID columns, ID/type pairs, strict lists, and supported JSON or serialized structures. Unresolved references remain blocking.
* **Table Dependency Inspector (TableDependencyInspector):** Checks incoming foreign keys, views, attached triggers, and readable trigger-body references. Incomplete dependency metadata keeps a candidate protected.
* **Database Audit and Compaction Services (DatabaseAuditService, DatabaseCompactionService):** Compare row counts and allocated-size estimates, then optimize eligible tables under engine, size, and free-space rules. Skipped and failed tables are reported separately.
* **Semantic Builder Assignment Engine (BuilderAssignment, BuilderRegistryService):** Uses one policy for builder-reference discovery and repair. Matching numbers alone are not references; prices, stock, quantities, ratings, dimensions, counters, and cache values are excluded unless a supported field path proves an assignment.

= Smart Cleanup and Extension Forensics =

Preview-first cleanup identifies supported WordPress and WooCommerce candidates before deletion. Categories include revisions, auto drafts, trash, autosaves, expired transients, orphaned metadata and relationships, and selected WooCommerce or Action Scheduler records. Candidate ID sets are fingerprinted and revalidated under the cleanup lock. Failed queries or changed candidates stop the affected deletion.

Smart Cleanup coordinates inventory, preview, verified private backup, eligible cleanup, extension-residue analysis, dependency checks, uploads scanning, final compaction, and before/after reporting. Installed extensions, shared data, commerce records, ambiguous ownership, and unresolved dependencies remain protected. Full revision purges, pending editorial revisions, and media-plugin-specific trash are excluded from unattended cleanup.

Extension Forensics investigates residue left by removed plugins and themes. It correlates deletion records, installed-extension inventory, historical theme identities, table namespaces, option/meta keys, row-level ownership evidence, custom post types, taxonomies, WP-Cron, Action Scheduler, theme CSS/templates, and supported plugin registry data. Optional ZIP inspection is static and bounded: PHP is not executed, and archive paths, traversal, and symlinks are checked. A table-name match or inactive status alone never authorizes deletion. Eligible tables require a fresh checksum-verified backup and successful live dependency checks. Automatic residue cleanup is skipped on Multisite when shared ownership is unclear.

= Uploads, Audits, and Backups =

The uploads scanner checks exact paths associated with removed extensions and searches supported database locations for references, including Options, Posts, Post Meta, User Meta, Comment Meta, Term Meta, WooCommerce HPOS order meta, and supported legacy order-item metadata. It rejects unsafe trees and symlinks, applies file and size limits, and verifies moved files with SHA-256. Eligible files are moved to reversible private quarantine with a restore manifest; uploads are not permanently deleted. Referenced, ambiguous, unmatched, and protected business-data paths remain untouched.

Database audits compare table counts, exact row totals where readable, and INFORMATION_SCHEMA estimates for allocated data and index space. Incomplete scans are marked partial and unknown counts are not reported as zero. Allocation figures are estimates, not the full physical database-directory footprint. OPTIMIZE TABLE is limited to eligible tables under engine, size, and free-space rules. Smart Cleanup performs a final eligible compaction pass.

Logical SQL backups are stored locally and verified with SHA-256. The default location is a protected Tornado-owned directory below wp_upload_dir(), with a persisted random storage token and restrictive access controls. Administrators can configure SHCD_TORNADO_DBM_BACKUP_DIR. Backup records include schema and Posts ID fingerprints, consistency status, and storage classification. Full database restore is provided through WP-CLI.

= Revision Archive and ID Maintenance =

The independent revision archive stores supported snapshots in Tornado's typed records store. Depending on policy, it can capture final Elementor editor and metadata saves, deduplicate snapshots, apply per-post retention, and remove eligible orphan snapshots after permanent post deletion. It excludes derived CSS and cache data and does not replace Elementor's complete editor history or a full site backup.

Generic AUTO_INCREMENT normalization does not lower counters. Explicit counter repair can set supported Core and WooCommerce counters to MAX(ID)+1 after a fresh private backup and live verification. It does not change existing row IDs or fill interior gaps, but deleted tail IDs may become reusable.

The optional Post ID Reindex workflow creates a dense 1..N sequence for the active $wpdb->posts table. Mapping priority is pages, posts, products, variations, other content, attachments, then revisions, preserving ascending old-ID order within each group. An immutable Old ID to Temporary ID to Final ID mapping synchronizes registered references in two phases. Execution requires matching Discovery, Mapping, and Backup fingerprints, supported transactional tables, successful Preflight, administrator authorization, and explicit confirmation. Reindexing is disabled by default and is not needed for ordinary cleanup.

= Compatibility, Storage, and Safeguards =

Adaptive reference detection evaluates semantic ID columns, ID/type pairs, strict ID lists, supported JSON or PHP-serialized paths, and explicit foreign keys to the active Posts table. Structured handling covers selected WordPress Core, WooCommerce, Elementor, Gutenberg, and Rank Math relationships. Unsupported, proprietary, remote, encrypted, binary, or ambiguous references are not guessed. The 2.4.1 builder policy excludes unrelated numeric values unless a supported field path establishes a genuine assignment.

After verified legacy migration, Tornado uses three operational tables based on the active prefix: shcd_tornado_jobs for job state, shcd_tornado_mappings for Reindex mappings, and shcd_tornado_records for typed discoveries, backups, logs, reports, and supported revision snapshots. These are three separate tables, not one shcd_tornado table.

Destructive operations use applicable previews, candidate fingerprints, backup verification, capability checks, nonces, one-time authorization, typed confirmation, locks, ownership revalidation, and live dependency checks. Tornado sends no site data to an external service and includes no telemetry. Operational records, backups, and quarantined uploads stay local and may contain sensitive data.

Tornado requires WordPress 7.0 or later and PHP 8.3 or later. Network-wide Multisite Reindexing and WooCommerce HPOS order-ID reindexing are unsupported. Automatic extension-residue cleanup is skipped where Multisite ownership is unclear. IDs stored outside the current WordPress database cannot be discovered reliably. Test Smart Cleanup, table removal, counter repair, and Reindexing on staging before production use.

== Installation ==

1.  Create a full independent backup of the site files and database.
2.  If upgrading from a legacy SHCD Tornado plugin, deactivate the old plugin before running the guarded legacy migration.
3.  Upload the shcd-database-maintenance directory to /wp-content/plugins/, or install the ZIP through Plugins > Add New > Upload Plugin.
4.  Activate Shabnam Tornado Database Maintenance.
5.  Open Tools > Tornado.
6.  Review System Status and run Discovery.
7.  Review the database prefix and the three Tornado operational tables.
8.  Use Preview before any cleanup operation.
9.  Verify that private backup storage is writable and protected.
10. Test Mapping, Backup, Preflight, cleanup, and Reindex workflows on a staging copy before considering production use.

No wp-config.php edit is required for normal operation. An optional emergency constant can disable destructive operations; review the plugin settings and inline administrator guidance before enabling destructive operations.

Do not uninstall the previous release before upgrading. Install the new release over the existing plugin directory and allow the guarded migration process to run. Keep an independent backup until migration and post-upgrade verification have completed.

= System Requirements =

* WordPress 7.0 or later.
* PHP 8.3 or later.
* A MySQL-compatible database that provides the required INFORMATION_SCHEMA metadata.
* InnoDB for every base table in the active database when creating a backup that will be accepted for Reindex.
* Sufficient database privileges for the selected operation. Discovery and cleanup require fewer privileges than backup, table removal, restore, or Reindex.
* Enough disk space for a complete logical database backup and any temporary files required by the selected operation.
* A private writable backup location for backup-dependent destructive operations.

= Upgrade Notes for Version 2.4.2 =

**Upgrading to 2.4.2**
* Dashboard, archive, and administrative list reads use authenticated same-origin admin AJAX. Explicit refresh bypasses the bounded read cache.
* A failed or incomplete refresh preserves the last valid statistics and identifies the affected section.
* The release preserves the three-table operational data architecture.
* The active database prefix is applied to the tornado_jobs, tornado_mappings, and tornado_records table suffixes.
* For an active prefix of shcd_, the table names are shcd_tornado_jobs, shcd_tornado_mappings, and shcd_tornado_records.
* The release does not replace those three tables with one table named shcd_tornado.
* The 2.4.1 builder-reference policy is more conservative. Review any custom builder assignments that rely on non-standard fields.
* Take an independent backup before running Smart Cleanup, explicit counter repair, table removal, or Reindex.
* Test all destructive operations on a staging copy first.

= WP-CLI Commands =

Tornado registers commands under wp shcd-tornado-dbm when WP-CLI is available. Examples include:

* wp shcd-tornado-dbm discover
* wp shcd-tornado-dbm mapping build
* wp shcd-tornado-dbm dry-run
* wp shcd-tornado-dbm backup create
* wp shcd-tornado-dbm integrity check
* wp shcd-tornado-dbm cleanup preview
* wp shcd-tornado-dbm cleanup execute --yes
* wp shcd-tornado-dbm tables scan-unused
* wp shcd-tornado-dbm reindex prepare
* wp shcd-tornado-dbm reindex preflight

Destructive WP-CLI commands require their documented confirmation arguments. Use wp help shcd-tornado-dbm for the commands available in the installed version.

== Frequently Asked Questions ==

= Does Tornado automatically renumber my WordPress posts? =

No. Post ID Reindexing is disabled by default and requires a separate, explicit workflow with Discovery, Mapping, Backup, Preflight, authorization, and typed confirmation.

= Do I need Reindexing to clean the database? =

No. Cleanup, revision retention, orphan checks, backup, integrity reporting, table compaction, and AUTO_INCREMENT maintenance can be used without changing existing Post IDs.

= Which internal database tables does Tornado create? =

Tornado uses exactly three dedicated operational tables after verified legacy migration: the active prefix followed by tornado_jobs, tornado_mappings, and tornado_records. With the shcd_ prefix, the names are shcd_tornado_jobs, shcd_tornado_mappings, and shcd_tornado_records. These are three separate tables, not one shcd_tornado table.

= Does Tornado support a custom database prefix? =

Yes. Core table names are read from $wpdb, and plugin tables are resolved from the active $wpdb->prefix. The plugin does not hard-code wp_posts.

= What is the difference between AUTO_INCREMENT repair and Post ID Reindexing? =

AUTO_INCREMENT repair changes the next generated value. It does not change the primary keys of existing records. Depending on the selected repair workflow, the next value may be set to MAX(ID)+1, which can make deleted tail IDs available for reuse.

Post ID Reindexing changes existing IDs and synchronizes registered references using the two-phase mapping workflow. It is a separate, more extensive operation.

= Does ordinary counter normalization lower AUTO_INCREMENT values? =

Generic counter normalization is non-decreasing and does not lower counters. The explicit advanced counter-repair workflow is separate and can set supported counters to MAX(ID)+1 after backup and live verification. Review the operation’s warning because deleted tail IDs may be reused.

= How does adaptive detection handle an unknown plugin table? =

It evaluates schema and data evidence before registering a relationship. Clear conventional references can be included in Preflight and the two-phase mapping. Ambiguous data remains blocked instead of being rewritten by guesswork.

= Does the plugin support Rank Math? =

The plugin includes a dedicated Rank Math adapter for supported internal-link, internal-meta, and analytics object relationships. The adapter is conditional and only acts on tables and columns that exist in the current installation.

= Does the plugin support Elementor? =

It includes structured Elementor reference handling, selected builder-registry support, revision snapshots under the configured archive policy, and post-operation CSS or cache rebuilding. Elementor and third-party widget data can vary, so unresolved proprietary paths remain protected.

= Can Tornado detect IDs stored outside WordPress? =

No. Remote services, custom applications, external databases, exported files, and copied IDs outside the current WordPress database must be audited separately.

= Are backups sent to another server? =

No. Backups are created locally. The default location is a protected, randomized Tornado directory below the WordPress uploads base directory returned by wp_upload_dir(). Administrators remain responsible for server permissions, off-site backups, encryption, retention, and restore testing.

= Does the uploads scanner permanently delete files? =

No. Eligible files are moved into a protected, reversible quarantine location and recorded in a restore manifest. Ambiguous, referenced, unsafe, or business-data paths are preserved.

= Does Smart Cleanup delete every discovered extension table? =

No. A table must have sufficient ownership evidence, verified backup coverage, and no blocking live dependencies. Installed extensions, shared data, uncertain ownership, and protected business records are not automatically removed.

= Is Multisite supported? =

The plugin can inspect the active site’s tables, but network-wide Multisite Reindexing is intentionally not supported. Automatic deleted-extension residue cleanup is skipped where shared ownership cannot be safely established.

= What happens when Preflight finds an unresolved reference? =

Reindex remains blocked. Review the table and column, choose an explicit supported policy, register a site-specific adapter, or leave the operation unexecuted.

= What happens when I uninstall the plugin? =

Scheduled hooks and Tornado capabilities are removed. By default, operational tables and backup files are retained to avoid accidental data loss. They are deleted only when the relevant uninstall settings were enabled before uninstalling.

= What are the main features of Shabnam Tornado Database Maintenance? =

* Database schema discovery through INFORMATION_SCHEMA, including tables, columns, indexes, storage engines, and foreign-key metadata.
* Preview-first cleanup for supported WordPress and WooCommerce records, orphaned data, expired transients, revisions, auto drafts, trash, autosaves, and other configured categories.
* One-click Smart Cleanup orchestration for inventory, preview, verified backup, eligible cleanup, extension-residue analysis, uploads scanning, compaction, and final reporting.
* Deleted-plugin and deleted-theme forensic discovery using removal records, table families, option/meta namespaces, source evidence, and row-level ownership witnesses.
* Uploads residue scanning with database-reference checks, safe-path validation, SHA-256 verification, private quarantine, and a restore manifest.
* Whole-database before-and-after auditing with exact row counts and allocated data/index size estimates.
* Live table-dependency inspection for incoming foreign keys, views, triggers, and related table references.
* Logical SQL backups with SHA-256 file verification, schema fingerprints, Posts ID fingerprints, consistency reporting, and protected local storage.
* A dedicated three-table operational data architecture for jobs, ID mappings, and typed records.
* Independent revision snapshots stored in the typed records store according to the configured archive policy, including supported final Elementor editor and metadata saves.
* Controlled, collision-resistant, two-phase Post ID reindexing with immutable Old ID to Temporary ID to Final ID mappings.
* Conservative adaptive discovery of plugin references, plus structured handling for selected WordPress, WooCommerce, Elementor, Gutenberg, and Rank Math relationships.
* Semantic builder-assignment detection that avoids treating unrelated numeric values such as prices, stock, quantities, ratings, dimensions, and counters as content references.
* Explicit advanced AUTO_INCREMENT repair for supported Core and WooCommerce tables, with backup and live verification. This operation does not renumber existing rows, but can make deleted tail IDs available for reuse.
* Audit logs, operation reports, bounded administrative list caching, retention controls, and WP-CLI commands.
* No external telemetry or usage tracking. Site data and backup files remain on the site’s own storage.
* Intelligent maintenance engines for Extension Inventory and Forensics, ownership evidence, Smart Cleanup, uploads scanning, adaptive references, dependency inspection, database auditing and compaction, and semantic builder assignments.

= Which internal database tables does Tornado use? =

Tornado uses exactly three dedicated internal operational tables after the verified legacy-store migration:

* tornado_jobs - stores maintenance job and execution-state data.
* tornado_mappings - stores the immutable records used by the Post ID mapping and reindex workflow.
* tornado_records - stores indexed typed operational records, including discoveries, backup records, logs, operation reports, and supported revision archives.

Each table name is formed by appending its suffix to the active WordPress database prefix. For a site whose active prefix is shcd_, the three table names are:

* shcd_tornado_jobs
* shcd_tornado_mappings
* shcd_tornado_records

These are three separate tables. The plugin does not use a single table named shcd_tornado.

The plugin does not store its operational jobs, mappings, and typed records in WordPress posts or post meta. The typed records table consolidates record types that were stored in separate legacy metadata tables in earlier releases. Jobs and mappings remain in their own dedicated tables.

Legacy-store migration is guarded. Before legacy tables are removed, Tornado requires a fresh verified backup covering the source data, locks the relevant internal tables, copies the legacy rows, and compares the copied data. Source tables are dropped only after successful verification. If migration or verification fails, the source data is retained.

The 2.4.0 release shortened the internal table names while retaining the three-table architecture and the independent Elementor revision history. The migration does not overwrite an existing destination table.

Tornado does not create new database quarantine tables. Eligible unused or deleted-extension tables can be dropped only after verified backup coverage and live dependency checks. Existing legacy quarantine tables are still inspected and included in the applicable Smart Cleanup workflow.

= How do database discovery and integrity checks work? =

Tornado discovers the active database schema using the current WordPress database connection and the available INFORMATION_SCHEMA metadata.

Discovery can inspect:

* Base tables and table names.
* Columns and column data types.
* Primary keys and indexes.
* Storage engines.
* Foreign-key relationships.
* Table ownership candidates and extension-specific namespaces.
* Supported WordPress and plugin relationships.
* Table statistics used by cleanup and audit reports.

Discovery is prefix-aware. Core table references are resolved from the active $wpdb table names and plugin-owned tables use the active $wpdb->prefix. The plugin does not assume that the site uses wp_posts, wp_options, or another default-prefix table name.

When metadata cannot be read, the plugin must not interpret the missing information as proof that a table is safe to modify. Unreadable or incomplete dependency information is treated conservatively and is reported as unresolved or protected.

= Which cleanup and revision-management operations are supported? =

Tornado provides preview-first cleanup. A preview identifies the selected cleanup categories and the candidate records before deletion. Cleanup runs in bounded batches and revalidates the candidate set before destructive work.

Supported cleanup categories include:

* All revisions or revisions beyond the configured retention limit.
* Auto drafts, trash, autosaves, and optionally aged pending revisions.
* Orphaned post meta.
* Orphaned comments and comment meta.
* Orphaned user meta and term meta.
* Orphaned term relationships.
* Supported WooCommerce orphaned lookup, order-item, permission, and related records.
* Expired transients and supported expired timeout records.
* Stale local media rows covered by the plugin’s explicit media policies.
* Selected Action Scheduler orphan logs and eligible old claims.
* Other supported categories exposed by the installed release and its cleanup policy.

The exact available categories depend on the installed WordPress and plugin schema. Tornado rechecks parent relationships before deleting supported orphan records. If a verification query fails, the affected deletion is stopped rather than assuming the record is orphaned.

Preview First uses candidate counts and SHA-256 fingerprints of the candidate ID sets. The execution stage validates the fingerprints while holding the cleanup lock. This reduces the risk of deleting a different set of records after the preview was generated.

Generic values and ambiguous serialized references are not treated as safe cleanup candidates solely because their names look familiar. High-risk generic keys remain manual-review items and are not preselected.

Full revision purges, pending editorial revisions, and media-plugin-specific trash are excluded from unattended Smart Cleanup. Where supported, they remain available through advanced manual tools.

= What does the Smart Cleanup workflow do? =

Smart Cleanup provides one primary administrative workflow for the supported maintenance phases.

Depending on the site’s configuration and available evidence, the workflow can include:

1.  Inventory and discovery of the current database and installed extensions.
2.  Internal cleanup preview and candidate validation.
3.  Creation and verification of a private SQL backup.
4.  General cleanup of selected supported records.
5.  Deleted-plugin and deleted-theme residue analysis.
6.  High-confidence table dependency and ownership checks.
7.  Uploads residue scanning and reversible file quarantine.
8.  Final eligible-table compaction.
9.  Whole-database before-and-after audit and operation reporting.

The workflow uses an orchestration lock so incompatible destructive maintenance operations do not run concurrently. Backup, baseline-audit, dependency, and Multisite safeguards fail closed when their required checks cannot be completed.

Sub-services defer their own compaction during Smart Cleanup. The orchestrator performs one final eligible-table optimization pass after the cleanup phases.

The default cleanup interface is designed around one primary Smart Cleanup action. Specialist controls, manual cleanup categories, and recovery tools are grouped under Advanced Tools where applicable.

Smart Cleanup does not mean that every discovered object is automatically deleted. Ambiguous, shared, installed-extension, business, and otherwise protected data is excluded from destructive actions.

= How does Extension Forensics identify deleted-plugin and deleted-theme residue? =

Tornado includes forensic discovery for database residue left by removed plugins and themes.

The discovery process can use:

* WordPress plugin and theme deletion records.
* Active and inactive installed plugins.
* Must-use plugins and drop-ins.
* Installed and historical theme identities.
* Custom table names and table-family patterns.
* Option and metadata namespaces.
* Independent row-level ownership evidence.
* Custom post types and taxonomies.
* WP-Cron and Action Scheduler hooks.
* Theme custom CSS, templates, and saved theme content.
* Plugin registry and other supported WordPress records.
* Optional static source inspection of a plugin or theme ZIP archive.

ZIP source inspection is static and bounded. It does not execute code. Archive size, PHP parsing, paths, symlinks, and path traversal are checked before source evidence is accepted.

Tornado uses multiple evidence sources rather than assuming that a table belongs to a deleted plugin because its name resembles a slug. Generic option/meta keys and ambiguous value references require independent ownership evidence or administrator review.

Installed inactive plugins and themes remain protected. WordPress Core tables, ordinary posts/pages/media, commerce content, and data that may be shared with another installed extension are also protected.

A fresh checksum-verified private backup must cover target tables before their removal. Live dependency checks are performed before a table is dropped. Tornado does not disable foreign-key protections to force a deletion.

Eligible high-confidence deleted-extension tables can be dropped after backup and dependency verification. Inferred or ambiguous ownership does not authorize automatic permanent deletion. Generic serialized/value references, extension-named columns, and non-core text matches can remain read-only review findings.

WordPress does not provide a universal ownership registry for every deleted extension. Unknown proprietary data must remain protected unless sufficient evidence or a dedicated adapter is available.

Automatic deleted-extension residue cleanup is skipped on Multisite where shared ownership cannot be safely established.

= How does the uploads residue scanner work? =

The uploads residue scanner checks exact top-level paths that are associated with extensions recorded as removed or supported by high-confidence database table-owner evidence.

The scanner:

* Excludes currently installed plugins, including inactive plugins, must-use plugins, drop-ins, and installed themes.
* Checks database references in Options, Posts, Post Meta, User Meta, Comment Meta, Term Meta, WooCommerce HPOS order meta, and supported legacy order-item meta.
* Preserves paths that remain referenced by database records.
* Rejects symbolic links and unsafe directory trees.
* Applies bounded file-count and file-size checks.
* Verifies moved files using SHA-256.
* Moves eligible files into a protected, reversible quarantine location beside the verified private SQL backup.
* Stores a restore manifest and reports candidate paths, quarantined paths, file counts, bytes moved, skipped references, unsafe paths, and failures.

The scanner does not permanently delete uploads. It moves only high-confidence exact-slug top-level directories or exact plugin-basename files for extensions recorded as removed or supported by sufficient ownership evidence.

WooCommerce download/invoice data and other known business-data directories are protected. Unmatched or ambiguous uploads remain untouched. Quarantine is skipped if Tornado cannot verify a private writable location outside known public web roots.

= What does the database before-and-after audit report? =

The database audit compares the database before and after supported manual cleanup operations.

The audit can report:

* Exact COUNT(*) row totals for each readable base table.
* INFORMATION_SCHEMA data and index allocation estimates.
* Table-count changes.
* Net row-count changes.
* Allocated-size changes and estimated space saved.
* Per-table changes.
* Optimized, skipped, and failed tables.
* The largest remaining tables.

The baseline audit must complete before destructive manual cleanup starts. If one or more tables cannot be counted, the final audit is marked partial. Unknown counts are not converted to zero.

A confirmed dropped table is reported with zero rows after deletion, including a table that was already empty. A table that could not be scanned remains unknown rather than being reported as zero.

INFORMATION_SCHEMA size totals are estimates of allocated table data and indexes. They are not the complete MySQL data-directory footprint. Concurrent site writes can affect before-and-after net differences.

The whole-database audit is used for manual Preview First cleanup and deleted-extension cleanup. The expensive audit is skipped for background WP-Cron and WP-CLI cleanup.

= How are table dependencies checked before a table is removed? =

Before eligible table removal, Tornado checks live database dependencies.

The checks include:

* Incoming foreign keys from other tables.
* Foreign keys that reference the candidate table.
* Views and readable view definitions.
* Triggers attached to candidate tables.
* Trigger-body references where readable.
* Other supported table-family and installed-owner evidence.

Self-referencing foreign keys are not treated as external blockers. Unreadable metadata, unresolved dependencies, circular dependencies, and external dependencies remain protected and are reported.

Where deleted-extension tables have a parent/child relationship, Tornado processes recorded child tables before retrying eligible parents. It never disables foreign-key checks or removes a real dependency to force the operation.

The dependency checks are shared by Smart Cleanup and the applicable manual table-removal or legacy-quarantine recovery paths.

= How does database compaction work? =

After eligible cleanup, Tornado can run OPTIMIZE TABLE on supported tables.

Compaction is limited by the configured eligibility rules, including engine support, verified table changes, free-space estimates, and table-size bounds. The 1.0.7 workflow targeted verified changed tables and tables reporting at least 1 MiB or 5 percent free space, while tables larger than 256 MiB and unsupported engines were reported as skipped.

Smart Cleanup defers sub-service compaction and performs one final eligible-table optimization pass after its cleanup phases.

Compaction is not a substitute for a backup. It may require additional database resources and can take time on large tables. Unsupported or failed operations are reported instead of being described as successful.

= How does AUTO_INCREMENT maintenance work? =

Tornado distinguishes between ordinary counter normalization, cleanup-triggered counter repair, explicit advanced counter repair, and Post ID reindexing.

Ordinary generic AUTO_INCREMENT normalization does not lower counters and does not reuse deleted IDs.

Cleanup-triggered counter repair can recalculate an affected table’s counter to MAX(primary_key)+1 after a verified row-count reduction, subject to the cleanup policy and live checks. Earlier releases deliberately skipped this behavior for incomplete cleanup, no-op cleanup, scheduled cleanup, and WP-CLI cleanup.

The explicit advanced counter-repair workflow introduced in the 2.4.0 development line can inspect supported WordPress Core and WooCommerce order counters and repair them to MAX(ID)+1 even when no general-cleanup rows were deleted. It uses a fresh private backup and live verification. This operation does not renumber existing records, but deleted tail IDs may become available for reuse.

Version 2.4.2 preserves the AUTO_INCREMENT and Post ID mapping algorithms from 2.4.0 and 2.4.1.

Counter repair does not fill interior ID gaps. It changes the next generated value; it does not rewrite the primary keys of existing records. Counter repair and Post ID reindexing are separate operations.

= How does controlled Post ID reindexing work? =

The optional reindex workflow creates a dense 1..N sequence for rows in the active $wpdb->posts table. It is an advanced destructive operation and is disabled by default.

The final mapping prioritizes content types in this order:

1.  Pages.
2.  Posts.
3.  Products.
4.  Product variations.
5.  Other content types.
6.  Attachments.
7.  Revisions.

Rows within each content-type group preserve ascending old-ID order. A content-type change during mapping construction aborts the mapping. Mappings built under an obsolete ordering policy are not reused.

Tornado uses a collision-resistant two-phase mapping:

1.  Build an immutable Old ID to Temporary ID to Final ID mapping from the current Posts table.
2.  Move registered references from Old IDs to Temporary IDs.
3.  Move the Posts primary keys from Old IDs to Temporary IDs.
4.  Move registered references from Temporary IDs to Final IDs.
5.  Move the Posts primary keys from Temporary IDs to Final IDs.
6.  Verify reference parity, row counts, sequence boundaries, zero gaps, and the final AUTO_INCREMENT value.

The Posts table is the source of truth for the mapping. Adapters synchronize references; they do not independently choose or renumber the Posts primary-key sequence.

Reindex execution requires matching Discovery, Mapping, and Backup fingerprints. It also requires supported transactional tables, successful Preflight checks, administrator capabilities, a REST nonce, a session-bound one-time authorization token, and an explicit confirmation phrase.

Blocking failures before commit cause the operation to stop or roll back. If an unresolved reference remains, Reindex is blocked until the reference is reviewed, an explicit supported policy is selected, or a site-specific adapter is registered.

Reindexing changes existing WordPress content IDs and registered references. It is not necessary for database cleanup, revision retention, orphan cleanup, backup, integrity reporting, or ordinary AUTO_INCREMENT maintenance.

= How does adaptive plugin-reference detection work? =

Tornado includes dedicated reference handling for known relationships and a conservative adaptive detector for conventional plugin tables.

The adaptive detector can evaluate:

* Integer columns with semantic names such as post_id, page_id, product_id, or attachment_id.
* Polymorphic pairs such as object_id with object_type, or element_id with element_type.
* Strictly formatted ID lists in semantically named columns.
* Supported JSON and PHP-serialized paths that clearly represent WordPress object IDs.
* Explicit foreign keys that reference the active Posts table.

Detection is evidence-based. The plugin checks column type, naming, mapping intersection, row resolution, table scope, and compatible WordPress post types.

Ambiguous, encrypted, compressed, binary, proprietary, remotely stored, or free-text references are not guessed. They remain blocking until an administrator selects an explicit policy or a dedicated adapter is provided.

The 2.4.1 builder-assignment policy applies the same semantic rules to discovery and actual repair. A numeric value that happens to match a content ID is not sufficient evidence that it is a builder reference.

The detector excludes unrelated values such as prices, stock values, quantities, counters, ratings, dimensions, derived cache values, commerce records, and font records unless a supported semantic field path establishes a genuine assignment.

For supported builder assignments, Tornado rewrites only genuine nested builder-ID paths, preserves scalar types and JSON/PHP-serialized formats, and rechecks the destination content type before each registered-assignment rewrite.

= Which plugins and builders have structured compatibility? =

Tornado includes dedicated or structured handling for selected relationships in:

* WordPress Core.
* WooCommerce.
* Elementor.
* Gutenberg.
* Rank Math.
* Selected builder, media, and cache integrations.

The plugin exposes an adapter registration hook for site-specific integrations.

Compatibility does not mean that every extension or external system can be detected automatically. IDs copied to a CRM, ERP, payment gateway, search service, mobile application, custom API, arbitrary HTML, shortcode, URL, or remote database may remain outside WordPress and must be reviewed separately.

Elementor and third-party widget data can vary between installations and versions. Unresolved proprietary paths remain protected rather than being rewritten by guesswork.

= How does the independent revision archive work? =

Tornado supports an independent revision archive in its typed records store. The archive can preserve selected snapshots according to the configured archive policy rather than relying exclusively on ordinary WordPress revision rows.

Supported archive behavior includes:

* Capture of supported final Elementor editor and metadata saves.
* Snapshot deduplication.
* Per-post retention.
* Orphan discovery and cleanup after permanent post deletion.
* Retention independent of ordinary WordPress revision rows.

The archive does not store derived CSS or cache data. It does not replace Elementor’s complete editor history, a complete site backup, or an independently tested recovery plan.

The archive policy can be disabled. The explicit Off setting is preserved during upgrades.

= How are database backups and recovery handled? =

Tornado creates local logical SQL backups and verifies the resulting file with SHA-256.

By default, backup files are stored below the directory returned by wp_upload_dir() in a Tornado-owned directory with a persisted random storage token, restrictive file permissions, and Apache/IIS deny files.

A site administrator may explicitly provide SHCD_TORNADO_DBM_BACKUP_DIR for a custom storage location.

A backup records relevant verification information, including:

* The Posts ID fingerprint.
* The database schema fingerprint.
* Backup consistency status.
* Storage classification.
* File checksum and verification result.

A backup is accepted for Reindex only when the required snapshot and protected-storage checks pass. Mixed storage engines or an insufficiently protected custom backup location can produce warnings or prevent the backup from being accepted for Reindex.

Full database restore is intentionally available through WP-CLI rather than a browser request. This reduces the risk of HTTP timeouts or connection loss during a large import.

The ordinary backup retention policy keeps three backups. Operation reports and log rows have bounded retention, with twenty reports and twenty log rows retained under the documented policy. Active Reindex recovery pins are preserved.

Registered backup files under historical private storage roots can be removed without generating a new storage token. Tornado verifies whether a file was actually removed; failed registrations remain available for retry and are reported.

A local SQL backup may contain the complete database and must be treated as sensitive data. Administrators remain responsible for independent off-site backups, encryption, server permissions, retention, and restore testing.

= Which safeguards protect destructive operations? =

Tornado uses authenticated WordPress administrative requests and capability checks for its maintenance operations.

Destructive workflows use applicable protections such as:

* Internal preview and candidate-set verification.
* SHA-256 fingerprints for selected candidate sets.
* Fresh private backup verification.
* Administrator capability checks.
* REST nonces or authenticated admin AJAX nonces.
* Session-bound, one-time authorization where required.
* Typed confirmation for high-risk operations.
* Advisory or orchestration locks to prevent conflicting destructive work.
* Live revalidation of ownership and table dependencies.
* Fail-closed behavior when required queries or metadata checks fail.
* Explicit reporting of skipped, deferred, protected, and failed items.

The 2.2.2 release binds a preview to its own random token, administrator, and login session. The plugin verifies transient persistence before returning a successful preview. A selection change or expired preview invalidates the authorization for that selection.

Unknown execution results are not automatically retried. This avoids repeating a destructive action when the client cannot determine whether the server completed it.

A global destructive-operation Emergency Stop is honored by the applicable cleanup workflows.

= What are the important limitations? =

* Network-wide Multisite Reindexing is not supported.
* Automatic deleted-extension residue cleanup is skipped on Multisite when shared ownership cannot be safely established.
* WooCommerce HPOS order-ID reindexing is not supported.
* Legacy WooCommerce order IDs are not reindexed unless the related advanced option is explicitly enabled.
* Unknown proprietary data is not rewritten without sufficient evidence or a dedicated adapter.
* Remote systems and copied IDs outside the WordPress database cannot be discovered reliably.
* Some database engines or storage configurations may not support all backup, transaction, or compaction operations.
* Reindex requires supported transactional tables and successful Preflight checks.
* A successful local backup is not a substitute for an independently tested hosting or infrastructure backup.
* Exact row counts and whole-database audits can take time on large databases.
* Database allocation estimates do not represent the complete physical data-directory footprint.

= Does Tornado send site data to an external service? =

Tornado does not send site data to an external service and does not include usage tracking or telemetry. Administration requests are made to the site’s own WordPress installation.

The plugin stores operational data locally, including settings, discoveries, mappings, backup records, jobs, logs, revision archives, and short-lived authorization data.

SQL backup files may contain the complete database and must be treated as sensitive data. Uploads quarantine files may also contain private site content and must be protected accordingly.

Uninstall removes scheduled events and plugin capabilities. Operational tables and backup files are removed only when the corresponding uninstall options are enabled by an administrator. By default, operational data and backups are retained to avoid accidental data loss.

== Changelog ==

= 2.4.2 =

* Add English and Arabic administration translations alongside Persian. Select the catalog from the current WordPress user's administration locale, including when it differs from the site or REST-request locale. Fall back to English for other locales.
* Translate administration forms, navigation, cleanup categories, report labels, execution states, optimization reasons, audit notes, confirmation prompts, and supported error and log messages. Clarify deleted-row totals versus net database row changes.
* Add local JSON fallbacks, canonical English gettext messages, Persian and Arabic PO/MO catalogs, and a POT template for WordPress translation tools. Do not add a language option, database table, external translation request, or front-end language switcher.
* Support left-to-right English and right-to-left Persian/Arabic layouts, including logical spacing, notice borders, switches, and locale-aware displayed numbers and refresh times. Preserve stored numeric values, content titles, table names, keys, UUIDs, and confirmation tokens.
* Route revision archive list and status reads through the authenticated admin AJAX bridge, completing the same transport for all nine initial administration reads. Preserve the existing REST routes and original capability requirements.
* Resolve administration requests against the current browser origin while preserving WordPress subdirectory paths, avoiding mixed-origin or mixed-protocol requests caused by configured site URLs behind a proxy.
* Give read requests a bounded timeout and identify the failed section when connection or response reading fails. Preserve previous statistics and form values rather than displaying false zeros or blank settings.
* Validate dashboard counts, next-ID values, version fields, and archive list shapes before rendering. Explicit refresh reads fresh statistics, records the last successful refresh time, and clears a previous error after a successful retry initiated by the administrator.
* Reject nonscalar archive filters, bound archive list limits, and preserve nonce, capability, and read-only route restrictions. Treat failed archive list/count queries as errors rather than successful empty lists or zero counts.
* Report an interrupted write as an unknown outcome and do not automatically retry it. Keep cleanup, backup, and reindex mutation authorization and verification requirements in place.
* Preserve the AUTO_INCREMENT, Post ID mapping, semantic builder-assignment, retention, and three-table storage algorithms from 2.4.1.

= 2.4.1 =

* Introduce a shared semantic builder-assignment policy used by automatic discovery, registered-reference validation, and actual builder repair. A number matching a content ID alone is no longer sufficient evidence of a reference.
* Exclude prices, stock values, quantities, counters, ratings, and dimensions from automatic builder-reference inference unless a supported semantic field path establishes a genuine assignment.
* Exclude derived CSS/cache values, commerce records, and font records from automatic builder discovery. Numeric overlap in unrelated data cannot authorize a rewrite.
* Rewrite supported nested header, footer, template, layout, and related builder-ID paths without recursively replacing every matching number in a container.
* Preserve unrelated numeric siblings even when their values equal the source content ID. Keep ID arrays and scalar assignment fields subject to their supported path rules.
* Preserve integer versus string scalar types during reference repair and retain the original JSON or PHP-serialized storage format.
* Recheck the destination content type before rewriting a registered assignment. Reject unsupported or mismatched target types instead of assigning an unrelated post.
* Rebuild legacy automatic builder results once under the new semantic policy. Remove stale automatic entries while retaining administrator removal decisions.
* Preserve manual overrides per field. Editing one builder property no longer promotes all automatically discovered properties to manual authority.
* Track manually added option and meta keys individually. Adding one manual key does not authorize rewriting unrelated automatic containers or their numeric values.
* Keep unregistered content types from deleted themes disabled by default. A header-like name or Elementor data alone cannot enable automatic builder repair.
* Invalidate cached builder discovery after content deletion so removed documents no longer remain trusted automatic candidates.
* Preserve the previous builder registry when database scanning fails or returns incomplete evidence, rather than overwriting it with an apparently empty result.
* Cache a valid empty discovery result and distinguish it from a failed scan, avoiding repeated full discovery on routine administration reads.
* Report confirmed dropped tables as zero rows after deletion, including tables that were already empty. Include empty dropped tables in the before/after table-change report.
* Keep row counts unknown when a before/after database scan is incomplete. Do not convert unreadable or uncounted tables to confirmed zero-row results.
* Keep exact row-count deltas distinct from allocated-size estimates and account for dependent-row deletion and operation-record writes when explaining net changes.
* Preserve the AUTO_INCREMENT and Post ID mapping algorithms introduced in 2.4.0, including content-type ordering. Keep the three-table operational store and independent Elementor revision archive unchanged.

= 2.4.0 =

* Fix log deletion when selected IDs have already rotated out. Make repeated deletions idempotent and preserve record-kind boundaries.
* Delete registered backup files under historical private storage roots without generating a new storage token. Verify that files were actually removed; retain failed backup registrations for a later retry and report the reason.
* Display one-based list ordinals for backups, reports, and revision archives while preserving stable UUIDs and internal record keys.
* Prioritize content types in new Post ID mappings in this order: pages, posts, products, product variations, other content types, attachments, and revisions. Preserve ascending old-ID order within each group.
* Reject reuse of mappings created under an obsolete ordering policy and abort when a content type changes during mapping construction.
* Add automatic, evidence-based theme and plugin residue cleanup and exact counter repair to the advanced cleanup workflow. Remove the former manual slug, ZIP, and separate authorization interface.
* Repair repeated dbm_ option-name corruption. Recover settings and backup-storage identity from legacy names without overwriting current valid values or changing names on repeated runs.
* Shorten the internal table names atomically while retaining the three-table architecture and independent Elementor revision history. Do not overwrite an existing destination table during migration.
* Add an independent Elementor revision archive in the typed records store. Capture supported final editor and metadata saves, deduplicate snapshots, and apply per-post retention without creating a fourth operational table. Do not archive derived CSS or cache data. Preserve the explicit Off setting.
* Delete orphaned expired-transient timeout records and count only successful deletions. Prevent repeated candidates from being counted more than once and preserve unexpired or permanent transient data.
* Add live counter statistics and explicit MAX(ID)+1 repair even when no general-cleanup rows were deleted. Verify the counter again after ALTER TABLE. Do not change existing row IDs or interior ID gaps during counter repair.
* Keep the three dedicated operational tables named with the active WordPress table prefix: tornado_jobs, tornado_mappings, and tornado_records. Migrate legacy stores only after backup, transfer, and data verification.
* Preserve the existing Reindex recovery state, private uploads-residue quarantine, bounded administrative list cache, explicit refresh behavior, and retention policy.

= 2.3.0 =

* Merge internal preview and manual cleanup into one authenticated request with request-local proof, exact candidate checks, and no dependency on persisted preview tokens.
* Consolidate discoveries, backups, logs, and revision archives into an indexed typed records table. Keep jobs and mappings in their dedicated tables.
* Before removing legacy metadata tables, create a fresh verified backup covering each source, lock the internal tables, copy every legacy row, and byte-compare the copied data. Drop source tables only after successful verification; preserve the source when migration fails.
* Drop eligible unused and deleted-extension tables directly after verified backup coverage and live dependency checks. Disable creation of new database quarantine tables while continuing to inspect existing legacy quarantine tables.
* Rotate ordinary backups to three and operation reports/logs to twenty, preserving active Reindex recovery state.
* Correct dashboard and settings transports, independent initialization, defaults, explicit refresh, and history refresh.
* Keep AUTO_INCREMENT and ID-remapping algorithms unchanged; only discovery metadata readers move to the typed records store.

= 2.2.2 =

* Localize Smart Cleanup headings, explanatory text, all 28 general-cleanup category labels, related controls, and preview status in Persian.
* Route the manual cleanup form through authenticated WordPress admin AJAX using the same cleanup service, capability checks, per-page nonce, and preview verification. Keep the existing REST endpoints available.
* Add strict preview and execution response validation. Empty objects, invalid JSON, HTML errors, missing tokens, and inconsistent totals are no longer treated as successful previews.
* Recover complete valid AJAX response envelopes when stray PHP notices appear before the response.
* Bind each preview to its own random token, administrator, and login session. Verify transient persistence before returning a successful preview so other tabs and rejected requests do not erase a valid preview.
* Enable deletion only after a valid preview for the current selection. Display Persian per-category counts, lock controls during processing, and invalidate the preview after selection changes or expiration.
* Do not automatically retry unknown execution results.
* Preserve candidate fingerprints, single-use tokens, existing cleanup execution logic, AUTO_INCREMENT behavior, identifier mapping, Reindexing, and earlier table-cleanup fixes.

= 2.2.1 =

* Replace the hard dependency on INFORMATION_SCHEMA.VIEW_TABLE_USAGE with portable live view discovery and SHOW CREATE VIEW checks. Servers without VIEW_TABLE_USAGE no longer retain every candidate table for that reason.
* Keep unreadable dependency metadata protected and report the actual error.
* Unify dependency checks for Smart Cleanup, manual extension-table deletion, table quarantine, and quarantine purge.
* Check incoming foreign keys from other databases, attached triggers, trigger-body references, and readable view definitions. Do not treat self-referencing foreign keys as external blockers.
* Process recorded deleted-extension child tables before retrying foreign-key parents. Never disable actual dependencies; keep circular or external dependencies protected and identify them in reports.
* Preserve request-local table-family ownership evidence while sibling tables are quarantined, then recheck live installed owners and dependencies before every mutation.
* Recognize legacy PascalCase and underscore table families only when independent option/meta namespace evidence exists and no installed owner is found. Inferred ownership permits reversible quarantine, not automatic permanent deletion.
* Protect installed Elementor Pro submissions and notes, TeraWallet/woo-wallet aliases, and other WordPress table families sharing the database, including cases where a deleted-extension record overlaps another prefix.
* Add Persian outcomes and concrete reasons for candidate tables, original names for permanently dropped tables, and exact dedicated-table row counts. Limit each run to 100 tables and report deferred outcomes explicitly.
* Keep AUTO_INCREMENT logic, identifier transformation, and Reindexing unchanged.

= 2.2.0 =

* Add an uploads residue scanner to Smart Cleanup.
* Check exact top-level uploads paths for plugins or themes explicitly recorded as removed by WordPress or supported by high-confidence database table-owner evidence.
* Exclude all currently installed plugins, must-use plugins, drop-ins, and themes.
* Check database references across Options, Posts, Post Meta, User Meta, Comment Meta, Term Meta, WooCommerce HPOS order meta, and legacy order-item meta. Preserve paths still referenced by database records.
* Reject symlinks and unsafe directory trees. Apply bounded file-count and size checks, then verify moved files with SHA-256.
* Move eligible files into a protected, reversible quarantine directory beside the verified private SQL backup.
* Add per-run uploads reporting for candidates, quarantined paths, file count, bytes moved, skipped database references, unsafe paths, and failures.
* Never permanently delete uploads through this scanner. Move only high-confidence exact-slug top-level directories or exact plugin-basename files for extensions recorded as removed or supported by high-confidence ownership evidence.
* Protect WooCommerce download/invoice and other known business-data directories. Leave unmatched or ambiguous uploads untouched. Skip quarantine when a private writable location cannot be verified.

= 2.1.0 =

* Add a single Smart Cleanup REST workflow and primary administrative action.
* Run inventory, internal preview, private verified backup, safe cleanup, extension-residue analysis, high-confidence table quarantine, final compaction, and whole-database before-and-after reporting from one action.
* Make ZIP source analysis optional. Prefer installed-extension inventory, removed-extension manifests, table-family evidence, and independent row-level ownership witnesses. Keep ambiguous or shared data protected.
* Move manual cleanup categories, extension ZIP controls, quarantine recovery, and specialist repair controls under an optional Advanced Tools disclosure so the default cleanup screen has one primary action.
* Add a Smart Cleanup orchestration lock and fail-closed backup, baseline-audit, dependency, and Multisite safeguards.
* Defer sub-service compaction during Smart Cleanup and run one final eligible-table optimization pass after cleanup phases.
* Normalize Core WordPress and WooCommerce order AUTO_INCREMENT counters to MAX(ID)+1 when enabled. Deleted tail IDs may be reused by this explicit cleanup workflow.
* Exclude full revision purges, pending editorial revisions, and media-plugin-specific trash from unattended cleanup. Keep those operations in advanced manual tools.

= 2.0.0 =

* Promote the Extension Forensic Scanner and whole-database audit architecture to the 2.0 major release.
* Fix a boot-time fatal TypeError by aligning DatabaseCompactionService with the canonical Loggingservice registered by the dependency container.
* Standardize release version and build identifiers across the plugin header, runtime constant, and readme stable tag.
* Retain the forensic inventory, ownership evidence, database before-and-after audit, and bounded compaction workflows introduced during the 1.0.x releases.

= 1.0.7 =

* Add a whole-database before-and-after audit to manual Preview First cleanup and deleted-extension cleanup. Cover every base table in the current database; skip this expensive audit for background WP-Cron and WP-CLI cleanup.
* Add exact per-table COUNT(*) row totals and INFORMATION_SCHEMA data/index allocation totals before and after cleanup.
* Report net changes in table count, exact row count, allocated size, estimated space saved, and per-table changes.
* Add post-cleanup OPTIMIZE TABLE for verified changed tables and tables with at least 1 MiB or 5% reported free space. Report unsupported engines and tables larger than 256 MiB as skipped.
* Report optimized, skipped, and failed tables, plus the largest remaining tables.
* Require the baseline audit to complete before destructive manual cleanup. Mark the final audit partial if any table cannot be counted.
* Clarify that INFORMATION_SCHEMA size totals are allocated table-data and index estimates, not the complete MySQL data-directory footprint. Concurrent site writes may affect net deltas.
* Unify cleanup, extension cleanup, and Reindex maintenance locks to prevent destructive workflows from running concurrently.
* Remove duplicate helper declarations in CleanupService that prevented PHP from parsing the class.

= 1.0.6 =

* Add Extension Forensic Inventory for active and inactive plugins, must-use plugins, drop-ins, themes, WordPress Core tables, and database table-ownership candidates.
* Add static ZIP source inspection for removed plugins and themes with bounded archive size, PHP-only parsing, path-traversal and symlink checks, and no code execution.
* Add independent ownership-evidence scoring. Keep unknown table-name clusters review-only; allow reversible quarantine only with a recorded removal manifest or a recognized extension namespace and sufficient table-family evidence.
* Add row-level cleanup for generic source-discovered Option/Meta keys only when a stored value or parent object provides an independent ownership witness. Treat generic public keys such as settings as review-only without such a witness.
* Add Revision Archive orphan discovery and automatic snapshot cleanup after permanent post deletion.
* Add expired Site Transient cleanup, including Multisite network sitemeta storage.
* Define exact AUTO_INCREMENT scope for WordPress Core identity tables and WooCommerce order tables, with an explicit deleted-ID reuse warning.
* Add post-cleanup AUTO_INCREMENT recalculation for tables with verified row-count reductions and bounded OPTIMIZE TABLE compaction for changed tables up to 64 MiB.
* Protect WooCommerce historical order, product, and order-meta records from generic WooCommerce extension cleanup.

= 1.0.5 =

* Allow generic Option/Meta keys extracted from a removed extension source to be manually selected. Keep these high-risk candidates unselected by default.
* Consolidate deleted-extension residue and custom-table cleanup inside the single Cleanup & Repair screen. Remove the former separate unused-table navigation.
* Distinguish general WordPress/WooCommerce orphan cleanup from deleted-extension residue cleanup so Core and still-installed extension tables are not presented as deletion candidates.
* Add exact source-manifest discovery for plugin/theme tables, Option/Meta keys, custom content types, taxonomies, WP-Cron and Action Scheduler hooks, and saved theme content.
* Keep generic exact keys and hooks high-risk, manually selectable, and never preselected.
* Protect WordPress Core tables, current-prefix boundaries, and tables attributable to other installed plugins/themes. Make old unused-table scans fail closed on database query errors.
* Revalidate source-manifest ownership and installed-extension protection immediately before custom-table deletion.
* Expand cleanup summaries with custom table count, row estimate, and storage bytes. Keep ambiguous generic values manual-review-only.
* Treat WooCommerce download permissions as orphaned only when both the product and its parent order are missing.
* Revalidate orphan metadata, comments, revisions, term relationships, WooCommerce order items, and HPOS rows against their parent immediately before deletion. Stop when verification queries fail.
* Add Action Scheduler orphan-log cleanup and claim cleanup limited to claims with no actions that are older than 24 hours.
* Make cleanup and deleted-extension cleanup honor the global destructive-operation Emergency Stop.

= 1.0.4 =

* Bind each Preview First cleanup type to both its count and a SHA-256 fingerprint of the exact candidate ID set, up to 100,000 candidates per type.
* Validate candidate fingerprints while holding the cleanup lock. Snapshot exact row counts and rebuild AUTO_INCREMENT only for tables whose row count actually decreased.
* Leave related tables with no net deletion untouched.
* Make cleanup and extension-residue scan query failures fail closed instead of interpreting them as zero remaining candidates.
* Allow explicitly selected high-risk custom tables in extension-residue cleanup only after a verified private backup and typed confirmation.
* Block tables with incoming foreign keys, dependent views, or triggers.
* Stop preselecting Cron and Action Scheduler hooks. Do not delete Action Scheduler hooks with in-progress or claimed actions.

= 1.0.3 =

* Rebuild AUTO_INCREMENT on affected tables to MAX(primary_key)+1 after all selected Preview First cleanup candidates are removed.
* Document that deleted tail IDs may be reused by this cleanup behavior.
* Keep manual AUTO_INCREMENT repair, cache cleanup, backup deletion, and log deletion on a non-decreasing-counter policy.
* Skip counter rebuilding for incomplete cleanup, no-op cleanup, scheduled cleanup, and WP-CLI cleanup.
* Report counter-rebuild failures without misreporting the cleanup itself as rolled back.
* Add live post-ALTER verification and explicit reporting of lowered counters and reusable tail-ID ranges.

= 1.0.2 =

* Add preview-first cleanup for database residue left by deleted plugins and themes.
* Capture successful plugin and theme deletions using WordPress pre-delete and post-delete hooks.
* Discover custom tables and columns, WordPress option/meta keys, generic value references, plugin registries, custom post types, taxonomies, Cron and Action Scheduler hooks, and saved theme content.
* Add bounded database-wide text-column discovery for non-core tables. Keep ambiguous serialized/value references and columns in manual-review-only status.
* Require verified private backups, scan-specific confirmation, one-time authorization, fresh locked rediscovery, and stale-preview checks for extension cleanup.
* Correct Action Scheduler claim cleanup so only claims made unused by the selected hook cleanup are removed.
* Use WordPress option and metadata APIs for row deletion to clear caches and fire normal deletion hooks.

= 1.0.1 =

* Prevent generic AUTO_INCREMENT repair from lowering counters or reusing deleted IDs.
* Restrict exact Posts AUTO_INCREMENT adjustment to a verified gapless Reindex and validated Mapping.
* Keep internal maintenance-table counters non-decreasing.
* Recheck manual AUTO_INCREMENT execution against its preview while holding the advisory lock.
* Block legacy migration while the old SHCD Tornado plugin is still active.
* Reset destructive uninstall flags to Off when legacy settings are migrated.

= 1.0.0 =

* Apply WordPress.org pre-review fixes: standardize backup storage resolution, harden protected backup paths and serialized-data handling, and clarify third-party Elementor option writes.
* Publish under the shcd-database-maintenance repository slug and matching text domain.
* Add custom-prefix-aware database discovery using the active $wpdb table names.
* Add preview-first cleanup, revision policies, orphan checks, and retention controls.
* Add checksum-verified logical SQL backups with snapshot fingerprints.
* Add immutable Old ID to Temporary ID to Final ID mapping and dry-run reporting.
* Add controlled, repeatable, gapless Post ID reindex generations with fail-closed Preflight checks.
* Add dedicated Rank Math reference handling.
* Add conservative adaptive discovery for conventional scalar, polymorphic, structured, and strict ID-list references.
* Add selected Elementor, Gutenberg, WooCommerce, builder, media, and cache repair strategies.
* Add reversible table quarantine, audit logs, reports, and WP-CLI commands.
* Add optional independent revision archiving and operational-data retention.

== Upgrade Notice ==

= 2.4.2 =

Back up the site and database before running Smart Cleanup, explicit counter repair, table removal, or Post ID Reindexing. Upgrade over the existing plugin installation; do not uninstall the previous version before the guarded migration has completed. Test destructive workflows on a staging copy first.