Le moment exact où un site bascule d’un thème à un autre correspond, dans le code de WordPress, à un hook précis nommé switch_theme. Peu de développeurs l’utilisent, pourtant il ouvre une possibilité intéressante : exécuter une migration de réglages exactement quand elle doit avoir lieu, sans dépendre d’une action manuelle du client ou d’un script lancé à part.
Le déroulement d’un changement de thème
Quand un administrateur active un nouveau thème depuis l’écran « Apparence », WordPress déclenche deux hooks dans un ordre précis, chacun correspondant à un moment distinct de la bascule.
// 1. switch_theme : déclenché juste après le changement de réglage, thème encore en cours d'activation
add_action( 'switch_theme', 'monthème_avant_migration', 10, 3 );
function monthème_avant_migration( $nouveau_nom, $nouveau_theme, $ancien_theme ) {
// $ancien_theme est un objet WP_Theme représentant le thème quitté
}
// 2. after_switch_theme : déclenché une fois le nouveau thème pleinement actif
add_action( 'after_switch_theme', 'monthème_apres_activation' );
function monthème_apres_activation() {
// Le nouveau thème est désormais actif, ses fonctions sont disponibles
}
La distinction entre les deux est essentielle : switch_theme s’exécute alors que l’ancien thème est encore techniquement identifiable via son objet WP_Theme transmis en troisième argument, ce qui permet de savoir précisément d’où vient la bascule. after_switch_theme, en revanche, s’exécute une fois que les fonctions du nouveau thème sont pleinement chargées, ce qui convient mieux à une initialisation de réglages par défaut.
Un cas d’usage concret : migrer un réglage de couleur
Imaginons un thème qui stocke une couleur d’accent choisie par le client via set_theme_mod(). Lors d’un changement de thème planifié vers un nouveau thème successeur, il est possible de récupérer ce réglage depuis l’ancien thème et de l’appliquer automatiquement au nouveau.
add_action( 'switch_theme', 'monthème_migrer_couleur_accent', 10, 3 );
function monthème_migrer_couleur_accent( $nouveau_nom, $nouveau_theme, $ancien_theme ) {
if ( 'ancien-theme-maison' !== $ancien_theme->get_stylesheet() ) {
return;
}
$couleurs = get_option( 'theme_mods_ancien-theme-maison' );
if ( isset( $couleurs['couleur_accent'] ) ) {
update_option( 'theme_mods_' . get_stylesheet(), array(
'couleur_accent' => $couleurs['couleur_accent'],
) );
}
}
Cette approche évite qu’un client perde un réglage auquel il tenait simplement parce que le format de stockage diffère entre l’ancien et le nouveau thème.
Pourquoi ne pas tout faire dans after_setup_theme
after_setup_theme s’exécute à chaque chargement du thème, pas seulement lors d’un changement. Y placer une logique de migration exécuterait ce code à chaque affichage de page, ce qui est à la fois inutile et potentiellement coûteux si la migration implique des lectures ou écritures en base de données. switch_theme et after_switch_theme, en comparaison, ne se déclenchent qu’une seule fois, exactement au moment de la bascule.
switch_theme: idéal pour lire les données de l’ancien thème avant qu’elles ne deviennent inaccessibles.after_switch_theme: idéal pour initialiser des réglages par défaut propres au nouveau thème.after_setup_theme: réservé aux déclarations qui doivent s’exécuter à chaque chargement, pas à une migration ponctuelle.
Un réflexe utile pour toute agence qui gère un renouvellement de thème planifié à l’avance : préparer ce hook de migration plusieurs semaines avant le jour J, plutôt que de tout scripter en urgence au moment de l’activation.
En résumé
switch_theme reste un hook peu connu, mais il permet une chose que peu d’autres mécanismes offrent aussi proprement : agir précisément au moment de la transition entre deux thèmes, avec un accès direct à l’ancien comme au nouveau. Une base solide pour toute migration de réglages qui doit survivre à un changement d’habillage visuel.
