No me cansaré de repetirlo. El mundo del desarrollo web es una jungla donde por muy experimentado que seas, cualquier espécimen te la puede liar. Si te dedicas a esto sabrás de lo que te hablo. Hacer el mal es más fácil de lo que parece. Y, por desgracia, en Nelio nos hemos encontrado ya con más situaciones de las que nos hubiera gustado donde nuestros plugins han dejado de funcionar por culpa de las malas prácticas de terceros.
Uno de los problemas más comunes que te puedes encontrar hoy en día si desarrollas plugins para WordPress es el mal uso de JavaScript. Muchos «desarrolladores» (por llamarlos de alguna manera elegante) no siguen las normas de WordPress. Y te puedes encontrar con sorpresas inesperadas. O peor aún, se las encontrarán tus clientes ?
En este artículo te voy a explicar cómo pasamos una mañana investigando los problemas que tenía un cliente de Nelio Content y cómo pudimos solucionarlo gracias a una extensión para Google Chrome y Opera que agilizó todo el proceso.
Investigando problemas de JavaScript en un «entorno hostil»
La historia empieza como siempre: un cliente nos contactó a través de nuestro sistema de soporte porque tenía problemas con Nelio Content. En concreto, el problema tenía que ver con las analíticas que Nelio Content proporciona. En su instalación, la página de analíticas de Nelio Content se quedaba cargando de forma infinita, sin mostrar nada más.
Después de pedirle acceso a su WordPress (no siempre es fácil conseguir acceso a las instalaciones de tus clientes) y comprobar el error nosotros mismos, vimos que efectivamente existía un problema relacionado con nuestros scripts. Pero era un problema muy extraño. Aparentemente, entrábamos en un bucle infinito de llamadas a funciones. Funciones que solamente se ejecutan en respuesta a eventos. Por lo que, de algún modo, se estaban generando eventos múltiples veces sin sentido.
Investigar este tipo de problemas en la instalación de un cliente es un infierno. Además, fuimos incapaces de reproducir el problema en nuestras instalaciones de desarrollo. Así que cada cambio que necesitas hacer en tu código JavaScript implica que tengas que probarlo en tu instalación de desarrollo, preparar una nueva versión del plugin (un archivo .zip), desactivar la versión subida en la web del cliente y eliminarla, subir la nueva versión allí, y finalmente activarla y ver si has solucionado el problema.
Está claro que si te dan acceso FTP o SSH la cosa se simplifica, pero no fue el caso. No siempre vas a poder disponer de un entorno en el que hacer pruebas sea un paseo. Así que cada prueba que hacíamos nos destrozaba la productividad y la paciencia. Y además, nada nos indicaba dónde estaba el problema. ¿¡Qué estábamos haciendo mal!? Hasta que se nos iluminó la bombillita…
¿Y si el problema que tienes con nuestro plugin no es realmente un problema con nuestro plugin? ¿Habrá otro plugin que mete algo en nuestra página y hace que todo se rompa? Investiguemos…
Como deberías saber, si un plugin en WordPress define una página privada en el Escritorio de WordPress, esta página (normalmente accesible a través del menú del plugin) es del plugin y nadie debería meter allí ningún JavaScript o ningún estilo CSS. Esto es lo que dice la norma, pero la realidad es muy diferente, lamentablemente.
En la instalación WordPress de nuestro cliente, en la página de analíticas de Nelio Software, encontramos más de 10 archivos JavaScript incluidos que no forman parte de nuestro plugin. Os recuerdo que esta página es privada de nuestro plugin, así que nadie, excepto Nelio Content, debería meter nada allí ?
En estos casos, lo más normal es ir desactivando los plugins activos y ver si sólo teniendo Nelio Content activo el problema se soluciona. A partir de ahí, si todo funciona, vas activando un plugin cada vez para ver cual es el que rompe el tuyo. Sin embargo, al estar en una instalación WordPress en producción, esto no lo puedes hacer a la brava o puedes hacer que la web de tu cliente se rompa por desactivar plugins.
Por suerte, finalmente encontramos la solución.
La extensión Interception te permite reemplazar scripts y estilos al vuelo con los tuyos propios. Además, funciona tanto en Google Chrome como en Opera. Échale un ojo aquí. [Edit: parece ser que esta extensión ya no está disponible. Usa Request Interceptor en su lugar] Y su interfaz es muy sencilla:
Sólo tienes que poner la URL de un archivo remoto y sustituirla por otra URL cualquiera. De este modo, lo que hicimos fue apuntarnos todas las rutas de los archivos JavaScript que no eran propios de WordPress ni estaban encolados por Nelio Content, explorando el código fuente de la página de analíticas de Nelio Content.
Una vez tenemos estas URLs (más de 10, en nuestro caso), vamos poniéndolas en la extensión Interception y haciendo que se sustituyan por una URL de nuestra instalación local. Por tanto, acabaremos teniendo algo así:
Puedes ver que todas las URLs se reemplazan por URLs locales que apuntan a un JavaScript concreto (empty.js en la captura de arriba). Sólo tienes que hacer que este JavaScript esté vacío, así lo que consigues es «desactivar» esos JavaScripts. Y además, no tienes que preocuparte por esto, ya que no hay problema de que fallen las cosas puesto que esos scripts originales no deberían estar en esa página.
Una vez has hecho esto, verás que el contenido de esos scripts pasa a estar vacío. Lo puedes comprobar mirando la consola de desarrollador de tu navegador:
empty.js) visto desde la consola de desarrollador del navegador.Ahora que has interceptado los scripts conflictivos en tu navegador y los has «desactivado» localmente (recuerda que esto sólo pasa en tu navegador; la instalación de tu cliente sigue funcionando como siempre), puedes comprobar si tu plugin funciona. En nuestro caso, el problema desapareció, por lo que sólo queda ver qué plugin es el causante.
Para esto, sólo has de ir eliminando las reglas de sustitución de Interception una a una e ir probando para ver en qué momento el problema vuelve a aparecer. Una vez sepas cual es el JavaScript de otro plugin que está rompiendo el tuyo, ya tienes al culpable.
En el caso de nuestro cliente, el plugin causante añadía de forma indiscriminada un JavaScript en todas las páginas de WordPress. Este JavaScript lanzaba eventos en los selectores de forma también indiscriminada, por lo que volvía locos a los filtros de la página de analíticas de Nelio Content.
Hemos contactado por varias vías con los desarrolladores del plugin causante de los problemas (WP Social Traffic PRO, que no está en el directorio de WordPress, sino que se vende en una web externa) y no hemos recibido respuesta alguna. Al cliente se le reportó el problema y se le pidió que desactivara el plugin conflictivo, ya que podía inutilizar, no solo a Nelio Content, sino a otros plugins con selectores.
Y hasta aquí la historia de cómo pasamos una mañana en Nelio hasta que dimos con la solución gracias a Interception.
Nelio Content
Estoy tan contento con Nelio Content que parece que me hayan pagado para hablar bién de él… pero es que también a ti te encantará: funciona como prometen, la programación automática de mensajes es increíble, la calidad/precio no tiene parangón y su equipo de soporte se siente como si fueran parte del tuyo.
Panozk
Conclusiones
Cada plugin para WordPress sólo debería encolar archivos JavaScript y estilos CSS en sus propias páginas o en páginas comunes de WordPress. Un ejemplo de página común es la página de edición de entradas. Si vas a meter un CSS o un JavaScript allí, hazlo teniendo en cuenta que puedes romper el trabajo de otros. Ten cuidado y sé responsable.
Lamentablemente muchísimos plugins se saltan la norma anterior sin ningún motivo. Muchas veces por desconocimiento o inexperiencia de los desarrolladores. Por lo menos, eso me gustaría pensar. Si eres desarrollador WordPress, por favor, léete el Plugin Handbook. En serio, hazlo. Te lo dejo aquí enlazado una vez más.
Cuando un cliente tiene un problema, tendemos a pensar que la hemos liado y nos centramos demasiado en buscar qué hemos hecho mal. Este es uno de los errores que, por lo menos en mi caso, suelo cometer más a menudo. Y a veces, como en la historia que te he contado, la culpa es de otro. De haber mirado esto antes, hubiéramos llegado a la solución mucho más pronto. Eso sí, tampoco vayas de sobrado pensando que siempre los errores son culpa de otro. Simplemente ten presente que esto pasa, y compruébalo bien para intentar mejorar tu productividad.
Como cliente, ten cuidado de dónde sacas los plugins que instalas en tu WordPress. Intenta buscar información antes y comprueba que la fuente es de fiar y el desarrollador es experimentado. De lo contrario, te la juegas. El directorio de plugins de WordPress suele ser el mejor sitio donde buscar. Pero eso no quita que encuentres plugins de calidad dudosa. Otra vez, ten cuidado.
El proceso de revisión de plugins debería incluir ciertas comprobaciones automáticas. Así se podría evitar (o minimizar) el encolado de estilos y scripts de forma indiscriminada. Es algo factible. No me cansaré de pedirlo. ¿Por qué la revisión de temas es más abierta que la de plugins? En Nelio nos encantaría poder contribuir revisando plugins del directorio de WordPress.
La extensión Interception es una maravilla. Si conoces más herramientas como ésta que te ayudan en tu día a día como desarrollador, por favor no dudes en dejar un comentario explicando tu caso. Nos encantaría aprender de tu experiencia.
Imagen destacada de Alexander Dummer en Unsplash.
Deja una respuesta