Migrer une automatisation Zapier ou Make vers un nouvel hôte de géocodage
Les automatisations sans code construites autour d'une étape de géocodage demandent une autre approche de migration que le code sur mesure. Voici comment gérer ce changement.
Les plugins WordPress qui appellent une API de géocodage, qu'il s'agisse d'un localisateur de magasins, d'un vérificateur de zone de livraison ou d'une carte d'annonces immobilières, sont généralement conçus avec la clé d'un fournisseur précis, saisie une fois dans une page de réglages et utilisée partout où le plugin a besoin d'une recherche de localisation. Ce champ de réglage unique est pratique pour les propriétaires de sites, mais il signifie aussi que le fournisseur de géocodage est souvent plus profondément intégré au code du plugin qu'un rapide coup d'œil à la page de réglages ne le laisse penser.
La première chose à établir est de savoir si vous migrez un plugin que vous maintenez vous-même ou un plugin tiers que vous vous contentez de configurer. Ce sont deux situations réellement différentes :
Si vous maintenez le plugin, la migration est une modification de code classique : trouvez chaque fonction qui appelle l'API de géocodage (rechercher dans le code du plugin le nom d'hôte du fournisseur ou le nom de son paramètre de clé est généralement le moyen le plus rapide de localiser chaque appel), et mettez à jour ces fonctions pour qu'elles appellent le nouvel hôte avec une nouvelle clé. Comme PHP est ici le langage naturel et que les hôtes compatibles de My Geocode reproduisent exactement le format de réponse d'un fournisseur familier, si le code existant du plugin analyse déjà le format propre à ce fournisseur, il suffit souvent de mettre à jour l'hôte de la requête et l'authentification, plutôt que la logique d'analyse des réponses. L'authentification accepte un en-tête X-API-Key, Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête : quelle que soit la façon dont le plugin envoie actuellement sa clé, il existe un équivalent direct.
Si vous vous contentez de configurer un plugin tiers, vos options dépendent entièrement de ce que la page de réglages du plugin propose. Certains plugins permettent de configurer un endpoint d'API personnalisé en plus de la clé ; dans ce cas, faire pointer ce réglage vers l'hôte compatible correspondant, s'il en existe un pour le fournisseur pour lequel le plugin a été conçu, peut fonctionner sans aucune modification de code, puisque du point de vue du plugin il communique toujours avec une API de même format. D'autres plugins codent entièrement en dur le nom d'hôte du fournisseur ; vos options se limitent alors à contacter le développeur du plugin, à chercher un fork ou une mise à jour qui apporte plus de souplesse, ou, pour une dépendance critique, à envisager une petite modification personnalisée si la licence du plugin le permet.
Quelques remarques pratiques valables dans les deux cas :
Pour le site d'une petite entreprise qui s'appuie sur un seul plugin pour un localisateur de magasins ou une fonctionnalité similaire, le quota quotidien gratuit, 2 500 requêtes sans aucune clé, ou 2 500 par compte et par jour, partagées par toutes ses clés, couvre souvent largement le trafic que génère un petit site typique ; cela vaut la peine de le comparer au volume réel de visiteurs et de recherches de votre site avant de supposer qu'une offre payante est nécessaire.