Un thème à blocs actif n’empêche pas forcément l’accès à l’écran Customizer : selon la configuration du site et les extensions installées, ce menu peut rester visible dans l’administration alors qu’il n’a plus aucun effet réel sur l’apparence du site, désormais pilotée par l’éditeur de site et les styles globaux. Un client habitué à cet ancien réglage peut alors continuer à y modifier des valeurs, sans comprendre pourquoi rien ne change en façade — une source de confusion et de tickets de support récurrents une fois la migration terminée.
Retirer cet accès à la fin d’une migration réussie évite cette confusion, mais demande de vérifier au préalable que rien d’important n’en dépend encore. Cette checklist couvre les points à contrôler avant de fermer la porte, pas la migration technique elle-même.
Vérifier qu’aucun réglage actif ne dépend encore du Customizer
- Confirmer que le logo du site est bien géré via les réglages du site ou un bloc dédié de l’éditeur de site, et non plus via l’option de logo du Customizer.
- Vérifier qu’aucun widget de barre latérale classique, géré depuis le Customizer, n’est encore affiché sur une zone du site qui n’a pas été migrée vers un template part.
- Repérer si une extension tierce enregistre son propre panneau dans le Customizer (un réglage de bandeau de cookies, un module de recherche personnalisé) et vérifier si ce réglage reste réellement utilisé.
- Contrôler les options de couleurs ou de mise en page éventuellement encore lues par le thème depuis le Customizer via
get_theme_mod(), plutôt que depuis les styles globaux.
Retirer l’accès proprement
Le Customizer n’a pas d’interrupteur unique dans l’administration : son accès dépend de la capacité customize, contrôlée normalement par le rôle de l’utilisateur. Retirer l’entrée de menu correspondante côté administration se fait par filtre, sans toucher aux capacités des rôles eux-mêmes :
add_action( 'admin_menu', function () {
remove_submenu_page( 'themes.php', 'customize.php' );
} );
Ce retrait masque l’entrée de menu, mais n’empêche pas un accès direct à l’URL de l’écran pour un utilisateur qui en connaîtrait le chemin. Pour un blocage plus strict, une vérification côté customize_loaded_components ou un contrôle de capacité explicite au chargement de l’écran complète ce premier retrait.
Documenter le changement pour le client
- Indiquer clairement, dans la documentation de prise en main livrée avec le projet, que les réglages d’apparence passent désormais par l’éditeur de site et non plus par l’ancien menu Personnaliser.
- Prévoir une note explicite si un rôle personnalisé du site (rédacteur, éditeur avec droits étendus) avait l’habitude d’intervenir sur le Customizer, pour rediriger cette pratique vers le bon écran.
- Conserver une trace des anciens réglages du Customizer avant de les neutraliser, au cas où une donnée oubliée s’avérerait encore nécessaire après coup.
Cas particulier : les extensions qui exigent encore le Customizer
Certaines extensions, notamment des modules de personnalisation tiers plus anciens, continuent d’enregistrer leurs réglages exclusivement via l’API Customizer, sans équivalent dans l’éditeur de site. Retirer l’accès au Customizer sur un site qui dépend encore de l’une de ces extensions casserait un réglage fonctionnel. Le point de vigilance à ne pas sauter : lister explicitement les extensions actives et vérifier, pour chacune, si elle enregistre un panneau Customizer toujours utilisé avant de finaliser ce retrait.
Vérification finale avant mise en production
- Se connecter avec le rôle client réel (pas un compte administrateur) pour confirmer que le menu Personnaliser a bien disparu de son point de vue.
- Vérifier que la façade du site reste identique après le retrait, signe qu’aucun réglage actif ne reposait encore sur le Customizer.
- Informer le client du changement par écrit, avec la date effective, pour éviter tout ticket de support basé sur une ancienne habitude d’usage.
La règle qu’on applique avant toute fermeture d’accès de ce type : jamais de retrait sans avoir listé explicitement, extension par extension, ce qui dépend encore de l’écran qu’on s’apprête à fermer.
En résumé
Couper l’accès au Customizer à la fin d’une migration vers l’éditeur de site évite des confusions durables, mais ne se décide pas à la légère : une vérification systématique des réglages et des extensions encore actives protège contre la perte d’un réglage qu’on croyait obsolète à tort.
