# Ce que register_activation_hook comble, faute de mieux dans le cœur

> Créer une table, planifier une tâche, définir une option par défaut : ce hook comble un vide que le cœur ne gère pas automatiquement à l'activation.

- Auteur : WordPress Développement
- Publié le : 2020-12-30
- Mis à jour le : 2020-12-30
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/register-activation-hook-comble-vide-noyau/

## L’essentiel

- Le cœur n'automatise aucune initialisation à l'activation
- Trois usages historiques dominent depuis toujours
- Le hook symétrique de désactivation reste sous-utilisé

Le 30 décembre d'une année marquée par l'arrivée de PHP 8 dans WordPress est une bonne occasion de regarder en arrière : pourquoi un hook aussi simple que `register_activation_hook()` reste-t-il, après des années d'évolution du cœur, le seul point d'entrée officiel pour initialiser une extension ? La réponse tient moins à un manque de vision qu'à un choix d'architecture assumé depuis les débuts du système d'extensions.

WordPress n'a jamais imposé de cycle de vie obligatoire à une extension au-delà de son chargement PHP. Une extension peut se contenter d'ajouter des filtres et des actions sans jamais rien initialiser ; à l'inverse, une extension qui a besoin d'une table, d'une tâche planifiée ou d'une option par défaut doit le faire elle-même, au moment où elle est activée, faute d'un mécanisme générique fourni par le cœur.

## Un vide assumé plutôt qu'un oubli

Si le cœur proposait une initialisation automatique — par exemple, une convention de nommage qui créerait une table à partir d'un fichier de description —, cela imposerait une structure rigide à toutes les extensions, y compris celles qui n'en ont pas besoin. En laissant chaque auteur d'extension définir lui-même ce qui doit se passer à l'activation via un simple rappel, le cœur reste agnostique sur la façon dont une extension gère ses propres besoins d'initialisation. C'est cohérent avec la philosophie générale du système de hooks : proposer des points d'entrée, jamais des comportements imposés.

> L'essentiel à retenir : Le cœur n'automatise aucune initialisation à l'activation ; Trois usages historiques dominent depuis toujours ; Le hook symétrique de désactivation reste sous-utilisé

## Les trois usages qui dominent historiquement

En observant les extensions publiées depuis les premières versions du système, trois usages reviennent presque systématiquement dans le rappel d'activation :

- La création ou la mise à jour d'une table personnalisée, généralement via `dbDelta()`.
- La planification d'une tâche récurrente avec `wp_schedule_event()`, pour un traitement en arrière-plan.
- La définition d'options par défaut avec `add_option()`, pour éviter des vérifications répétées de valeurs manquantes ailleurs dans le code.

```
function mon_extension_activation() {
    global $wpdb;
    require_once ABSPATH . 'wp-admin/includes/upgrade.php';

    $sql = "CREATE TABLE {$wpdb->prefix}mon_extension_journal (
        id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
        message TEXT NOT NULL,
        date_creation DATETIME NOT NULL,
        PRIMARY KEY (id)
    ) {$wpdb->get_charset_collate()};";
    dbDelta( $sql );

    if ( ! wp_next_scheduled( 'mon_extension_purge_journal' ) ) {
        wp_schedule_event( time(), 'daily', 'mon_extension_purge_journal' );
    }

    add_option( 'mon_extension_duree_conservation', 30 );
}
register_activation_hook( __FILE__, 'mon_extension_activation' );
```

## Le hook symétrique, souvent délaissé

Face à ces trois usages, `register_deactivation_hook()` devrait logiquement défaire ce que l'activation a mis en place — au minimum, annuler la tâche planifiée avec `wp_clear_scheduled_hook()`. Dans la pratique, cette symétrie est fréquemment oubliée : beaucoup d'extensions créent une tâche à l'activation sans jamais la retirer à la désactivation, laissant une tâche fantôme s'exécuter indéfiniment tant que l'extension reste installée, même désactivée.

## Pourquoi ce vide ne sera probablement jamais comblé

Une initialisation générique imposerait une convention unique à un écosystème d'extensions profondément hétérogène, où certaines gèrent des tables, d'autres uniquement des réglages, d'autres encore rien du tout à l'activation. Vouloir standardiser ce comportement reviendrait à retirer une part de la liberté d'architecture qui caractérise le système de hooks depuis son origine — un compromis que le projet n'a jamais choisi de faire, préférant laisser chaque extension responsable de son propre cycle de vie.

> Un hook générique et silencieux en dit parfois plus sur une architecture qu'une fonctionnalité imposée : il fait confiance à l'auteur de l'extension pour savoir ce dont il a besoin.

## Pour aller plus loin

Comprendre pourquoi `register_activation_hook()` reste minimal aide à mieux l'utiliser : plutôt que d'attendre du cœur qu'il devine les besoins d'une extension, il s'agit d'assumer explicitement, dans ce rappel, la responsabilité de créer ce qui doit exister — et, tout aussi important, de prévoir dans le hook de désactivation ce qui doit disparaître.