Configure the cron, view reports and run a controlled repair (PrestaShop)

Goal of this article

This guide explains how to configure and verify the Securantis cron on a PrestaShop store, where to consult reports and alerts, and how to trigger diagnostic and controlled repair actions from the module. The objective is to allow you to automate information collection and apply safe fixes without interrupting the store.

Prerequisites

1. PrestaShop 1.7 to 9 installed and accessible as an administrator.
2. Securantis module installed and enabled in the back office.
3. Active Securantis license (advanced reporting and repair features may be blocked without a license).
4. SSH access or access to your hosting administration interface to create a cron task (if you cannot use the hosting panel scheduler, contact your host).
5. Up‑to‑date PHP and extensions required by PrestaShop (compatible versions verified in your client area if needed).

Overview of operation

• The cron periodically runs local checks: inventory, file integrity, quarantine tables, cron token and diagnostic collection.
• The module sends reports and events to the Securantis SaaS if sending is enabled. You can receive automatic alerts by email or via the SaaS interface.
• Repairs proposed by the module are controlled: Securantis prepares and applies fixes such as restoring configuration values, restoring hooks and back‑office menus, regenerating a cron token or repairing quarantine tables. Final decisions (quarantine, deletion, restoration) remain human.

Detailed steps

1. Configure the cron task (recommended: once per hour or once per day)

   a. Open your hosting management panel or use SSH. b. Create a cron task that calls the public URL provided by the Securantis module or the command shown on the module configuration page. If the module provides a cron token, use the full URL including that token. c. Recommended frequency: once per hour for high‑traffic or high‑risk stores, once per day for stores with low changes.

   Expected result: the cron runs without error and the module logs periodic collection events.

2. Verify that collection and report sending are enabled

   a. In the Securantis module settings, enable sending of reports and events if necessary (activation option present in the module). b. Ensure the license is activated and the domain is correctly linked in your Securantis account.

   Expected result: after the first cron run you should see generated reports and, if enabled, reception of a first event in the SaaS interface or by email.

3. View diagnostics and logs from the back office

   a. Open the module’s diagnostic / maintenance page. b. Check the time of the last run, the elements checked (files/items), and the status of components (2FA, firewall, reCAPTCHA, content protections) indicated by the module.

   Expected result: list of checks performed and general module status. Translations display labels such as “Enable firewall” or “Enable admin protection” according to the protections available.

4. Run a controlled repair from the back office

   a. From the module maintenance page, use the controlled repair function. This executes several automated steps: restoring default configurations, repairing hooks and back‑office menus, fixing the cron token and checking quarantine tables. b. Confirm only the actions you understand. The module must display a report of sub‑actions (for example: “Quarantine table”, “Default configuration”, “PrestaShop hooks”, “Back‑office menus”, “Cron token”).

   Expected result: series of results indicating success or failure for each sub‑action. A maintenance log is generated.

Careful settings and recommendations

• Backup: always perform a full backup (files + database) before applying repairs that modify the database or restore tables.
• Quarantine: any quarantining, deletion or restoration of a file detected as suspicious must be decided manually. Securantis will prepare operations but should not automatically remove critical files without your approval.
• Cron frequency: increase the frequency if you detect frequent suspicious behavior, decrease it if your hosting is resource‑limited.
• Logging: keep local logs for at least 30 days to be able to review past events.

Common errors and solutions

1. Cron does not run

   • Common cause: incorrect URL, missing cron token, access permissions blocked by the server firewall.
   • Check: call the cron URL manually from your browser (locally if necessary) and check the HTTP response. Review web access logs (e.g. access.log).
   • Solution: correct the URL or regenerate the cron token from the module, check server firewall configuration.

2. Report not sent to the SaaS

   • Common cause: license not activated, report sending disabled, outbound restrictions on hosting.
   • Check: ensure the report sending option is enabled and the license is validated. Test outgoing connectivity to Securantis services from your server.
   • Solution: activate the license, allow outgoing connections or ask the host to open access.

3. Failure of a repair sub‑action (e.g. hooks, menus)

   • Common cause: insufficient database rights, tables modified by other modules, incompatible PrestaShop version.
   • Check: consult the repair log for the detailed error. Check MySQL privileges of the account used by PrestaShop.
   • Solution: fix privileges, restore a backup if necessary, and rerun the repair.

Advanced troubleshooting

• Clearing logs and cache: if the interface indicates local logs have been cleaned and the cache regenerated, rerun the cron and observe whether the issue persists.
• Forcing a partial repair: if a global repair fails, run repairs one by one (quarantine tables, configuration, hooks, menus, token) to isolate the problematic step.
• Check addon modules: some optional classes (firewall, admin protection, reCAPTCHA, content protection) have ensureDefaults routines. If one of these classes is missing or incompatible, the related repair may be skipped or produce a warning.

Security precautions and compliance

• Never share your passwords by email or chat. If a paid intervention is required, access will be requested (or provided) via the secure client area after payment.
• Securantis does not automatically delete malware: quarantine, restoration or deletion require a human decision. The module will help isolate suspicious items.
• Keep backups before any repair action affecting the database or files.

When to contact Securantis support

Contact support if:

• The cron is correctly configured but reports do not appear and the license is valid.
• The repair repeatedly fails at the same step and the log does not allow resolution.
• You observe suspicious files and need help deciding on restoration, quarantine or deletion.

In your request, provide:

• Precise description of the issue and actions already performed.
• Copy of the maintenance log generated by the module (do not send passwords).
• Mention of the PrestaShop and PHP versions in use.

Final expected result

After correct cron configuration and, if necessary, a controlled repair:

• Periodic executions visible in the module logs.
• Reports and alerts transmitted to the SaaS (if enabled) and/or summaries available in the back office.
• Repaired items listed with status for each sub‑action (success/failure) and an operation log.

If a critical item remains unrepaired, keep the backup and contact support for guided intervention.

Appendix: quick best practices

• Always backup before repair.
• Prefer gradual repair (sub‑actions one by one) when in doubt.
• Keep logs and note any manual changes.
• Do not automate deletion of suspicious files without human review.

If you need help verifying cron configuration or sending the maintenance log, open a ticket from your Securantis client area. Support will instruct you on the next steps and will never request your passwords by email or chat.