En 2015, un développeur qui cherchait à documenter la bonne façon de proposer des réglages à un thème trouvait, dans le Codex de développement des thèmes, des références à des panneaux d’options organisés en onglets, généralement construits avec des frameworks tiers comme Options Framework ou Redux Framework. Cette pratique, aujourd’hui disparue des recommandations, répondait à un manque réel du cœur de WordPress à cette époque.
Comprendre pourquoi cette approche a existé, puis pourquoi elle a été abandonnée, éclaire une partie de l’histoire de l’API de personnalisation de WordPress, et explique pourquoi certains thèmes anciens continuent d’afficher un panneau d’options séparé du Customizer, hérité d’une époque où ce dernier n’offrait pas encore les mêmes possibilités.
Avant le Customizer, chaque thème inventait sa propre solution
Le Customizer a été introduit dans le cœur de WordPress avec la version 3.4, en 2012, mais son adoption par les auteurs de thèmes a pris plusieurs années. Avant cette généralisation, un thème qui voulait proposer des réglages de couleur, de mise en page ou de logo devait construire sa propre page d’administration, en utilisant l’API des pages d’options du cœur (add_options_page(), register_setting()). Cette API, fonctionnelle mais austère, ne proposait aucune interface visuelle avancée : chaque auteur de thème devait écrire son propre HTML, souvent organisé en onglets pour regrouper des dizaines de réglages sur un seul écran.
Les frameworks d’options, une réponse standardisée à un besoin répété
Face à cette charge de travail répétée d’un thème à l’autre, des frameworks tiers comme Options Framework, puis Redux Framework, ont proposé une couche prête à l’emploi : un tableau PHP décrivait la structure des onglets et des champs, et le framework générait automatiquement l’interface correspondante. Cette approche a connu un succès important sur les places de marché de thèmes premium, où elle permettait de proposer un grand nombre de réglages sans développement d’interface spécifique à chaque thème.
Le Customizer devient progressivement l’alternative recommandée
Le Customizer, en s’enrichissant version après version, a fini par couvrir la majorité des besoins auparavant confiés à ces frameworks : aperçu en temps réel des modifications, organisation en sections et panneaux, contrôles pour les couleurs, les images et les polices. La documentation officielle des thèmes a progressivement mis en avant l’API du Customizer comme approche recommandée, notamment parce qu’elle offrait un aperçu instantané que les frameworks à onglets ne proposaient pas nativement, l’administrateur devant enregistrer puis recharger la page pour voir le résultat de chaque changement.
Pourquoi cette recommandation a mis du temps à s’imposer
La transition n’a pas été immédiate : de nombreux thèmes premium avaient construit toute leur documentation et leur support client autour de leur framework d’options historique, et migrer vers le Customizer représentait un travail de réécriture important sans bénéfice visible immédiat pour l’acheteur final. C’est ce qui explique qu’en 2015, plusieurs années après l’introduction du Customizer, la documentation générale continuait de mentionner ces frameworks comme une pratique répandue, sans les déconseiller explicitement.
Une pratique documentée n’est pas toujours une pratique recommandée pour un projet neuf ; elle reflète parfois simplement ce qui reste répandu par héritage.
Ce qu’il reste de cette époque dans des thèmes encore actifs
Un thème premium acheté avant la généralisation du Customizer peut encore aujourd’hui afficher un panneau d’options séparé, sous un onglet propre dans le menu d’administration, plutôt que d’intégrer ses réglages au Customizer natif. Cette différence n’est pas nécessairement un défaut en soi, mais elle indique presque toujours l’ancienneté de la base de code du thème, un point utile à vérifier avant de reprendre la maintenance d’un tel projet.
- Un panneau d’options séparé du Customizer signale souvent un thème dont la base de code remonte à avant 2015.
- L’absence d’aperçu en temps réel dans un panneau de réglages est un indice fiable de framework d’options historique.
- Migrer ces réglages vers le Customizer natif reste possible, mais représente un chantier de réécriture non négligeable.
En résumé
Le panneau d’options à onglets, aujourd’hui disparu des recommandations, n’était pas une erreur de conception à son époque : il répondait à une absence réelle d’API standardisée dans le cœur de WordPress. Son remplacement progressif par le Customizer illustre bien comment une pratique répandue peut devenir obsolète sans jamais avoir été mauvaise, simplement dépassée par une solution native plus complète.
