« The active theme cannot be deleted » : ce message s’affiche dans l’administration WordPress dès qu’on tente de supprimer le thème actuellement activé sur un site, que ce soit via l’interface graphique ou via WP-CLI. Avant d’entamer une migration d’un parc de sites vers WordPress 7.0, il est utile de comprendre précisément ce mécanisme, car un script de nettoyage automatisé mal conçu peut buter dessus sans prévenir.
Pourquoi WordPress refuse cette suppression
Le cœur de WordPress vérifie, avant toute suppression de thème, si celui-ci correspond au thème actuellement actif du site, stocké dans l’option template et stylesheet. Si c’est le cas, la suppression est bloquée sans exception : un site ne peut techniquement pas fonctionner sans thème actif, et permettre cette suppression laisserait WordPress dans un état incohérent, incapable de générer le moindre gabarit de page.
Cette protection existe de longue date dans le cœur de WordPress et reste inchangée dans son principe pour la version 7.0 : elle ne dépend pas d’une extension ni d’un réglage particulier, elle fait partie du comportement natif de la fonction de suppression de thème.
Le même blocage en ligne de commande
La commande wp theme delete applique exactement la même vérification que l’interface graphique, ce qui peut surprendre dans un script de migration automatisé exécuté sur plusieurs sites d’un parc à la fois :
$ wp theme delete ancien-theme
Error: You cannot delete the currently active theme: ancien-theme.
Sur un parc de sites où chaque site peut avoir un thème actif différent, un script qui tente de nettoyer systématiquement les anciens thèmes échouera site par site, sans jamais supprimer le thème réellement en cours d’utilisation, ce qui est précisément le comportement recherché, mais qu’il faut anticiper dans la logique du script pour éviter qu’un échec ne bloque l’exécution du reste du parc.
Ce qu’il faut vérifier avant une migration de parc vers WordPress 7.0
- Lister, pour chaque site du parc, le thème actuellement actif via
wp theme list --status=active --field=name - Exclure explicitement ce thème actif de toute commande de suppression automatisée dans le script de migration
- Activer le nouveau thème cible avant de supprimer l’ancien, jamais dans l’ordre inverse
- Vérifier, après activation du nouveau thème, que l’ancien peut désormais être supprimé sans erreur
$ wp theme activate nouveau-theme
Success: Switched to 'Nouveau thème' theme.
$ wp theme delete ancien-theme
Success: Deleted 'ancien-theme' theme.
Un piège fréquent sur les scripts de nettoyage automatisés
- Un script qui active un thème puis tente de le supprimer dans la même exécution, sans laisser WordPress recharger correctement l’option du thème actif
- Un script qui suppose à tort que tous les sites du parc partagent le même thème actif au moment de la migration
- Une confusion entre thème parent inactif et thème réellement actif, alors qu’un thème enfant peut être actif tout en dépendant d’un parent qu’on tenterait de supprimer par erreur
Le cas particulier du thème parent d’un thème enfant actif
Un script de nettoyage qui se contente de vérifier le nom du thème actif via stylesheet peut passer à côté d’un cas fréquent : lorsqu’un thème enfant est actif, WordPress considère le thème parent comme requis pour le fonctionnement du site, même s’il n’apparaît pas directement comme actif au sens strict. Tenter de supprimer ce parent produit une erreur différente, liée à sa dépendance, plutôt qu’au message évoqué plus haut, ce qui peut dérouter un script qui ne prévoirait qu’un seul type d’erreur à intercepter.
Sur un parc de sites où plusieurs thèmes enfants partagent le même thème parent, cette dépendance doit être vérifiée explicitement via wp theme list --field=parent_theme avant toute tentative de suppression, pour ne jamais confondre un parent encore utilisé par un site avec un thème réellement obsolète sur l’ensemble du parc.
Un message d’erreur qui bloque une suppression n’est pas toujours un bug à contourner : ici, il protège exactement contre l’état qu’un script de migration mal conçu pourrait provoquer.
En résumé
Ce comportement n’a rien de nouveau ni de spécifique à WordPress 7.0 ; il rappelle simplement, au moment d’une migration de parc, qu’aucun script de nettoyage ne doit tenter de supprimer un thème sans avoir d’abord vérifié, site par site, lequel est réellement actif. Une simple vérification via wp theme list avant chaque suppression évite tout échec de script sur l’ensemble du parc.
