Shabnam Tornado Database Maintenance

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

• 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.

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.

• shcd_tornado_jobs
• shcd_tornado_mappings
• shcd_tornado_records

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

Tornado includes dedicated or structured handling for selected relationships in:

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

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.

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.

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.

• 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.

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.