WooCommerce : des images de catégorie par saison sans écraser l'image par défaut

Fleuristore — Tue, 03 Nov 2026 14:20:42 +0000

On a un catalogue WooCommerce de fournitures pour fleuristes, Fleuristore, avec une vingtaine de rayons et de pages "métier". Chaque terme a son image, choisie pour être intemporelle : fond clair, lumière du jour, produits seuls.

Puis arrive Noël. On veut que la page Noël et les vignettes de l'accueil passent en version houx et rouge, sans perdre les images de base, et sans devoir tout remettre à la main le 27 décembre.

La règle : ne jamais écraser `thumbnail_id`

La tentation est de remplacer l'image du terme pendant la saison. C'est le meilleur moyen d'oublier de la remettre, ou de perdre l'image d'origine. On a donc posé une règle simple :

thumbnail_id reste l'image par défaut, pour toujours ;
chaque saison ajoute une variante dans une term meta à part : fl_thumb_noel, fl_thumb_saint-valentin, etc. ;
un filtre choisit la bonne image au moment de l'affichage.

Le filtre

WordPress passe toutes les lectures de métadonnées de terme par get_term_metadata. Il suffit d'intercepter thumbnail_id côté front :

add_filter( 'get_term_metadata', function ( $value, $term_id, $meta_key, $single ) {
    if ( is_admin() || $meta_key !== 'thumbnail_id' ) {
        return $value; // l'admin voit toujours l'image par défaut
    }

    $saison = ma_saison_courante(); // ex. 'noel', ou null hors saison
    if ( ! $saison ) {
        return $value;
    }

    $variante = get_term_meta( $term_id, 'fl_thumb_' . $saison, true );
    if ( ! $variante ) {
        return $value; // pas de variante : on garde le défaut
    }

    return $single ? (int) $variante : array( (int) $variante );
}, 10, 4 );

L'appel à get_term_meta() dans le filtre ne boucle pas : la clé demandée n'est plus thumbnail_id, donc le filtre la laisse passer.

Les pièges rencontrés

1. L'admin doit rester honnête. Sans le is_admin(), l'écran d'édition du terme affiche l'image de saison comme si c'était l'image principale. Et pour relire le vrai défaut depuis un script pendant la saison, il faut passer par la table termmeta en SQL : get_term_meta() est filtré.

2. Les images écrites en dur. La page d'accueil avait des vignettes de rayons insérées avec une URL d'image figée (...-768x505.jpg), pas via le terme. Le filtre ne les voit pas. On a ajouté un second passage qui remplace le src de ces vignettes d'après le lien vers le rayon.

3. L'extinction automatique. Tout dépend de ma_saison_courante(), qui lit un calendrier. Le 27 décembre, la fonction ne renvoie plus noel, le filtre rend la main, et l'image par défaut revient sans intervention. Il reste à purger le cache de pages au changement de saison.

Ce que ça change au quotidien

Ajouter la Saint-Valentin revient à poser des fl_thumb_saint-valentin sur les termes concernés. Pas de code, pas de retour arrière à prévoir. Les rayons qui n'ont pas de variante gardent simplement leur image habituelle, par exemple le rayon emballage pour fleuriste.

Article rédigé avec l'aide d'une IA (Claude), relu et basé sur une mise en place réelle sur notre boutique.

Structurer un catalogue WooCommerce B2B : trois axes plutôt qu'un

Fleuristore — Mon, 02 Nov 2026 17:14:22 +0000

Quand on vend des fournitures à des professionnels, le réflexe est de ranger le catalogue comme un rayon de magasin : contenants, emballage, matériel, déco. Ça marche pour l'acheteur qui sait déjà ce qu'il cherche. Ça marche beaucoup moins bien pour celui qui arrive avec un métier ou un événement en tête.

Sur Fleuristore, un grossiste en ligne de fournitures pour fleuristes et décorateurs, on a fini par organiser le catalogue sur trois axes indépendants. Voici le raisonnement et ce que ça implique côté WooCommerce.

1. Les rayons : la taxonomie produit classique

Les catégories WooCommerce (product_cat) restent la base : un produit appartient à un rayon, l'arborescence est stable, les URL ne bougent pas. C'est l'axe « quoi ».

2. Les métiers : une taxonomie dédiée

Un fleuriste et un décorateur événementiel n'achètent pas la même chose, même dans le même rayon. Plutôt que de dupliquer des catégories, on a créé une taxonomie personnalisée « métier », avec ses propres pages d'archive, par exemple les fournitures pour fleuristes ou pour décorateurs.

Une déclaration minimale ressemble à ceci :

register_taxonomy( 'metier', 'product', [
    'label'        => 'Métiers',
    'hierarchical' => false,
    'public'       => true,
    'rewrite'      => [ 'slug' => 'metier' ],
    'show_in_rest' => true,
] );

Un produit peut appartenir à plusieurs métiers : c'est l'axe « pour qui ».

3. Les occasions : le calendrier

Troisième taxonomie, « occasion » : mariage, Noël, fête des mères… C'est l'axe « pour quand ». Une page comme décoration de mariage rassemble des produits venus de rayons très différents.

Ce que ça change

Pas de duplication : un produit vit à un seul endroit, les trois axes ne sont que des filtres.
Des pages d'atterrissage naturelles pour les recherches du type « fournitures mariage » ou « matériel fleuriste ».
Un point de vigilance : chaque archive de taxonomie a besoin d'un vrai texte d'introduction et d'une image par défaut, sinon on se retrouve avec des pages pauvres. On stocke l'image dans un term_meta (thumbnail_id) et on ne l'écrase jamais automatiquement.

Si vous gérez un catalogue B2B sur WooCommerce, posez-vous la question : vos clients cherchent-ils un produit, un usage ou une date ? Souvent, les trois.

DEV Community: Fleuristore