Cuando la libertad de WordPress se carga tu negocio

Negocio

¿Sabías que sólo somos tres personas aquí en Nelio? Y aún así nuestras entradas molan, ¿eh? ¡Es gracias a nuestro nuevo plugin, Nelio Content! ¿Por qué no lo usas tú también?

La semana pasada uno de nuestros clientes abrió un tique de soporte describiendo un problema bastante raro. Aparentemente, cuando intentaba usar Nelio Content, la interfaz de usuario estaba rota y era imposible hacer nada con él. Como normalmente soy yo quien se encarga de los tiques de soporte, suelo estar bastante familiarizado con los problemillas que van saliendo y los motivos por los que pasan. Pero esta vez era muy raro todo: “el plugin se ve roto y no se puede usar”, nos decía el chico 🤔

Para que sepas de qué estoy hablando exactamente, así es cómo se debería de ver una de las ventanas de Nelio Content:

Diálogo para añadir nuevos mensajes sociales
Captura de pantalla del diálogo para añadir nuevos mensajes sociales con Nelio Content.

y esto es lo que nuestro querido cliente estaba viendo:

Diálogo de Nelio Content totalmente roto por culpa de otro plugin
Es imposible usar el diálogo de Nelio Content cuando hay un plugin de otro desarrollador activado, puesto que éste último rompe completamente nuestra interfaz.

😨😱 ¡¿Pero qué coj***s?! Efectivamente, esto es inusable😐 La barra de herramientas del editor está por encima del diálogo, el diálogo está todo mal, los colores (¿naranja?) están cambiados… ¿Qué ha pasado aquí?

Reproducir el problema

Siempre que un usuario reporta un problema, lo primero que debes hacer es (intentar) reproducirlo en tu propia instalación de desarrollo. Hay veces en las que esto es muy difícil o incluso imposible (por ejemplo, llamadas AJAX que requieren conexiones a Internet especialmente lentas). Otras veces, puede ser tan sencillo como activar un plugin cualquiera. Sea cual sea el caso, los usuarios deberían darte algo de información de contexto sobre cómo y cuándo sucedió el problema para que, precisamente, tú puedas verlo con tus ojos y reproducirlo. Si no lo hacen, pídeles información hasta que entiendas bien qué pasa y consigas tenerlo “en marcha” en tu ordenador.

En este caso en particular, el problema era fácil de reproducir. Cuando el usuario activaba el plugin Facebook Instant Articles & Google AMP Pages by PageFrog en su web, Nelio Content empezaba a ir mal. Para aquellos que no conozcan el plugin de PageFrog, ésta es su descripción en WordPress.org:

PageFrog es un plugin que te permite publicar y gestionar tu contenido WordPress en Facebook Instant Articles (FBIA) y Google Accelerated Mobile Pages (AMP), con soporte completo a anuncios y analíticas.

No sé tú, pero yo leyendo esta descripción soy incapaz de ver por qué un plugin como este puede hacer que el nuestro falle. Pero lo hace. ¿Por qué será?

Descubrir la fuente del problema

Llegados al punto en que ya hemos confirmado la existencia del problema y hemos sido capaces de reproducirlo en local (qué cracks 💪), es el momento de descubrir el porqué. Por desgracia, no existe ninguna fórmula mágica que te pueda dar para hacerlo. Encontrar los motivos por los que un problema sucede depende enteramente de tu experiencia… ¡Pero no decaigas! Veamos cómo lo hice yo en este caso concreto.

Para aquellos que sepan un poquito de mundo web y WordPress, supongo que ya estarán viendo claro que el problema tiene que estar necesariamente relacionado con las reglas CSS que hay activas. A fin de cuentas, éstas son las que modifican la apariencia de nuestra web… y está claro que aquí todo se ve “diferente” (por no decir “mal”). Recordemos cómo hemos reproducido el problema:

  • Si PageFrog no está activo, Nelio Content funciona bien y el diálogo es bonito.
  • Si PageFrog está activo, es imposible usar el diálogo porque esta roto.

Así que parece claro que el problema no sólo es una cuestión de CSS; ¡tienen que ser los CSS que está añadiendo PageFrog!

Para validar esta hipótesis, simplemente inspeccioné los elementos HTML del diálogo de Nelio Content (usando las herramientas de desarrollador de Google Chrome) y busqué si alguno de esos elementos estaba afectado por reglas de PageFrog. Y, efectivamente, así era; inspeccionando un elemento cualquiera vi la siguiente lista de reglas:

Reglas CSS activas
Captura de pantalla de las reglas CSS que hay activas cuando el plugin PageFrog está activo.

Recuerda que Chrome ordena las reglas de más específica a más genérica. ¿Ves las últimas reglas que aparecen en la lista? Son estas:

Así es, son reglas super genéricas (¡afectan a cualquier elemento!) y las está añadiendo el script pagefrog-admin.css. ¿Es posible que sean estas las culpables del embrollo este? Probemos a desactivarlas a ver qué pasa…

Gestión de reglas CSS
Con las herramientas de desarrollador de Chrome, puedes gestionar fácilmente las reglas CSS que se están aplicando a tu página.

…y ¡tachán!

Diálogo de Nelio Content medio roto
Después de desactivar algunas de las reglas añadidas por PageFrog, el diálogo de Nelio Content ya es reconocible, aunque sigue sin estar bien.

¡No está nada mal! Ahora ya tenemos algo más “funcional”. Con lo cual, efectivamente, esas reglas eran (en parte) culpables del problema. Por desgracia, aún quedan cosas por arreglar:

  • La barra de herramientas del editor TinyMCE sigue estando por encima del editor de Nelio Content.
  • El fondo oscuro que se pone por debajo del diálogo no está por encima del menú del Escritorio (y debería).
  • La apariencia del diálogo sigue sin ser correcta; no tiene el estilo de WordPress. Sus colores, el estilo de la barra, los botones… están cambiados.

Fíjate que todos estos problemas de ahora son exclusivos del “diálogo” flotante. Por si no lo sabes, estos diálogos (y otros componentes de la interfaz de WordPress) se crean usando la librería jQuery UI. Por defecto, un diálogo creado con esta librería tiene esta pinta:

Captura de pantalla de la página de jQuery UI
Apariencia por defecto de un diálogo creado con la librería jQuery UI.

que, curiosamente, se parece un montón al diálogo que tenemos en WordPress ahora mismo. Vaya, vaya… el estilo de la barra de título, el botón de cerrar, los bordes redondeados… Parecidos, ¿verdad? Sí, claro, hay alguna diferencia (por ejemplo, la barra de título en WordPress es naranja y aquí es gris), pero aún así es muy sospechoso, ¿no crees? 🤔

Una posible explicación a este extraño comportamiento es que, quizás, PageFrog está añadiendo su propia hoja de estilos para componentes jQuery UI. Si echamos un vistazo rápido al código fuente de la página, podemos confirmar la hipótesis en un par de segundos; fíjate en la línea 45:

Captura de pantalla de algunos scripts en la cabecera de un documento HTML
PageFrog añade su propia hoja de estilos para modificar la apariencia de jQuery UI.

Hay un script con el ID jquery_ui-css que tiene todos los números de ser el culpable. Suponiendo que PageFrog añada los scripts como toca, deberíamos encontrar en el código fuente del plugin un fragmento de código donde se registre y encole un script llamado jquery_ui. Y, efectivamente, ahí lo tenemos. En admin/class-pagefrog-admin.php encontramos lo siguiente:

PageFrog registra y encola estilos para jQuery UI
Captura de pantalla del fragmento de código de PageFrog en donde se registra y encola el estilo que jQuery UI debe tener (según PageFrog).

Si comentamos la línea 76 y evitamos que se registre el “script maldito”, los diálogos de Nelio Content se vuelven a ver bien.

Cuando la libertad de WordPress se carga salva tu negocio

Después de que nos reportaran este error y de ver quién lo estaba causando y cómo, no pude evitar pensar que la libertad de WordPress estaba atentando contra la viabilidad de nuestro negocio. Permíteme que me explique:

  1. Uno de nuestros clientes quería dejar de usar nuestro plugin porque no le funcionaba.
  2. El problema en cuestión no era culpa nuestra; otro plugin (que al cliente ni le va ni le viene) es el que está montando el pollo.
  3. Tuve que dedicar parte de mi tiempo a entender cómo funcionaba otro plugin, ver por qué fallaba y pensar en la solución. En definitiva, estaba “trabajando para otra gente”, no para Nelio.
  4. El problema es debido a que WordPress no impone ningún tipo de límite a qué pueden hacer y qué pueden sobrescribir los scripts y estilos que se encolan. Como resultado, cualquier plugin puede perjudicar a los demás si no es cuidadoso. Y muchos no lo son 😓

Así que estaba claro: si los desarrolladores pueden hacer lo que les dé la gana, acabarán (o acabaremos) perjudicando a los demás en un momento u otro. Ojo, no estoy diciendo que lo hagamos adrede… pero al final el resultado es el mismo: te han jodi** el negocio.

Pero, ¿sabes qué?, creo que en realidad la libertad de WordPress es positiva, no negativa. Gracias a que WordPress es código abierto y libre pude explorar el código fuente de un plugin que estaba rompiendo el nuestro. He podido contactar con los desarrolladores, pedirles ayuda y proponerles una solución por el camino. Y si, por lo que fuera, no pueden hacerse cargo de ella, sé que yo mismo podré solucionarlo para mis clientes, sin tener que depender de terceras partes (tal y como hicieron los de Yoast, por ejemplo).

La solución

A ver, entiéndeme. Sigo pensando que los desarrolladores tenemos que ser más cuidadosos cuando escribimos código. Si sabes cómo funcionan WordPress y la web, eres plenamente consciente de la importancia que tiene ser responsable y ordenado. Por ejemplo, si añades una página en el Escritorio de WordPress que necesita sus propios scripts o estilos, asegúrate de añadir esos scripts y estilos en esa página únicamente, no en todas las demás.

El problema que he descrito hoy era un poco más difícil de evitar porque ambos plugins (Nelio Content y PageFrog) manipulaban la misma página: la pantalla de edición de entradas. Cada plugin necesita sus scripts y estilos, así que es posible que, sin pretenderlo, uno sobrescriba la regla de otro. Es por ello que aquí es importantísimo que nuestro código esté siempre circunscrito a un ámbito: ni más, ni menos. Nosotros los hacíamos, pero como veis, otros no.

PageFrog puede solucionar fácilmente el problema que hemos encontrado. Por un lado, basta con que modifiquen sus reglas para que sean más específicas:

y no afecten a cualquier elemento de la web. Por otro lado, deberían evitar añadir la hoja de estilos de jQuery UI y dejar que sobrescriba los estilos por defecto de WordPress. O, si la necesitan, deberían editarla para que solo modificase los componentes de jQuery UI que ellos generen.

Somos una comunidad de código abierto. Estamos aquí para ayudarnos entre nosotros y aprender de los demás. Contacté con los desarrolladores de PageFrog hace un par de días y confío en que nos ayudarán a solucionar este problema (aunque, en el momento de escribir la entrada, aún no había recibido respuesta a mi correo). Pero si no pudieran o quisieran hacerlo, sé que tenemos las herramientas para hacerlo nosotros mismos 😆

Y tú, ¿has tenido problemas parecidos? ¿Has sido alguna vez la causa de que otro plugin deje de funcionar? ¡Danos tu opinión!

Imagen destacada de Pabak Sarkar.

FlojaNo está malBienMuy bien¡Impecable! (Ninguna valoración todavía)
Cargando…

por

Lidera el análisis y diseño de nuestros servicios, así como el servicio de soporte a los usuarios. Es Doctor en Computación por la UPC y siempre ha estado interesado en una gran variedad de áreas, incluyendo el modelado conceptual, la realidad virtual y la impresión digital en 3D. Contribuye muy activamente en la comunidad WordPress, habiendo participado en meetups, seminarios y en la WCEU.

4 comentarios en “Cuando la libertad de WordPress se carga tu negocio

  1. Enhorabuena, es un excelente artículo y reflexión sobre lo bueno y lo malo del Software libre y del código abierto y cómo lo que separa las ventajas de los inconvenientes es una delgada y a veces difusa línea.

    Coincido plenamente en que todos deberíamos ser cuidadosos en que nuestro trabajo con WordPress sea para bien de la comunidad, procurar interferir lo menos posible en otros desarrollos y que errores de este tipo en ocasiones no son intencionados.

    Sería interesante saber en qué acaba esto, la respuesta recibida por parte de la gente de PageFrog. En general por experiencia propia la respuesta de los desarrolladores suele ser positiva, aunque en muchos casos es gente que no vive específicamente de ese desarrollo concreto, que lo hace por hobby.

    Lo dicho, enhorabuena.

    1. Muchas gracias por tus palabras de apoyo, Jorge. Me alegra saber que compartes mi opinión en este aspecto y que, como yo, valoras el trabajo de los desarrolladores y el esfuerzo que todos ponemos para minimizar este tipo de problemas.

      En cuanto a la respuesta de la gente de PageFrog, la verdad es que de momento estoy un poco decepcionado. Les escribí el pasado viernes y aún no han respondido mi correo. De hecho, hoy mismo he abierto un hilo de soporte en WordPress.org; aunque aún es pronto para decir si van a responder o no, repasando los últimos hilos abiertos es difícil creer que van a encargarse del tema… ¡pero yo tengo fe!

      En fin, seguiremos atentos a la evolución del plugin de PageFrog.

      Un saludo,
      David

  2. Pues prepárate a ver muchos conflictos como ese y peores conforme vuestro plugin aumente su base de usuarios. Al final hay que aceptar que no está en tu mano resolver los problemas causados por terceros, tú ya has hecho bastante localizando la causa del problema e incluso dando una solución al autor del plugin conflictivo, si este no está dispuesto a solucionar el conflicto el usuario debería buscar una alternativa a dicho plugin.

    Y no estarías actuando mal por no querer asumir en tu código los problemas causados por un tercero. Asumir en tu código parches para arreglar lo que otros hacen mal sólo te conducirá a asumir problemas que no son tuyos y a tener más problemas en el futuro.

    1. Hola Samuel,

      Muchas gracias por aportar tu punto de vista; estoy totalmente de acuerdo con lo que dices. En general, soy contrario a modificar nuestro plugin para corregir los problemas de otros porque, como muy bien señalas, es “asumir problemas que no son nuestros” 😑

      De todas formas, hay veces en que no te queda más remedio que hacerlo. Si el plugin en cuestión tiene una enorme base de usuarios y quieres poder llevarte parte del pastel, o si no es realmente un problema de ellos, pero hay algún tipo de conflicto entre ambos plugins, entonces tendrás que buscar una solución. En este caso lo mejor es hacer un segundo plugin que extienda el tuyo y el de la otra parte, permitiendo que ambos convivan sin mayores problemas. Pero vaya, que si puedes evitarlo, mejor 😉

      Un saludo,
      David

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

He leído y acepto la Política de privacidad de Nelio Software.

Al marcar la casilla de aceptación estás dando tu legítimo consentimiento para que tu información personal se almacene en SiteGround y sea usada por Nelio Software con el propósito único de publicar aquí este comentario. Contáctanos para corregir, limitar, eliminar o acceder a tu información.