Devtips: cómo interceptar archivos JavaScript desde la distancia y reemplazarlos con versiones locales

Traducción de Nuria Adell. No me voy a cansar de repetir eso. El mundo del desarrollo web es una jungla en la que no importa cuán experimentado sea, cualquier espécimen puede superar su trabajo. Si eso es lo que haces, sabrás de lo que estoy hablando. Hacer el mal es más fácil de lo que parece. Y, desafortunadamente, en Nelio ya hemos encontrado más situaciones de las que queríamos en las que nuestros complementos han dejado de funcionar debido a las malas prácticas de terceros. Uno de los problemas más comunes que puede encontrar hoy si desarrolla complementos de WordPress es el uso incorrecto de JavaScript. Muchos “desarrolladores” (para llamarlos elegantes) no respetan las reglas de WordPress. Y puedes encontrar sorpresas inesperadas. O peor aún, ¿los encontrarán sus clientes?
En este artículo, explicaré cómo pasamos una mañana investigando el problema que tenía un cliente de contenido de Neli y cómo logramos resolverlo debido a una extensión para Google Chrome y el trabajo que simplificó todo el proceso. Investigar los problemas de JavaScript en un “entorno hostil” La historia comienza como de costumbre: un cliente nos contactó a través de nuestro sistema de asistencia porque tuvo problemas con el contenido de Neli. En particular, el problema tenía que ver con los análisis proporcionados por el contenido de Nelio. En su instalación, la página de análisis de contenido de Nelio está cargada de infinito, sin mostrar nada más.
Después de pedir acceso a su WordPress (no siempre es fácil obtener acceso a sus clientes) y verificar el error solo, vi que realmente había un problema con nuestros scripts. Pero fue un problema muy extraño. Aparentemente, tenía un bucle infinito de llamadas. Funciones que se realizan solo en respuesta a los eventos. Entonces, de alguna manera, los eventos se generaron varias veces sin ningún sentido. Investigar este tipo de problemas en la instalación de un cliente es un infierno. Además, no pudimos reproducir el problema en nuestras instalaciones de desarrollo local. Entonces, cada cambio que tuvimos que hacer en nuestro código JavaScript significaba que tuvimos que probarlo en nuestra instalación de desarrollo, para preparar una nueva versión del complemento (un archivo .zip), para deshabilitar la versión cargada en el sitio. El cliente y para eliminarlo, para cargarlo la nueva versión allí y finalmente activar y ver si hemos resuelto el problema.
Está claro que si tiene acceso a FTP o SSH, todo se simplifica, pero no fue el caso. No siempre podrá tener un entorno en el que la prueba sea simple. Entonces, cada prueba que hicimos destruyó nuestra productividad y paciencia. Y además, nada indicó dónde estaba el problema. ¡¿Que hice mal?! Hasta que la pequeña bombilla se encendiera … ¿Qué sucede si el problema que tiene con nuestro complemento no es realmente un problema con nuestro complemento? ¿Podría haber otro complemento para poner algo en nuestra página y hacer que todo falle? Para investigar … Como debe saber, si un complemento de WordPress define una página privada en el tablero de WordPress, esta página (generalmente accesible a través del menú del complemento) pertenece al complemento y nadie debe colocar ningún estilo JavaScript o CSS allí. Esto es lo que dicen los estándares, pero la realidad es muy diferente, desafortunadamente. En la instalación de WordPress de nuestro cliente, en la página de análisis de software NELI, encontramos más de 10 archivos JavaScript que no formaban parte de nuestro complemento. Recuerde que esta página es privada, por lo que nadie además del contenido de Nelio, ¿no deberían poner nada allí? En estos casos, generalmente deshabilite los complementos activos y vea si el problema simplemente se resuelve solo con contenido de Nelio. A partir de ahí, si todo funciona, active un complemento una vez para ver cuál se rompe el suyo. Sin embargo, al estar frente a una instalación de WordPress en producción, no puede hacerlo increíblemente o puede hacer que el sitio web de su cliente falle desactivando complementos.
Afortunadamente, finalmente encontré la solución. La extensión de intercepción le permite reemplazar los scripts y estilos con los suyos, funciona tanto en Google Chrome como en Opera. Echa un vistazo aquí. Y su interfaz es muy simple: con la intercepción, solo tiene que indicar la ruta del archivo interceptado y la ruta que lo reemplaza. Solo tiene que escribir la URL de un archivo remoto y reemplazarlo con cualquier otra URL. De esta manera, pudimos encontrar todas las formas de los archivos JavaScript que no eran de WordPress o escritos por contenido de Nelio, explorando el código fuente de la página de análisis de contenido de Nelio.
Una vez que haya encontrado estas URL (más de 10, en nuestro caso), puede colocarlas en la extensión de intercepción y reemplazarlas con una URL en su instalación local. Llegué con algo así:

Captura de muestra y reemplazo de JavaScripts con intercepción. Puede ver que todas las URL han sido reemplazadas por URL locales que indican un cierto JavaScript (vacía.js en la captura de pantalla anterior). Que JavaScript no hace nada adentro para “deshabilitar” el otro JavaScript (llámalos interceptados). Y no tiene que preocuparse de que las cosas no fallarán, porque los scripts originales no deberían estar en esas páginas.
Una vez que haya hecho esto, verá que el contenido de esos scripts es reemplazado por su archivo vacía.js. Puede verificarlo mirando la consola de desarrollador de su navegador:

JavaScript vacío (vacía.js) visto desde la consola de desarrolladores del navegador. Ahora que ha interceptado scripts de conflicto en el navegador y los ha “deshabilitado” localmente (tenga en cuenta que esto solo está sucediendo en el navegador, la instalación de sus clientes todavía funciona como de costumbre), puede verificar si el complemento funciona. En nuestro caso, el problema desapareció, por lo que lo único que quedaba era descubrir qué complemento era la causa. Por esto, solo tiene que eliminar las reglas de reemplazo a su vez y probarlas para ver cuándo reaparece el problema. Una vez que hayas encontrado lo que JavaScript de otro complemento te destruye, tienes el culpable. En el caso de nuestro cliente, el complemento causal agregó un JavaScript sin discernimiento en todas las páginas de WordPress. Este JavaScript también arroja eventos en selectores sin sentido, por lo que se volvió loco por la página de análisis de contenido de Nelio.

Captura de pantalla de los análisis ofrecidos por Nelio Content. Me puse en contacto con los desarrolladores del complemento que causó los problemas (WP Social Traffic Pro, que no está en el director de WordPress, pero se vende en un sitio externo) de varios medios, pero no recibí respuesta. Se informó al cliente sobre el problema y se le pidió que deshabilitara el complemento en conflicto, ya que podría romper no solo el contenido de Nelio, sino también otros complementos con selectores.

Y hasta ahora la historia de cómo pasé una mañana en Nelio hasta que llegué con la solución debido a la intercepción.Conclusiones Cada complemento de WordPress solo debe poner estilos JavaScript y CSS en sus propias páginas o en páginas comunes de WordPress.Un ejemplo de una página común es la página para la edición.Si va a poner un CSS o un JavaScript allí, haz esto teniendo en cuenta que puedes romper el trabajo de los demás.Tenga cuidado y sea responsable.Desafortunadamente, muchos complementos omiten la regla anterior sin ningún motivo.A menudo se debe a la ignorancia o la falta de experiencia de los desarrolladores.Al menos eso es lo que me gustaría creer.Si es un desarrollador de WordPress, lea el manual del complemento.En serio, hazlo.Dejo el enlace una vez más.