Migrar una automatización de Zapier o Make a un nuevo host de geocodificación
Las automatizaciones sin código basadas en un paso de geocodificación necesitan un enfoque de migración distinto al del código propio. Así puedes gestionar ese cambio.
Migrar un plugin de WordPress desde una API de geocodificación de pago
Los plugins de WordPress que llaman a una API de geocodificación, ya sea un localizador de tiendas, un comprobador de zonas de reparto o un mapa de anuncios inmobiliarios, suelen construirse con la clave de un proveedor concreto que se introduce una vez en una página de ajustes y se usa en todos los puntos donde el plugin necesita consultar una ubicación. Ese único campo de ajustes es cómodo para los propietarios del sitio, pero también significa que el proveedor de geocodificación suele estar más integrado en el código del plugin de lo que sugiere un vistazo rápido a la página de ajustes.
Lo primero es determinar si vas a migrar un plugin que mantienes tú mismo o un plugin de terceros que solo configuras. Son situaciones realmente distintas:
Si mantienes el plugin, la migración es un cambio de código normal: localiza todas las funciones que llaman a la API de geocodificación (buscar en el código del plugin el nombre de host del proveedor o el nombre concreto de su parámetro de clave suele ser la forma más rápida de encontrar todos los puntos de llamada) y actualiza esas funciones para que llamen al nuevo host con una nueva clave. Como PHP es aquí el lenguaje natural y los hosts compatibles de My Geocode reproducen la estructura de respuesta exacta de un proveedor conocido, si el código actual del plugin ya analiza el formato concreto de ese proveedor, a menudo basta con actualizar solo el host de la solicitud y la autenticación, sin tocar la lógica de análisis de la respuesta. La autenticación admite una cabecera X-API-Key, Authorization: Bearer, autenticación HTTP Basic o un parámetro de consulta, así que el método que use actualmente el plugin para enviar su clave tiene un equivalente directo.
Si solo configuras un plugin de terceros, tus opciones dependen por completo de lo que ofrezca la página de ajustes del plugin. Algunos plugins permiten configurar un endpoint de API personalizado junto a la clave; en ese caso, apuntar ese ajuste a un host compatible equivalente, si existe uno para el proveedor para el que se creó originalmente el plugin, puede funcionar sin ningún cambio de código, ya que, desde el punto de vista del plugin, sigue hablando con una API de la misma estructura. Otros plugins tienen el nombre de host del proveedor fijado en el código; en ese caso, tus opciones se limitan a contactar con el desarrollador del plugin, buscar un fork o una actualización que añada flexibilidad o, si es una dependencia crítica, plantearte una pequeña modificación propia si la licencia del plugin lo permite.
Algunas notas prácticas para ambos escenarios:
- Prueba cualquier cambio primero en una copia de staging del sitio, nunca directamente en una instalación de WordPress en producción, ya que el código de un plugin que interactúa con una base de datos en producción conlleva más riesgo que un cambio de código aislado en otro contexto
- Comprueba si el plugin guarda en caché los resultados de geocodificación en su propia tabla de la base de datos, ya que un cambio de proveedor puede requerir vaciar o revalidar esa caché por separado del propio cambio de código
- Confirma que la gestión de errores del plugin maneja con elegancia una estructura de respuesta inesperada, ya que un sitio de WordPress que muestra un error de PHP en bruto a un visitante por una respuesta de API que no coincide es un resultado peor que el hecho de que la función de geocodificación simplemente no aparezca durante un momento
Para el sitio de una pequeña empresa que depende de un solo plugin para un localizador de tiendas o una función similar, la cuota diaria gratuita, 2.500 solicitudes sin ninguna clave, o 2.500 por cuenta y por día compartidas por todas sus claves, a menudo cubre de sobra el tráfico que genera un sitio pequeño típico, así que conviene contrastarla con el volumen real de visitantes y consultas de tu sitio antes de dar por hecho que necesitas un plan de pago.