Categoría: Wordpress

Recientemente nos hemos visto en una situación extraña pero que una vez encontrado el problema tiene su sentido.

Resulta que tras poner en producción un sitio web construido con WordPress (Gutenberg), el equipo que se ocupa del SEO detecta un problema grave en la indexación del sitio y otras incidencias en determinados procedimientos con Google que rechazaba las URL enviadas a alguno de sus servicios.

El caso es que nos reportan que Googlebot no puede leer el contenido de la página y que, al usar herramientas de simulación de renderizado, ésta se ve «vacía».

Herramienta Fetch & Render. Observa bien para encontrar el fallo.

Si observamos bien esta pantalla, efectivamente parece vacía pero ya de primeras podemos ver un menú, y si hacemos scroll el menú desaparece. Eso quiere decir que hay altura.

Bien.

Otra pista nos la da el color de fondo, que corresponde con un rojo bajo de opacidad. Ese color coincide con el de la superposición del primer bloque de tipo «Fondo» que aparece en esa landing. Debería de verse un vídeo detrás de esa capa traslúcida, pero vemos que los vídeos están excluidos en el robots.txt así que todo en orden, estamos viendo ese bloque o al menos la superposición de color.

Seguimos haciendo scroll y llega a aparecer algo de contenido, justo el que estamos esperando. La primera frase que está dentro de ese bloque «Fondo» entra en escena y después, EL VACÍO de nuevo. También vemos aparecer por la derecha unos pequeños botones «fixed» que tenemos en el lateral derecho para acceder a la sección de contacto. Pero seguimos bajando y bajando y no llega a aparecer nada más. ¿Qué está pasando? ¿Hay más? ¿Dónde está? ¿No está? ¿Está detrás?

Lo que está claro es que el primer bloque, de tipo «Fondo», está y se renderiza, pero es absurdamente alto. Pues vamos a quitarlo y a ver si aparece el resto en un nuevo renderizado.

Cuidado con WP Rocket cuando estés haciendo pruebas

Ya me he dado de bruces con este plugin miles de veces. Arreglas algo y te quedas tan ancho, pero resulta que no te has acordado de purgar la caché de WP Rocket. Tú lo ves todo fantásticamente actualizado y arreglado porque estás logueado en tu WordPress y te saltas esa caché, pero el resto de mortales inferiores te van a poner los pies en la tierra con un rotundo «pues yo lo sigo viendo igual (de mal)».

Así que lo primero que hago es purgar y seguidamente desactivo el plugin para evitar que actúe de nuevo esa caché mientras estoy probando.

Prueba y error con tu simulador de renderizado favorito

Supongo que dará igual el que uses, nuestros compañeros nos recomendaron comprobar todo con este y así lo hicimos. También nos han dicho que quitando determinados bloques parece que todo se arregla, así que veamos qué tienen en común, y lo primero que vemos es que son bloques de tipo Fondo.

Vamos a ir quitando el primero.

Hemos quitado de la landing page el primer bloque de tipo Fondo que es el que la herramienta de renderizado nos mostraba, aunque bastante deformado y lanzamos una nueva simulación, y la cosa ha cambiado, al menos de color, pero parece todo igual de raro. Seguimos bajando y solo vemos fondo, pero es del color del segundo bloque Fondo que aparece en la web.

Lo que no hemos visto es nada de contenido antes de ese bloque, que lo hay.

Este tipo de bloque tiene una capa de color para crear un efecto de superposición sobre la imagen y garantizar la legibilidad del texto que pongas dentro. Tiene declarada una propiedad z-index: 1 y podríamos pensar que, por lo que sea, está capa está poniéndose por encima de todo el contenido ocupando todo el alto y ancho de la página (no del viewport) y no deja verlo, pero no tiene lógica porque es traslúcida así que algo deberíamos de ver por detrás.

La luz se enciende al pensar en los ajustes de estos bloques, a ver si tienen alguno en común. El alto mínimo. Bueno, más bien las unidades 100vh unos y 60vh el último.

vh = viewport height

¿Cómo va a ajustar un bot el alto del bloque al alto del viewport? ¿Acaso estamos pensando en esto?

Veo claro que está intentando ajustar cada bloque con altura definida en «vh» en relación a la altura de su viewport que es… ninguno, así que los hace infinitamente altos, o al menos los hace crecer hasta que se cansa. No tengo pruebas pero tampoco dudas, así que procedo a cambiar la altura a píxeles y a lanzar un nuevo renderizado para comprobar que, ya sea por lo que yo pienso o por otra razón infinitamente más compleja, se renderiza bien. Nuestros compis SEO hacen la prueba en su lado y tan contentos, así que ahora que sabemos lo que falla, vamos a buscar en Google si hay mejor manera de resolverlo.

La primera que se me ocurre es no darle altura mínima y usar JavaScript para dársela como se ha hecho durante todo el siglo XX. Creo que es un paso atrás y más complejo de lo que estamos dispuestos a asumir.

La segunda que veo por ahi es ponerle un max-height a estos bloques, pero corres el riesgo de ocultar contenido, no solo a los bots, sino también al usuario.

Me quedo con el alto mínimo en valor absoluto en pixels. ¿Hay alguien que conozca otra solución o unidad CSS «bot friendly»? Deja tu aportación en los comentarios

Youtube nos ofrece una opción muy interesante para cumplir con la «ley de cookies» cuando incrustamos vídeos de esa plataforma en nuestra web. Es el modo de privacidad aumentada.

Pero si queremos beneficiarnos de este modo en nuestro flamante WordPress con el editor Gutenberg no lo vamos a tener tan fácil.

¿Puedo usar el bloque Incrustados > Youtube de Gutenberg con el modo de privacidad aumentada?

Así de primeras no. Si has sido observador habrás visto que al generar el código de incrustación en Youtube, si activas el modo de privacidad aumentada la única diferencia es que la url del iframe es «youtube-nocookie» en lugar de «youtube».

Se te puede pasar por la cabeza pegar la url en el bloque y modificarla añadiendo «-nocookie», pero WordPress nos dice en ese momento que ese tipo de contenido no se puede incrustar.

¿Qué puedo hacer?

Filtrar la salida html del bloque «Youtube» de Gutenberg

Si estás iniciado en temas hijo o en la creación de plugins no te hace falta más, se trata de un pequeño fragmento php que captura la salida html que genera los bloques de Gutenberg y permite modificarla antes de mostrarla en pantalla. Se trata del filtro render_block

Abre el fichero functions.php de tu tema hijo o el de tu plugin personalizado y pega el siguiente script.

function sumun_nocookie_youtube_block( $block_content, $block ) {
    if ( $block['blockName'] === 'core-embed/youtube' ) {
        $block_content = str_replace('www.youtube.com', 'www.youtube-nocookie.com', $block_content);
    }
    return $block_content;
}
add_filter( 'render_block', 'sumun_nocookie_youtube_block', 10, 2 );

El fundamento de este script es identificar el tipo de bloque para asegurarnos de que sólo modificamos la salida del bloque «Youtube» y sustituir en la salida html la url www.youtube.com por www.youtube-nocookie.com. Con esto consigues modificar la llamada que hace el iframe y el problema está resuelto.

El filtro render_block está documentado aquí.

Beneficios

• Mantenemos el interfaz del bloque inalterado en el backoffice, más agradable de ver que un bloque html con un iframe, y fácilmente identificable como vídeo de youtube a primera vista.
• El usuario editor ni se dará cuenta del cambio.
• Se aplica a todos los bloques Youtube del sitio web, a los ya insertados y a los futuros.
• Mantenemos el responsiveness que ofrece este bloque en el front. Un conjunto de reglas CSS que hacen que nuestro vídeo se adapte a cualquier tamaño de pantalla correctamente.

Desventajas

• Sólo se me ocurre un beneficio que se puede volver en contra: si por lo que sea quieres que algunos de los vídeos sí que inserten cookies al usuario, no nos valdría esta solución ya que afecta a todos los bloques Youtube del sitio.
• Y hay que tener nociones mínimas para saber lo que haces con tu functions.php

Si no te manejas con PHP y no te atreves a tocar los ficheros, puedes usar un plugin que te permita añadir funcionalidades desde el backoffice, como por ejemplo My Custom Functions.

Si aún así no lo ves claro, tienes otra opción:

Incrustar vídeo de Youtube sin cookies mediante el método tradicional

Ya lo has visto al principio, usa el generador de código de incrustación de Youtube para obtener un iframe que puedes pegar en Gutenberg dentro de un bloque HTML puro:

• Abre el vídeo de Youtube
• Haz click en «compartir«
• Elige la opción «insertar«
• Activa la casilla «Activar el modo de privacidad aumentada«
• Pulsa el botón «copiar» o selecciona el código del iframe y cópialo.
• En Gutenberg, inserta un bloque HTML donde desees.
• Pega lo que tienes en el portapapeles.

Beneficios

• No necesitas ningún tipo de conocimientos de programación.
• No es necesario ningún plugin, WordPress lo soporta de forma nativa. Puedes hacerlo desde ya.

Desventajas

• No es tan intuitivo como el bloque Youtube.
• No tiene carácter retroactivo. Si ya tenías vídeos en otras páginas tendrás que sustituirlos por su correspondiente iframe con privacidad aumentada.
• No se va a adaptar bien a todos los tamaños de pantalla.

😉

Vamos con un pequeño consejo para hacer más intuitivo el backend de WordPress cuando en nuestro proyecto utilizamos a menudo el estado «borrador». Si es tu caso, habrás notado que es difícil distinguir una entrada (o custom post type) publicada de las que están en modo borrador.

Tan sólo la palabra «borrador» las distingue, ya que el sombreado que vemos no tiene nada que ver con el estado de la entrada, si no con el estilo de la tabla, que sombrea las filas impares para facilitar la lectura. Teniendo esto en cuenta, vamos a añadir unas reglas CSS que van a colorear en oscuro las filas que contienen una entrada en estado «borrador», así el resto destacará más.

tr.status-draft {
background-color: #C5C5C5;
}
.striped>tbody>tr.status-draft:nth-child(odd) {
background-color: #bdbdbd;
}

Si queremos asignar un color para cada estado de entrada, no tenemos más que fijarnos en las clases que se aplican a las filas de la tabla dependiendo del estado:

• Programada: status-future
• Publicada: status-publish
• Pendiente de revision: status-pending

Así pues podemos colorear de amarillo las entradas «pendientes de revisión» y de azul las «programadas para el futuro», y dejar como están las publicaciones «publicadas»

tr.status-draft {
background-color: #C5C5C5;
}
.striped>tbody>tr.status-draft:nth-child(odd) {
background-color: #BDBDBD;
}
tr.status-future {
background-color: #E7E9FF;
}
.striped>tbody>tr.status-future:nth-child(odd) {
background-color: #DBDEF9;
}
tr.status-pending {
background-color: #FBFFDA;
}
.striped>tbody>tr.status-pending:nth-child(odd) {
background-color: #F7FDC5;
}

 

Si ves, aplicamos un primer color para todas las filas de la tabla y después aplicamos un color algo más oscuro a las filas impares.

¿Dónde añadimos estas reglas?

Pues dependerá del theme que estés usando. Algunos disponen de opciones de personalización que permiten escribir reglas CSS en un área de texto y las guardan en la base de datos sin necesidad de modificar archivos css o php. Suelen estar en «Apariencia > Opciones del tema». Sin embargo, es posible que estas reglas css sólo afecten al frontend, es decir, a la parte «pública» de la página, y no al panel de administración de WordPress.

Una de las formas correctas de aplicar estas CSS sería a través de un plugin como «Add Admin CSS«, que añadirá a la cabecera del html de nuestro backend las reglas que escribamos en un área de texto. También podemos subir un archivo CSS por FTP o mediante el gestor de medios de WordPress y decirle al plugin que añada las reglas contenidas en ese archivo, de modo que podemos editarlo con nuestro editor favorito, en lugar de en un formulario html.

Sin embargo, nosotros solemos implementar esta funcionalidad a través de una función en un Child Theme. Todos nuestros proyectos requieren de un alto grado de presonalización, tanto en el frontend como en el backend, de modo que siempre comenzamos por crear un Child Theme de la plantilla de WordPress que hayamos elegido. De este modo, cuando actualicemos el theme principal, no perderemos las modificaciones que hayamos hecho.

Una vez creado el child theme, dentro de su directorio creamos un subdirectorio llamado CSS donde subiremos nuestro archivo CSS (admin.css, por ejemplo) y otros más si fueran necesarios en nuestro proyecto. Ahora, en el archivo functions.php del child theme, crearemos una función y «anclaremos» su resultado a la cabecera del html de nuestro panel de administración de wordpress:

function cargar_estilos_admin() {
wp_enqueue_style( ‘admin_css’, get_stylesheet_directory_uri() . ‘/css/admin.css’, false, ‘1.0.0’ );
}
add_action( ‘admin_enqueue_scripts’, ‘cargar_estilos_admin’ );

Si piensas que sería más sencillo escribir directamente las css en el archivo header.php de tu child theme, piensa que si actualizas el theme principal y hay modificaciones sustanciales en el archivo header.php, tú no las vas a ver ni disfrutar porque tu child theme está «sobreescribiendo» ese archivo (si hablamos con propiedad no lo sobreescribe, sino que tiene prioridad). Incluso es posible que se produzca algún error y tu sitio se caiga (por experiencia).

¿Y si quiero hacerlo sin utilizar un child theme ni un plugin de terceros?

Puedes escribir tu propio plugin, no es muy complicado, pero para cosas sencillas como estas, los plugins de terceros ofrecen rapidez de implementación, son ligeros, e incluso puede que ofrezcan algo de soporte.