Technology & Packages
Package

Integrity & Auto-Setup: Self-Healing Module System

Automatic database table creation, hook registration, configuration repair, and integrity verification. Every module self-heals on every page load.

Modules that fix themselves

PrestaShop modules can break in dozens of ways: database tables get dropped during a botched update, hooks get unregistered, configuration values go missing, admin tabs disappear. Most modules crash with a white screen when this happens.

Our modules repair themselves. The Integrity system runs from our admin controllers, checks that the pieces the module declared are in place, and puts back the ones that are safe to put back. A full check is cached for an hour.

What it checks and repairs

  • Database tables: checks that every declared table exists with the expected columns and indexes. Missing tables are created, and missing columns and indexes are added. Changed column types and foreign keys are reported rather than altered, because rewriting a live column is not a safe automatic repair.
  • Hook registration: confirms every hook the module declared in getHooks() is registered in ps_hook_module, and registers the ones that are missing.
  • Configuration values: audits the configuration keys the module declares, so a missing one is visible instead of failing silently.
  • Admin tabs: verifies the menu entries the module declares in getAdminControllers() exist in ps_tab, and creates the missing ones. Correcting an existing tab is left to the module, since renaming or reparenting a row someone may have customised is not a safe automatic repair.
  • Authorization roles: ensures all CRUD permission slugs (ROLE_MOD_MODULE_*_CREATE, READ, UPDATE, DELETE) exist in ps_authorization_role. Missing slugs are registered so employee profiles can access the module.
  • Shared tables: cross-module tables such as ps_mpr_config and ps_mpr_admin_prefs are created by whichever module loads first and verified by the others.

How it works

Every module declares its requirements in a structured format. The getIntegrityConfig() method returns which tables are critical and what the expected schema looks like. The system compares that against the actual database, works out the difference, and applies the repairs that are safe to apply.

A full check is cached for 3,600 seconds, so it does not run on every page load. Some CLI and AJAX paths skip it entirely.

If a table marked critical is missing, the module sends the administrator to its Integrity page instead of crashing. That page shows what is wrong and offers a repair button, and noncritical additive fixes can be applied without interrupting anyone.

Why it matters

  • Fewer "missing table" support tickets: the module can recreate a declared table before anyone runs into it
  • Additive updates carry themselves: when a new version declares extra columns, hooks or admin tabs, they are added on the next admin page load
  • Survives a move: after a server move, a restore or a database clone, the module can rebuild the declared structures it finds missing
  • Multi-module coexistence: modules that share the same vendor packages coordinate through the shared tables instead of each creating their own
  • Less manual SQL: declared additive changes are applied for you. Changed types, dropped objects and data migrations still need an explicit, deliberate step

The developer experience

For module developers, declaring the schema in one place covers the additive cases. Add a column in v2.1 and shops on v2.0 receive it on the next admin page load, whether they updated through the back office, FTP or a module upload. The supported CREATE, ALTER ADD and access registrations are designed to be repeatable, so running them twice is harmless. Anything beyond that set is still a migration you write on purpose.

Back to top