# Understanding how PrestaShop hooks work

> Hooks are the core mechanism that lets a module add behaviour to PrestaShop without touching the core code. Understanding how they work changes how you assess whether a need can be met simply, or requires heavier intervention.

- Source canonique : [https://allaux.fr/en/guides/comprendre-hooks-prestashop](https://allaux.fr/en/guides/comprendre-hooks-prestashop)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Short answer

> A hook is a named point in PrestaShop's code where the core calls every module registered on it, exactly when that point is reached while rendering a page or processing an order. A module registers via registerHook() and responds via a method named hookNomDuHook().

## How it works in practice

PrestaShop runs its code normally, and at certain precise points in the flow, it calls every module registered on the corresponding hook, giving them the chance to add content or run an action. A display hook such as displayHeader lets a module insert CSS or JavaScript into the header of every page, for instance. An action hook such as actionValidateOrder fires right after an order is validated, letting a module send a notification, sync external stock or trigger a webhook.

Each hook corresponds to a precise moment and an expected type of content or action: some are meant to display HTML at a spot in the template, others to run an action without displaying anything. Using a display hook to run a heavy action, or the reverse, is a common source of bugs.

The list of available hooks changes from one PrestaShop version to the next: some hooks that exist in an older version disappear or get renamed in a major upgrade, which is why an old module can stop working after an update.

## Identifying the right hook for a given need

1. **Describe the exact moment you need** — First of all: is it when a page loads, after an order is validated, or when a product is added to the cart? Pinning down the exact trigger points directly to the relevant family of hooks.
2. **Distinguish display from action** — A display need (adding a block, a message, a widget) and an action need (sending an email, calling an external API, changing data) don't call for the same type of hook.
3. **Check the official documentation for the target hook** — Each hook expects and provides different parameters (for example the order object for an order-related hook), which you need to know before writing the module's code.
4. **Test the actual trigger** — A hook that looks right on paper can fire at a slightly different moment than expected; a concrete check (for example via a log or debug mode) confirms the actual behaviour before you build all your logic around it.

## modules/mon-module/mon-module.php (extrait)

```
public function install()
{
    return parent::install()
        && $this->registerHook('displayHeader')
        && $this->registerHook('actionValidateOrder');
}

public function hookDisplayHeader($params)
{
    return $this->context->smarty->fetch('module:mon-module/views/templates/hook/header.tpl');
}
```

## Execution order is set in the back office

> When several modules are registered on the same hook, the hook management screen lets you reorder their execution priority by drag and drop, which matters when two modules display content in the same spot or depend on each other. That screen sits under Design > Positions from PrestaShop 1.7 onwards (Modules and Services > Positions on 1.6).

## Signs of a hook-related problem

- A block added by a module that appears twice or in the wrong spot on a page
- An action that's supposed to fire after order validation but never happens
- A module that worked fine before a PrestaShop update and has stopped displaying
- Two modules that seem to conflict over the same display slot

## FAQ

### Can the same hook be used by several modules at once?

Yes, that's the normal way it works: every module registered on the same hook is called one after another, in an order that depends on their configured position.

### What happens if no hook matches the need?

In that case, the only native alternative is the override, which directly replaces a core class rather than hooking into a defined point, with the consequences that has for updates.

### How can you tell which hooks a module is already registered on?

The back office lists, under Design > Positions (Modules and Services > Positions on 1.6), every module registered on each hook, which also lets you reorder their execution priority. There is no hook management anywhere under Advanced Parameters.