Le WordPress d'aujourd'hui, décodé pour les développeurs

Thèmes

current_theme_supports() : un plugin réagit à une fonctionnalité, pas à un nom

Pourquoi un développeur d'extension doit tester les fonctionnalités déclarées par le thème actif plutôt que de vérifier son nom, et comment procéder correctement.

Par WordPress Développement • 22 août 2020 • 4 min de lecture • Aucun commentaire
current_theme_supports() : un plugin réagit à une fonctionnalité, pas à un nom

Que se passe-t-il quand une extension vérifie if ( get_template() === 'twentytwentyone' ) pour décider d’afficher ou non un bloc d’interface ? Le jour où le client change de thème, tout le comportement conditionnel disparaît silencieusement, sans erreur, sans avertissement. C’est un défaut de conception fréquent chez les développeurs qui débutent en écriture d’extensions.

La bonne pratique consiste à interroger non pas le nom du thème, mais les fonctionnalités qu’il a explicitement déclaré prendre en charge. C’est exactement le rôle de current_theme_supports(), une fonction trop souvent ignorée au profit de vérifications plus fragiles.

Le problème du test par nom de thème

Un thème n’est pas une API stable. Son nom peut changer lors d’un renommage, le thème lui-même peut être remplacé par un autre qui gère pourtant les mêmes fonctionnalités, et deux thèmes différents peuvent implémenter la même chose de façon totalement incompatible malgré un nom similaire. Coder en dur une vérification sur get_template() ou wp_get_theme()->get('Name') revient à parier sur un détail sans garantie de stabilité.

Ce que déclare réellement un thème

Quand un thème appelle add_theme_support('post-thumbnails') ou add_theme_support('custom-logo'), cette information est stockée dans un registre interne consultable par n’importe quel code exécuté après after_setup_theme. C’est cette information, et non le nom du thème, qu’une extension doit consulter.

L'essentiel à retenir : Tester un nom de thème est fragile et non évolutif ; current_theme_supports() lit les déclarations réelles ; Prévoir un repli propre si la fonctionnalité est absente
function monextension_afficher_bloc_logo() {
    if ( ! current_theme_supports( 'custom-logo' ) ) {
        return;
    }
    $logo_id = get_theme_mod( 'custom_logo' );
    if ( ! $logo_id ) {
        return;
    }
    echo wp_get_attachment_image( $logo_id, 'full' );
}

Cette fonction retourne un booléen simple pour la plupart des fonctionnalités, mais accepte aussi des arguments supplémentaires pour certaines déclarations plus riches, comme html5, où l’on peut tester la prise en charge d’un élément précis parmi une liste.

if ( current_theme_supports( 'html5', 'search-form' ) ) {
    // Le thème gère un balisage HTML5 natif pour le formulaire de recherche.
}

Prévoir un repli cohérent

Une extension bien conçue ne se contente pas de masquer une fonctionnalité quand le thème ne la déclare pas : elle propose, quand c’est pertinent, un mécanisme de repli qui reste utilisable même sur un thème minimal.

  • Si le thème ne gère pas les images mises en avant, proposer une image par défaut définie dans les réglages de l’extension.
  • Si le thème ne déclare pas title-tag, laisser l’extension gérer elle-même la génération du titre plutôt que d’imposer un doublon.
  • Documenter clairement, dans le fichier readme de l’extension, les fonctionnalités de thème qu’elle sait exploiter.

Un test symétrique côté thème

Il existe une fonction miroir, current_theme_supports(), utilisable aussi bien dans un thème que dans un plugin, et une fonction dédiée aux thèmes parents et enfants, get_theme_support(), qui retourne directement les arguments passés lors de la déclaration plutôt qu’un simple booléen.

$arguments = get_theme_support( 'html5' );
if ( $arguments && in_array( 'comment-form', $arguments[0], true ) ) {
    // Traitement spécifique au formulaire de commentaire en HTML5.
}

Sur les extensions que nous maintenons, la règle est stricte : aucune vérification de nom de thème dans le code métier. Si un comportement doit dépendre du thème, il dépend d’une fonctionnalité déclarée, jamais d’un identifiant.

Une compatibilité qui survit aux changements de thème

L’intérêt principal de cette approche apparaît le jour où un client change de thème sans prévenir l’agence qui maintient ses extensions. Si le nouveau thème déclare les mêmes fonctionnalités que l’ancien, l’extension continue de fonctionner sans aucune modification de code, exactement comme prévu par la conception native de WordPress.

En résumé

Tester une fonctionnalité plutôt qu’un nom de thème est l’un des réflexes qui distinguent une extension pérenne d’une extension fragile. current_theme_supports() et sa fonction complémentaire get_theme_support() offrent tout ce qu’il faut pour écrire ce genre de vérification, sans jamais avoir à connaître à l’avance le thème qui sera actif.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi