Sur un site associatif, deux extensions développées par deux prestataires différents à quelques mois d’intervalle utilisaient chacune l’Interactivity API pour leurs propres besoins : l’une pour un widget d’adhésion en ligne, l’autre pour un formulaire de recherche d’événements. Une fois les deux actives simultanément, un comportement étrange est apparu : cliquer sur le bouton de recherche d’événements déclenchait parfois, sans logique apparente, une action censée appartenir au widget d’adhésion. Aucune erreur dans la console, aucun message d’avertissement au chargement de la page, juste un comportement incohérent difficile à reproduire de façon systématique.
Après investigation, la cause s’est révélée d’une simplicité déconcertante : les deux extensions avaient déclaré leur store sous exactement le même nom de namespace, « recherche », chacune ignorant totalement l’existence de l’autre. Un tel conflit ne se manifeste par aucune erreur au chargement, puisque techniquement, rien n’empêche deux appels à store() avec le même identifiant : le second écrase ou fusionne silencieusement avec le premier selon l’ordre de chargement des scripts.
Comment le conflit se manifeste concrètement
// Extension A, chargée en premier
store( 'recherche', {
actions: {
lancer() { /* logique d'adhésion */ },
},
} );
// Extension B, chargée en second
store( 'recherche', {
actions: {
lancer() { /* logique d'événements, écrase la précédente */ },
},
} );Selon l’ordre de chargement des scripts, déterminé par les dépendances déclarées côté PHP via wp_enqueue_script, l’une des deux définitions d’action lancer finit par prévaloir sur l’autre dans le store fusionné, un comportement qui peut même varier d’un chargement de page à l’autre si l’ordre de chargement n’est pas strictement figé.
Diagnostiquer un namespace partagé
Le symptôme le plus révélateur reste l’incohérence entre le comportement attendu d’un bloc et celui observé, sans qu’aucune erreur JavaScript ne remonte dans la console. Inspecter l’attribut data-wp-interactive présent sur les éléments HTML des deux blocs concernés permet de confirmer rapidement l’hypothèse : si les deux valeurs sont strictement identiques alors qu’elles proviennent de deux extensions différentes, le conflit de namespace est quasiment certain.
<div data-wp-interactive="recherche"><!-- widget d'adhésion --></div>
<div data-wp-interactive="recherche"><!-- formulaire d'événements, même nom ! --></div>La convention qui évite ce piège
La documentation officielle recommande de préfixer systématiquement le namespace d’un store par le nom du plugin ou de l’extension, exactement comme pour l’espace de nom d’un bloc classique, plutôt que d’utiliser un mot générique lié uniquement à la fonctionnalité concernée.
// Extension A
store( 'association-adhesion/recherche', { /* ... */ } );
// Extension B
store( 'agence-evenements/recherche', { /* ... */ } );- Un namespace générique comme « recherche », « formulaire » ou « panier » est presque garanti d’entrer en collision tôt ou tard.
- Préfixer par le nom de l’extension élimine ce risque à la source, sans coût de développement supplémentaire.
- Documenter le namespace choisi dans le README du plugin facilite la détection rapide en cas de futur conflit.
Un conflit qui ne se limite pas aux actions
Le même risque s’applique à l’état partagé entre stores de même namespace : deux extensions qui définissent chacune une clé state.utilisateur sous un même namespace produisent un état fusionné dont le contenu dépend, là encore, de l’ordre de chargement des scripts, avec un risque de valeurs qui se substituent silencieusement l’une à l’autre au fil des interactions du visiteur sur la page.
Un namespace de store Interactivity API mérite le même soin qu’un espace de nom de bloc ou une clé de transient PHP : la tentation du nom court et générique se paie toujours, tôt ou tard, par un conflit difficile à diagnostiquer.
Ce qu’il faut retenir
Ce type de conflit ne produit aucune erreur explicite, ce qui le rend particulièrement coûteux à diagnostiquer sans connaître le mécanisme sous-jacent. Vérifier systématiquement l’unicité des namespaces déclarés dans une extension, en particulier lors d’une revue de code avant publication sur un répertoire public, évite ce genre d’incident qui ne se manifeste souvent qu’une fois deux extensions combinées chez un client, un scénario impossible à anticiper en développant chaque extension isolément.
