Cambio de Divi a GeneratePress

El pasado viernes realicé el cambio de Tema de esta web desde Divi a GeneratePress. Ya hacía un tiempo que quería probar un diseño creado a partir de bloques de Gutenberg y en alguna charla del Cafelito WP, Jesús Yesares me habló muy bien de GeneratePress y me decidí a comenzar las pruebas en local.

Lo primero que necesitaba era replicar la apariencia actual, no voy a decir diseño, porque no lo es 🙁 ya he repetido muchas veces que lo mío es el backend y queda en evidencia que lo de crear «una apariencia» no se me da bien. En algún momento realizaré cambios en la apariencia, que sé que ya hacen falta, pero en este caso era sólo emular lo que ya había.

Algunos cambios a nivel de apariencia si que realicé, ya que necesitaba un logotipo, o al menos algo que se le pareciese. También necesitaba/quería utilizar tipografías variables.

Para el tema de las tipografías variables y algunas otras opciones realizaré unos pequeños videos con los que además experimentaré un poco con LBRY tv desde el canal que he creado para probar. Ya escribiré sobre esto y os iré contando.

Cambios realizados

Lo primero que hice fue instalar GeneratePress y crear un tema hijo y en dicho tema hijo crear los archivos SASS para las personalizaciones.

Después descargar las fuentes variables (video pendiente) y añadirlas a la hoja de estilos. He utilizado Raleway con pesos desde 100 hasta 900 para los textos. Crimson Pro con pesos desde 200 hasta 900 para los titulares.

A continuación añado ambas fuentes al personalizador de GeneratePress para tenerlas disponibles desde las opciones de tipografía del propio tema:

// Register fonts in GeneratePress Theme.
add_filter(
	'generate_typography_default_fonts',
	function( $fonts ) {
		$fonts[] = 'Raleway';
		$fonts[] = 'Crimson Pro';

		return $fonts;
	}
);

Después añado algunos colores por defecto para la paleta de colores de GeneratePress:

/**
 * Change GeneratePress default color palettes.
 *
 * @param array $palettes GeneratePress array palettes, until 8 colors.
 *
 * @return array
 */
function cl_gp_custom_color_palettes( $palettes ) {
	// Could be 8 colors.
	$palettes = array(
		'#d0491c',
		'#21759b',
		'#f0f0f0',
		'#ffffff',
		'#000000',
	);

	return $palettes;
}
add_filter( 'generate_default_color_palettes', 'cl_gp_custom_color_palettes' );

Continúo personalizando la paleta de colores de Gutenberg y desactivando la opción de colores personalizados:

/**
 * Load Gutemberg and Theme defaults.
 *
 * @return void
 */
add_action(
	'after_setup_theme',
	function() {
		// Disables custom colors in block color palette.
		add_theme_support( 'disable-custom-colors' );

		// Adds support for editor color palette.
		add_theme_support(
			'editor-color-palette',
			array(
				array(
					'name'  => __( 'Orange WP', 'tabernawp' ),
					'slug'  => 'orange-wp',
					'color' => '#d0491c',
				),
				array(
					'name'  => __( 'Blue WP', 'tabernawp' ),
					'slug'  => 'blue-wp',
					'color' => '#21759b',
				),
				array(
					'name'  => __( 'Light gray', 'tabernawp' ),
					'slug'  => 'light-gray',
					'color' => '#f0f0f0',
				),
				array(
					'name'  => __( 'Pure White', 'tabernawp' ),
					'slug'  => 'pure-white',
					'color' => '#fff',
				),
				array(
					'name'  => __( 'Pure Black', 'tabernawp' ),
					'slug'  => 'pure-black',
					'color' => '#000',
				),
			)
		);
	}
);

Con el cambio de tema quedan visibles todos los shortcodes de Divi, por lo que comienzo a crear de cero las páginas a base de bloques. Quizás con alguna de las muchas colecciones de bloques, la labor sería más sencilla. Pero yo utilicé sólo GenerateBlocks del mismo autor de GeneratePress.

Por cierto, tanto la decisión de utilizar GeneratePress como GenerateBlocks, además de la recomendación de Yesares, también tuvo mucha influencia la recomendación de mi compañero de Codeable Mike Andreasen, un gran experto en optimización a los más altos niveles (podéis leer sus posts en WP Bullet).

Proceso de creación

El proceso de creación a base de bloques es una buena experiencia y cada vez hay más posibilidades con Gutenberg, pero de momento la experiencia de edición de Divi sigue siendo muchísimo más completa, optimizada, con cantidad de opciones, intuitiva… sigue ganando por goleada, al igual que con Elementor, aunque en este caso el paso era de Divi a Gutenberg.

La experiencia ha sido muy gratificante, trabajar sólo con HTML (y CSS desde el tema hijo). Según iba avanzando también iba aprendiendo y viendo el proceso más natural y rápido, pero repito: Divi y Elementor siguen estando aún mucho más avanzados, pero no dudo que Gutenberg no tardará nada en alcanzarlos en todos los sentidos. En muchos aspectos ya los ha superado como en extensibilidad y compatibilidad.

Creo que apostar por Gutenberg ya no es cuestionable, aunque en mi caso y por la naturaleza de mi trabajo, seguiré utilizando estos y otros muchos dependiendo en cada caso de los clientes, presupuestos, tiempos y especificaciones.

Plugins

En el proceso de creación de las diferentes páginas, también estaba la página de contacto, antes realizada por completo desde Divi. Ahora tocaba elegir un plugin de formularios (o hacerlos desde cero, pero no era el caso) y opté con Contact Form 7, que a día de hoy es una de las opciones más completas y personalizables que existen, aunque también debo admitir que es la menos amigable con el creador, pero ya puestos a trabajar con el HTMl y CSS, no había problema.

También instalé Flamingo para no perder ningún contacto por algún posible problema del correo. Todas las adaptaciones de apariencia las incorporé en el CSS del tema hijo (generado con Gulp desde SASS).

Para cargar los javascript y estilos de CF7 sólo donde fuesen necesarios, primero los desactivo totalmente:

// Unload CF JS and CSS.
add_filter( 'wpcf7_load_js', '__return_false' );
add_filter( 'wpcf7_load_css', '__return_false' );

Después los cargo sólo en las páginas que incorporan un formulario CF7:

add_action(
	'wp_enqueue_scripts',
	function() {
		// Unregister obsolete jQuery version and register last stable version.
		wp_deregister_script( 'jquery' );
		wp_register_script( 'jquery', get_theme_file_uri( '/assets/js/jquery-3.5.1.min.js' ), array(), null, true );

		$cf_enabled_pages = array(
			'contacto',
			'servicio-wordpress-mantenimiento-bronce',
			'servicio-wordpress-mantenimiento-plata',
			'servicio-wordpress-mantenimiento-oro',
			'servicio-wordpress-mantenimiento-empresa',
		);

		// Load CF JS and CSS in specific pages.
		if ( is_page( $cf_enabled_pages ) ) {
			if ( function_exists( 'wpcf7_enqueue_scripts' ) ) {
				wpcf7_enqueue_scripts();
			};
			if ( function_exists( 'wpcf7_enqueue_styles' ) ) {
				wpcf7_enqueue_styles();
			};
		}
	}
);

Cómo podéis ver en el código anterior, también des-registro la versión nativa de jQuery que incorpora WordPress (que tiene cuatro fallos de seguridad reconocidos) y cargo la última versión disponible. Si algún plugin no funciona con la versión 3.5.1 de jQuery, es un claro candidato a eliminar de mi instalación de WordPress. El siguiente paso ya sería eliminar todos los plugins que utilicen jQuery en el front-end, pero eso aún no toca 🙂

Todos los formularios de las páginas de mantenimiento se resuelven con uno sólo pero cambiando el asunto del mail y otros contenidos con las variables de CF7 y WordPress [_post_name] [_post_title] [_post_url]

Otro cambio en cuanto a los plugins es que antes para los comentarios utilizaba Disqus, pero además de cargar los comentarios por javascript, para dos comentarios que puede tener una entrada en este blog, no me compensa para nada el efecto negativo que me produce. Ahora se utilizan los comentarios nativos de WordPress.

El siguiente cambio de plugin: para mostrar fragmentos de código (PHP, Bash, CSS, SQL, etc.) utilizaba el estupendo plugin Crayon Syntax Highlighter de Aram Kocharyan, pero ya hace más de 4 años que no se actualiza y ya tuve que hacer una modificación en el cambio a PHP 7 para que no diese fallos.

Así que tocaba cambio de plugin y justo el mes pasado hablaban sobre el tema en WordPress Tabern. Así que instalé el plugin Code Syntax Block que podéis ver por ejemplo aquí en el código de este artículo. Además configuré un lenguaje por defecto:

// Default language in Code Syntax Block plugin (https://es.wordpress.org/plugins/code-syntax-block/).
add_filter(
	'mkaz_code_syntax_default_lang',
	function() {
		return 'php';
	}
);

Y los lenguajes que suelo utilizar más habitualmente:

// Limit languages to show in Code Syntax Block plugin (https://es.wordpress.org/plugins/code-syntax-block/).
add_filter(
	'mkaz_code_syntax_language_list',
	function() {
		return array(
			'bash'       => 'Bash',
			'html'       => 'HTML',
			'javascript' => 'JavaScript',
			'json'       => 'JSON',
			'markdown'   => 'Markdown',
			'php'        => 'PHP',
			'sass'       => 'Sass',
			'css'        => 'CSS',
			'sql'        => 'SQL',
			'svg'        => 'SVG',
			'xml'        => 'XML',
			'yaml'       => 'YAML',
		);
	}
);

Por último tocaba actualizar un poco la política de privacidad y tema RGPD y aquí no había duda, gracias a Fernando Tellado, ya hace un tiempo que el plugin utilizado para estos menesteres es GDPR Cookie Compliance desde el que inserto el código de Google Analytics cuando el usuario acepta las cookies de terceros.

Aunque hace cerca de tres años os daba un código para sustituir el plugin de cookies, la verdad es que se queda muy corto. Se podría completar y adaptarlo, pero teniendo un plugin funcional y que realiza bien esta tarea, no hay necesidad de reinventar la rueda.

Accesibilidad

La accesibilidad es un tema en el que ya he trabajado un poco hace bastantes años, en los inicios del IE y Netscape, pero que olvidé mucho más de lo recomendable y que tenemos muy poco en cuenta. Otra estupenda consecuencia de los Cafelitos WP ha sido el estar casi a diario con Vicent Sanchis y para el cambio de tema le he bombardeado mucho a preguntas.

De ahí ha surgido por ejemplo el que use los acordeones con la etiqueta de HTML5 details, que utilizo por ejemplo en todos los planes de mantenimiento de la web. Sé que aún le falta mucho y queda bastante por hacer, pero que mucho por hacer, pero al menos el primer punto de pasar las pruebas automáticas de Lighthouse está aprobado.

GeneratePress es una maravilla en cuanto a cumplimiento de las reglas básicas de accesibilidad, pero algo más hay que hacer. En primer lugar, subrayar los enlaces, algo que GP no hace por defecto. En mi caso el SASS aplicado ha sido muy sencillo:

.site-main,
#right-sidebar {
	a:not(.gb-button) {
		border-bottom: 1px dotted $color_blue-wp;
		transition: all 0.5s ease-in-out;

		&:hover {
			border-bottom: 1px solid $color_orange-wp;
			background-color: $color_orange-wp;
			color: $color_pure-white;
		}
	}
}

Otra cosa a arreglar es el titular de los comentarios con el «Deja un comentario» que es un H3 en lugar de un H2, siendo así incorrecto, si por ejemplo la entrada no incluye un H2 y aunque lo incluya, debería estar anidado después del H1.

La solución es fácil con el filtro comment_form_defaults:

/**
 * Change several comment form defaults like heading
 *
 * @param  array $defaults Default params.
 *
 * @return array
 */
function cl_custom_reply_title( $defaults ) {
	$defaults['title_reply_before'] = '<h2 id="reply-title" class="comment-reply-title">';
	$defaults['title_reply_after']  = '</h2>';

	return $defaults;
}
add_filter( 'comment_form_defaults', 'cl_custom_reply_title' );

Pero de todas formas lo ideal sería que por defecto el tema lo fijase como un H2, después si el usuario quiere cambiarlo mediante el filtro, ya es cuestión suya (al igual que los enlaces en el texto que deberían ir subrayados), por lo que lo puse en el Github del tema y el propio Tom Usborne (creador del tema) respondió al Issue, no tengo muy claro si lo incorporarán en futuras versiones, pero ahí queda.

Otro problema de accesibilidad en algunas páginas, las que incorporan código como esta, es que el plugin Code Syntax Block añade un atributo lang al tag code con el lenguaje de programación usado y dicho atributo es para el idioma, por lo que se engaña al lector de pantalla.

La solución es tan sencilla como cambiar ese tributo lang por uno del tipo data-lang. Así que contacté con Marcus, el autor del plugin en el Slack de WordPress y fue muy receptivo a los cambios, me pidió un Pull Request (PR) con los cambios y se lo envié. Ahora estoy a la espera de que lo incorpore para que Lighthouse no de fallo en estos bloques de código.

Además también daba algunos problemas de falta de contraste. La primera solución fue realizar pequeños ajustes en el color de fuente, pero finalmente encontré a11y-dark theme que simplemente con añadirla en el tema hijo como /assets/prism/prism.css ya se carga en nuestros fragmentos de código. Si preferís una versión clara, utilizad https://github.com/ericwbailey/a11y-syntax-highlighting/blob/master/dist/prism/a11y-light.css

Esto de que te escuchen sugerencias de cambios, que puedas contribuir con tus modificaciones o encuentres mejoras ya implementadas, sólo existe gracias a la belleza del código abierto.

WPO

En el tema de la optimización web lo primero que me esperaba era una disminución increíble del número de nodos DOM en comparación con todos los creados desde Divi. En este aspecto me llevé una decepción, ya que el número de nodos es similar e incluso superior en algunos casos. Analizándolo fríamente a posteriori, hay dos factores que influyen en este resultado:

• El código Divi utilizado lo tenía muy optimizado. He visto diseños donde se insertaba un div y dentro otro para a continuación, insertar uno nuevo… yo había procurado minimizar el número de nodos al mínimo.
• La falta de experiencia con los bloques de Gutenberg y CodeBlocks, quizás haya hecho que mi resultado no haya sido el mejor posible.

Vuelvo a repetir que Divi y Elementor para mi siguen siendo dos herramientas increíbles y que junto con Gutenberg son mis tres apuestas actuales como ya comenté en su momento (aunque en ese momento no incluía Elementor al no haberlo usado suficientemente).

Pero quitando esta «pequeña decepción» del número de nodos DOM generados, el resultado final ha sido excelente. En primer lugar decir que esta web está alojada en Kinsta, que ya ofrece un excelente rendimiento, pero quitando el hosting ya de por sí optimizado, aún no he realizado ninguna optimización más fuera de las mencionadas aquí.

En las mediciones de Pingdom nos da un tiempo de carga de 294ms, pero desde que hace unos meses cambiaron su forma de medirlo, ha disminuido en todas las web, por lo que debemos tomar este dato «con pinzas». Además tampoco obtiene una muy buena puntuación general debido a que según Pingdom no se han comprimido los archivos con gzip. Cierto, pero la realidad es que se utiliza el protocolo mejorado de compresión Brotli y eso no lo tiene en cuenta Pingdom. Cada herramienta tiene sus pros y sus contras (y Google Page Speed tampoco se libra).

Pero si medimos con herramientas «más precisas» que si reconocen Brotli y dan tiempos de la carga completa de la página, entonces ya tenemos una imagen más real del resultado, con un tiempo de carga de 8ooms y un TTFB (Time To First Byte) de 152ms.

Repito que aún no he entrado en optimizaciones con lo que se podrían sacer unos mejores tiempos, pero si las tareas pendientes me lo permiten espero poderlas hacer poco a poco. Los tiempos previos con Divi eran muy buenos, pero la verdad es que con un mínimo esfuerzo, los resultados con GeneratePress son mejores.

Aunque podría seguir contando bastante más sobre el Tema (véase Tema con mayúscula y con minúscula 😉 ), creo que por hoy ya es suficiente.

Disclaimer: Algunas de los enlaces aquí puestos, son enlaces de afiliado. Sólo pongo enlaces de afiliado de productos que recomiendo porque los utilizo en mi web o en webs de clientes. NUNCA recomiendo algo que no haya probado personalmente y no lo use regularmente.