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.
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.
