# register_activation_hook doublé d’une vérification manuelle : pourquoi

> Le hook d'activation seul ne suffit pas toujours : voici pourquoi ajouter une vérification manuelle protège une extension d'un environnement inadapté.

- Auteur : WordPress Développement
- Publié le : 2020-02-03
- Mis à jour le : 2020-02-03
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/register-activation-hook-verification-manuelle/

## L’essentiel

- Le hook seul ne bloque rien avant l'exécution
- Une vérification manuelle stoppe l'activation à temps
- deactivate_plugins() referme la porte proprement

`register_activation_hook( __FILE__, 'mon_extension_activation' )` déclenche une fonction au moment précis où une extension est activée — pas avant le chargement des autres fichiers, pas après. C'est un raccourci pratique, mais il a une limite qu'on découvre souvent trop tard : le hook lui-même ne vérifie rien. Il exécute la fonction qu'on lui donne, que l'environnement soit prêt ou non.

Beaucoup d'extensions maison se contentent de ce hook pour créer une table, planifier une tâche ou définir une option par défaut. Le problème arrive quand le serveur ne remplit pas les conditions minimales : version de PHP trop ancienne, extension PHP manquante (GD, cURL), version de WordPress trop basse pour une fonction utilisée plus loin dans le code. Sans vérification manuelle, l'activation « réussit » en apparence, puis l'extension plante au premier chargement d'une page d'administration.

## Ce que le hook déclenche réellement

Techniquement, `register_activation_hook()` associe un identifiant de fichier à un rappel, stocké en interne par WordPress. Quand un administrateur clique sur « Activer », le cœur inclut le fichier principal de l'extension, puis exécute ce rappel. Aucune validation n'est faite entre les deux étapes : si le fichier contient du code incompatible avec la version de PHP en place, l'erreur fatale survient avant même que le rappel d'activation ne s'exécute.

C'est la première limite à comprendre : le hook d'activation ne protège pas contre une incompatibilité de syntaxe. Il ne peut agir qu'une fois le fichier chargé sans erreur. La vérification manuelle doit donc, dans l'idéal, se situer le plus tôt possible dans ce fichier, avant toute déclaration de classe utilisant une syntaxe récente.

> L'essentiel à retenir : Le hook seul ne bloque rien avant l'exécution ; Une vérification manuelle stoppe l'activation à temps ; deactivate_plugins() referme la porte proprement

## Construire une vérification manuelle robuste

La méthode la plus fiable consiste à comparer les prérequis à des constantes disponibles très tôt, puis à interrompre l'activation avant qu'elle ne s'installe durablement :

```
function mon_extension_activation() {
    if ( version_compare( PHP_VERSION, '7.4', '<' ) ) {
        deactivate_plugins( plugin_basename( __FILE__ ) );
        wp_die(
            'Cette extension nécessite PHP 7.4 ou supérieur. ' .
            'Version détectée : ' . PHP_VERSION,
            'Erreur d\'activation',
            array( 'back_link' => true )
        );
    }

    if ( ! function_exists( 'curl_init' ) ) {
        deactivate_plugins( plugin_basename( __FILE__ ) );
        wp_die( 'L\'extension cURL de PHP est requise.' );
    }
}
register_activation_hook( __FILE__, 'mon_extension_activation' );
```

Trois éléments méritent d'être soulignés. D'abord, `deactivate_plugins()` retire l'extension de la liste des extensions actives avant même que WordPress ne finisse le cycle d'activation, ce qui évite qu'elle reste « activée mais cassée ». Ensuite, `wp_die()` interrompt l'exécution avec un message clair, plutôt que de laisser une erreur fatale peu compréhensible s'afficher. Enfin, le message précise la version détectée : cela évite un aller-retour de support pour savoir quel serveur pose problème.

## Où placer cette vérification dans le fichier

Une erreur fréquente consiste à placer la vérification après la déclaration d'une classe utilisant des types de propriétés typés ou une syntaxe récente. Si le serveur tourne encore sous une version ancienne de PHP, l'analyseur échoue avant même d'atteindre la fonction de vérification. La bonne pratique est de séparer le fichier en deux temps : un bloc minimal, écrit dans une syntaxe compatible avec les plus anciennes versions de PHP encore rencontrées en production, chargé de la vérification, puis le reste du code, chargé seulement si les conditions sont réunies.

- Placer la vérification tout en haut du fichier principal, avant tout `use` ou déclaration de classe.
- Écrire cette vérification dans une syntaxe la plus simple possible.
- Ne charger les fichiers de classes qu'après validation des prérequis.
- Toujours utiliser `plugin_basename( __FILE__ )`, jamais un chemin en dur.

## Les pièges qui restent malgré la vérification

Ajouter cette vérification ne règle pas tout. Elle ne s'exécute qu'à l'activation : si le serveur est rétrogradé plus tard, ou qu'une extension d'hébergement désactive cURL après coup, rien ne se déclenche automatiquement. Une vérification complémentaire, plus légère, sur `admin_init` ou `plugins_loaded`, reste utile pour couvrir ce cas — avec un simple message d'avertissement plutôt qu'une désactivation forcée, pour ne pas surprendre un administrateur qui n'a rien changé volontairement.

> Une vérification d'activation qui ne dit pas pourquoi elle bloque est presque aussi frustrante qu'une absence de vérification : le message d'erreur fait partie du correctif, pas un détail annexe.

## En résumé

Le hook d'activation est un point d'entrée, pas un garde-fou. Doubler `register_activation_hook()` d'une vérification manuelle explicite — version de PHP, extensions requises, version minimale de WordPress — évite qu'une extension s'installe dans un état instable. La clé tient en un principe simple : vérifier avant de charger, et toujours donner à l'administrateur une raison compréhensible quand l'activation échoue.