Cuando la libertad de WordPress se carga tu negocio

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:

y esto es lo que nuestro querido cliente estaba viendo:

?? ¡¿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:

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…

…y ¡tachán!

¡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:

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:

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:

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.

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

WordPress.org

Ver planes

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.