Cleanup Revolution: setup and help

1. Upload and install the mprcleanuprevolution ZIP through Modules > Module Manager.
2. Click Configure. You reach Cleanup > Settings > Configuration for file and image settings.
3. Choose the intended shop context.
4. Open Cleanup > Database > Database configuration for database policies.
5. Check the employee profile permissions and private archive storage before destructive database work.
6. Start with Cleanup > Database > Cleanup Tasks and click Preview cleanup for one task.
7. Review the saved plan, scope, protected rows and dependencies. Complete backup verification and approval where required before execution.

Keep your regular shop database and file backups. The module's row archives cover eligible database cleanup plans. They are not a full backup of your shop files, all tables or external services.

Database operations use native employee profile permissions. The module installs separate permission tabs for Preview cleanup, Statistics cleanup, Personal data cleanup, Catalogue cleanup, Approve destructive runs, Run now and scheduling, Export encrypted backups, Restore backups and Optimise tables.

Viewing a plan requires preview and task-category view access. Destructive work also checks the matching delete permission. Approval, backup export, restore and maintenance have additional permissions. Shop access is checked for the employee. CLI execution also checks the selected employee's permissions and shop access.

Database archives must be outside every public document root. The default location is a hidden directory beside the shop root, named .mprcleanuprevolution- plus a generated hash. A deployment can set the PHP constant MPRDBCLEAN_STORAGE_ROOT to another absolute private directory and MPRDBCLEAN_PUBLIC_ROOTS to an array of public roots.

The PHP user needs access to this storage. Directories must have private permissions equivalent to 0700; the archive key must be private, equivalent to 0600. Symlinked or publicly accessible archive storage is refused. OpenSSL must support aes-256-gcm.

Keep the archive encryption key with your private recovery material. Export encrypted backup does not export that key. For CLI, provide a valid DOCUMENT_ROOT or configured MPRDBCLEAN_PUBLIC_ROOTS so the module can establish which locations are public.

Open Cleanup > Database > Database configuration. Database settings are separate from the file/image configuration.

Policies inherit by scope. Read the effective policy table to confirm the source and value for each shop. A changed policy or scope requires a new preview. Approval is tied to the saved plan hash and authenticated employee.

Choose a database task

The task registry protects active references, historical orders and other-shop data according to each task. Unknown guest age starts at first observation. It does not assume every guest row is already old enough.

For Selected merchant variants, supply Selected combination IDs, separated by commas. This task requires explicit selection, preview, backup and approval. Acknowledged module names, separated by commas is available for the plan's dependency workflow. Read the dependency report before using it.

Old configuration fields for closed customer messages, page views, guest/registered customers without orders, double confirmation and global rows-per-batch are not the current database-policy screen. Use the task list and policies above.

Open Cleanup > Database > Cleanup Tasks. Select Tasks. You can enter One-off retention days for a preview override. Click Preview cleanup.

The workspace saves a run with a Run ID and plan hash. Review counts, affected shops, retention cutoff, effective policies, dependencies, risks, estimated logical bytes and protected/skipped rows. Large previews can progress through several bounded requests.

For tasks requiring backup and approval:

1. Click Verify backup and wait for backup verification to finish.
2. Review the saved plan and click Approve this plan.
3. Confirm the destructive operation.
4. Click Execute approved plan.
5. Read the final report. A partial or failed result needs review before Resume run.

Low-risk statistics tasks do not have the same backup/approval requirement. Check the plan rather than assuming every operation is recoverable.

Run now uses the same saved-plan workflow and permissions. It is not an unconditional delete shortcut. Cancel run stops further work; it does not reverse batches already committed.

Open Cleanup > Database > Backups and restore. Load the Run ID, inspect backup items and choose Preview restore. Review conflicts before Restore verified backup. Restore refuses conflicting live rows rather than replacing them blindly.

Use Export report JSON or Export report CSV for the run report. Choose a Backup item ID for Export encrypted backup. These downloads require the matching permissions.

Purge expired archives runs bounded archive housekeeping. Archive retention is measured in hours and is separate from the orphan-image trash setting.

Table optimisation uses the database workspace too. Enter Tables to optimise, separated by commas, then use Preview table optimisation, Verify optimisation backup, Approve table optimisation and Optimise tables. Only proceed after reviewing the plan. Optimisation can lock or rebuild database tables and should be scheduled for a suitable maintenance period.

Table Sizes reports data size, index size, reusable/free space and fragmentation from database metadata. The row-size figures estimate logical data; deleting rows can leave reusable database space without immediately reducing disk usage.

Open Cleanup > Settings > Configuration, headed Cleanup Configuration.

Click Save configuration after changes. On file/image action pages, review Preview only before choosing Apply cleanup to make changes. The saved dry-run preference selects the default; scheduled cleanup always applies changes.

Review images

Use Images > Orphaned Images to scan product, category, manufacturer and supplier image files against database references. Review files before removal, especially with custom image handling.

With trash mode on, selected orphaned images are moved to:

/img/_cleanup_trash/YYYY-MM-DD/

Recover those from the filesystem before the scheduled purge removes them after the retention period. With trash mode off, removed images are deleted permanently. Do not confuse image trash with encrypted database archives.

Duplicate Images groups matching product image files by MD5 and reports estimated wasted space. It does not merge image assignments or automatically delete duplicates. Missing Images reports referenced product images whose files cannot be found.

Review cache, temporary files and module leftovers

Files & Cache > Cache Cleanup lists existing Symfony cache, Smarty compiled/cache files, theme asset cache, log files and class-index cache. Review groups before clearing them. Cache clearing can cause regeneration work on the next requests.

Temp Files lists image-temp and import files for manual review and removal, including files younger than the retention threshold. Manual selection can remove these younger files. The retention setting applies to automated temporary-file cleanup and the temporary-image cleanup action in supported paths.

Module Leftovers distinguishes uninstalled module folders, parked folders and non-module entries. Only eligible uninstalled module folders have the removal workflow. Removing a folder deletes its files. Export anything you need first. Candidate MPR tables and configuration keys are review information; this page does not automatically drop those tables or erase every MPR% key.

Duplicate Finder reports duplicate products by name/reference/EAN/UPC, categories, features and attributes. Review and resolve these manually. It does not merge catalog entities.

Before removing an uninstalled module folder, the action checks its current inventory classification again. It rejects a candidate that conflicts with an installed module name only by letter case, and it rejects a symlinked candidate. The resolved folder must remain inside the modules directory. These checks do not make a file backup: review and export the folder contents before removal.

The database workspace supplies:

php modules/mprcleanuprevolution/bin/cleanup.php --help
php modules/mprcleanuprevolution/bin/cleanup.php --employee=1 --shops=1 --task=old_carts --preview

Replace IDs with an authorized active employee and the intended shops. Use --shops=1,2 for an authorized explicit list. --global is a separate explicit scope choice. The command does not bypass profile permissions.

Saved-run steps are separate commands:

php modules/mprcleanuprevolution/bin/cleanup.php --employee=1 --shops=1 --run-id=RUN_ID --verify-backup
php modules/mprcleanuprevolution/bin/cleanup.php --employee=1 --shops=1 --run-id=RUN_ID --approve --plan-hash=PLAN_HASH
php modules/mprcleanuprevolution/bin/cleanup.php --employee=1 --shops=1 --run-id=RUN_ID --execute

Use the actual Run ID and hash from your reviewed report. Use one operation flag per command. Restore uses --restore-preview, then --restore --plan-hash=PLAN_HASH. --batches=N checkpoints after a bounded number of batches. Preview overrides include --retention-days, --batch-size, --row-budget, --time-budget-ms, --combination-ids and --acknowledged-modules. A saved plan cannot be changed by adding those overrides.

The shared MPR cron runner checks database_cleanup every minute. Save a five-field cron expression and timezone in the task policy to activate its schedule, or leave the schedule empty to disable it. Runs use the permissions and shop access of the employee who saved the policy. The scheduler creates a saved preview and prepares required backups; tasks requiring approval wait for a reviewed plan to be approved in Cleanup Tasks before execution continues.

The separate file_cleanup task, labelled Clean Cache & Temp Files, runs at daily:03:30. It clears supported cache groups, deletes temporary files older than the configured threshold and permanently purges expired image-trash folders. It applies changes even when Dry-run by default is on. With email reports enabled, per-run sends a report after this callback; daily sends a digest through email_report at daily:05:00.

After any run, inspect Database history and its report for completed, skipped, partial and failed work. File/image operations also write the module's cleanup history with affected counts, space estimates, duration and employee/trigger details.

If a database action is unavailable, check profile permissions, selected shops, effective Enabled settings, task policy, plan revision and required backup. If backup verification fails, check the private storage location, permissions, public-root declarations and OpenSSL support. If a restore reports conflicts, review the changed live rows before creating a new restore preview.

Use Cleanup > Settings > System Check for shared tables and runtime-version problems. If execution pauses at a budget, inspect the saved run and resume instead of creating an unrelated delete operation.

To stop database destruction, set its effective Enabled value to No. Turn off File and image cleanup enabled to block both scheduled and manual file/image cleanup, including module-folder removal. Disable Enable email reports separately to stop report emails. Disable the whole module in Module Manager if you need to stop all module access. These settings are separate.

Uninstall removes the menu and module registration. Shared cleanup journals and recovery archives are kept for other modules that use them. Uninstall does not restore deleted rows or files. Preserve required recovery data and keys until your retention obligations and recovery needs are complete.

Requires PrestaShop 1.6.1 or later and PHP 7.1 or later.