¿Qué haces cuando te escribe una cliente y te dice que tu plugin no funciona en su web? ¿Cómo afrontas el reto?
La respuesta adecuada a estas preguntas es, como siempre, «depende».
Pero lo que está claro es que, independientemente del error concreto, lo más probable es que sigas un esquema parecido a este:
- Entender el problema
- Preguntarle qué ha hecho para llegar a él
- Reproducir el error en tu entorno de desarrollo local
- Entender qué está fallando
- Intentar arreglarlo
- Repetir los pasos 3, 4 y 5 hasta que lo tengas solucionado
En general, lo ideal es intentar reproducir el error en local, pero esto no siempre funciona… y es en esos casos cuando tienes que pedirle acceso a su web e intentar reproducir allí el error para entender qué falla y arreglarlo medio en remoto, como buenamuente puedas.
Pues bien, hoy te contamos cómo puedes debugar y arreglar los scripts públicos en la web de un cliente sin tener que pedirle acceso a la misma. Mola, ¿eh? Pues vamos al tema.
Problemas en los JavaScript públicos
Como te decía, si el problema del cliente está relacionado con la parte pública de su web y, en concreto, con los JavaScript que tu plugin inserta en la misma, estás de suerte porque no vas a tener que pedirle acceso. De hecho, podrás trabajar en local y ver si los cambios que haces arreglan o no el error en su web.
Requisitos
En primer lugar, vas a necesitar un entorno de desarrollo en local. Esto suele incluir un servidor web con WordPress corriendo encima con tu plugin instalado, claro. A mí personalmente me gusta usar Lando, pero puedes usar lo que quieras (como Local, LAMP, etc).
En segundo lugar, necesitarás la extensión de navegador Request Interceptor, disponible en Firefox y Chrome. Con ella, podrás «interceptar peticiones HTTP y HTTPS» y, según cómo la hayas configurado, «modificar las cabeceras de petición y respuesta, lanzar redirecciones o modificar parámetros».
Nelio A/B Testing
By combining A/B tests made with Nelio, we doubled the revenue of webshops in just 12 months. I would recommend Nelio A/B testing to anyone with a WordPress site who wants to start A/B testing. It is definitely the best A/B testing plugin with the best price/quality for WordPress and WooCommerce.
Pieter Boonstra
Interceptar scripts remotos y reemplazarlos por las copias en local
Para no enrollarme más, digamos que la solución pasa por interceptar los scripts de tu plugin que están en la web de la cliente y, a través de una redirección, sustituirlos por las copias que tienes en tu entorno de desarrollo.
Para ello, simplemente abre la página de ajustes de Request Interceptor y añade un nuevo grupo de reglas con New Rule Group. Luego, añades una nueva regla con New Rule y configuras una acción de redirección:
Cuando tengas la regla bien definida (tal y como ves en la captura anterior), activa la regla, el grupo y la propia extensión (fíjate que hay tres botones On/Off para activar diferentes partes de Request Interceptor) y ya lo tienes todo listo. A partir de ese momento, cuando entres a https://user-website.com y el navegador intente cargar el script.js de tu plugin, se hará una redirección a tu URL local y se cargará la versión con la que estás trabajando. Fantástico, ¿eh?
Simplificando un poco más nuestras vidas…
La solución que te acabo de explicar funciona de maravilla para sustituir un script concreto en una web concreta. Pero, claro, si este tipo de errores pasan a menudo, tener que editar cada vez la configuración de Request Interceptor para modificar la URL original y adaptarla a la web de cada nuevo cliente es un poco pesado…
Por suerte, conseguir una solución genérica tampoco cuesta mucho.
En la configuración de Request Interceptor, cambia el modo de detección de URL de StartsWith a Matches(RegEx). Así, podrás detectar el script (o los scripts, en plural) usando una expresión regular:
aunque me temo que tenemos que hacer algo más todavía. Si te fijas en la solución anterior, verás que la URL de destino (esto es, la URL de nuestro entorno de desarrollo) también coincide con la expresión regular que hemos puesto, lo cual acaba generando un bucle infinito de redirecciones… 😥
¡Pero todo tiene solución! 🤗
Simplemente pon una URL de destino diferente que no coincida con la expresión regular. Lo que yo suelo hacer es:
- Creo un enlace simbólico de
pluginsaredirected-pluginsen mi entorno de desarrollo (y me olvido) - Modifico la URL en Actions de
/wp-content/plugins/…a/wp-content/plugins/redirected-plugins/…
con lo que me queda una configuración tal que así:
¡Y listo! Ahora ya sabes cómo configurar tu navegador para sustituir los scripts de la web de un cliente por las versiones que tienes en tu entorno de desarrollo y, así, poder iterar rápidamente añadiendo logs, probando cambios, etc.
Espero que te haya gustado la entradita de hoy y, si es así, compártela con tus colegas y no te pierdas nuestras futuras publicaciones.
Imagen destacada de sebastiaan stam en Unsplash.
Deja una respuesta