Stats Table Guard Pro

Stats Table Guard Pro – Safe Retention-Based Statistics Cleanup for PrestaShop

Purchase status: Purchasing Stats Table Guard Pro is not enabled yet. This page describes its cleanup workflow. Start with the free Stats Table Guard Lite scanner to inspect your statistics tables.

Stats Table Guard Pro includes the same read-only statistics-table scanner as Lite and adds an explicit cleanup workflow for historical connection statistics. It is built for stores that want to keep old traffic data under control without broad or automatic database cleanup.

Preview before anything is deleted

Cleanup never starts on page load and saving settings does not trigger deletion. An administrator must first build a cleanup preview and then explicitly start the operation.

Cleanup is deliberately limited in scope

Pro only cleans historical rows from connections_page, connections_source and connections. Child rows are deleted before parent rows.

Cleanup does not target customers, orders, carts, products, guests, page statistics or arbitrary database tables.

Retention-based cleanup

Choose how many days of connection statistics to keep. The default retention period is 180 days, with common presets for 30, 90, 180 and 365 days plus a custom value.

Transactional batched deletion

Cleanup runs in configurable batches from 100 to 5000 rows, with a default batch size of 1000. Each batch uses a database transaction so a failed batch can stop cleanly instead of silently continuing through a partial operation.

Safety checks before destructive actions

• Cleanup requires the expected PrestaShop statistics tables and columns.
• Existing cleanup tables must be verifiably InnoDB before destructive actions are enabled.
• The cleanup cutoff is validated as a real date-time and against the configured retention boundary.
• AJAX cleanup endpoints require POST, Back Office authorization, edition capability checks and PrestaShop admin token / CSRF validation.
• A failed batch stops the cleanup and technical details are written through PrestaShopLogger.
• No TRUNCATE and no OPTIMIZE TABLE are used.

Understand what deletion does to disk space

Deleting historical rows does not guarantee that the physical database file will immediately become smaller. InnoDB and server configuration determine whether freed pages are reused internally or whether files can shrink.

Plan a retention-based connection-statistics cleanup

Pro is intended for administrators who need to remove old connection statistics after reviewing a preview. Purchasing is not enabled yet. The workflow below explains the cleanup controls described for this edition.

1. Back up the database and decide which historical connection statistics you need to retain.
2. Choose a retention period. The default is 180 days; review whether it matches your reporting needs.
3. Build a preview and check its cutoff date and the rows eligible for cleanup.
4. Explicitly start cleanup only after reviewing the preview. Transactional batches require the expected schema and verified InnoDB tables; a failed batch stops the operation.
5. Review the result. Deleted rows may free reusable InnoDB pages without immediately reducing the physical database file size.

Cleanup scope

Only three historical connection-statistics tables are part of the destructive workflow: connections_page, connections_source and connections. The cleanup service does not accept an arbitrary table name.

Compatibility

• Designed for PrestaShop 8.1.x and 9.x.
• Supports officially supported PHP versions for those PrestaShop releases.
• Supports MySQL and MariaDB configurations used by supported PrestaShop versions.
• No PrestaShop core override is used.

Frequently asked questions

Can cleanup run automatically when I open the page?

No. Cleanup never starts on page load. It requires an explicit preview and an explicit Start cleanup action.

Can Pro delete orders, customers or product data?

No. The cleanup scope is hard-limited to the three historical connection-statistics tables listed above.

Does deleting rows immediately reduce my database file size?

Not necessarily. InnoDB may reuse freed pages internally without shrinking the physical file.

What happens if the server cannot verify the storage engine?

The destructive cleanup path fails closed. Scanning can continue in a reduced read-only mode, but cleanup is not enabled without the required safety verification.

Can I switch from Lite to Pro without installing a second module?

Yes. Lite and Pro use the same technical module directory and module identity. Pro initializes its additional settings after the Lite files are replaced.